Si une personne ne doit pas connaître une information
mais doit pouvoir l'utiliser, est-il possible de lui
fournir un logiciel (ou un module logiciel) capable
de déchiffrer l'information et de produire le résultat
attendu ?
Je crois qu'il existe des boitiers cryptographiques capables
de faire ça : la clé est contenue dans le boitier, et c'est
la sécurité physique du boitier qui garantit que
l'utilisateur ne peut pas avoir accès au secret (la clé).
Selon vous, peut-on obtenir le même résultat
avec un logiciel (ou un module logiciel) ?
Le problème avec cette "boite noire" logicielle
est qu'elle est elle-même attaquable et peut
très bien révéler le secret (la clé).
(c'est ce qui s'est produit avec une clé de déchiffrement
des DVD vidéo, il me semble)
Selon vous, peut-on obtenir le même résultat avec un logiciel (ou un module logiciel) ?
AMHA, purement logiciellement, non ...
Le problème avec cette "boite noire" logicielle est qu'elle est elle-même attaquable et peut très bien révéler le secret (la clé).
voilà ... donc après c'est une question de gestion des risques ... si c'est une application avec un niveau d'obfuscation non trivial et qui concerne peu de monde/peu de flux, ça peut s'envisager ... si c'est une application largement diffusée ou critique, ça me parait plus discutable comme choix.
(c'est ce qui s'est produit avec une clé de déchiffrement des DVD vidéo, il me semble)
oui un soft de Xing si ma mémoire est bonne, et plus récemment on a eu le cas FairUse4WM/DRMDebug ou le reverse engineering chinois (prouvé ?) de Skype ...
Phil l'ancien wrote:
Selon vous, peut-on obtenir le même résultat
avec un logiciel (ou un module logiciel) ?
AMHA, purement logiciellement, non ...
Le problème avec cette "boite noire" logicielle
est qu'elle est elle-même attaquable et peut
très bien révéler le secret (la clé).
voilà ... donc après c'est une question de gestion des risques ... si
c'est une application avec un niveau d'obfuscation non trivial et qui
concerne peu de monde/peu de flux, ça peut s'envisager ... si c'est une
application largement diffusée ou critique, ça me parait plus discutable
comme choix.
(c'est ce qui s'est produit avec une clé de déchiffrement
des DVD vidéo, il me semble)
oui un soft de Xing si ma mémoire est bonne, et plus récemment on a eu
le cas FairUse4WM/DRMDebug ou le reverse engineering chinois (prouvé ?)
de Skype ...
Selon vous, peut-on obtenir le même résultat avec un logiciel (ou un module logiciel) ?
AMHA, purement logiciellement, non ...
Le problème avec cette "boite noire" logicielle est qu'elle est elle-même attaquable et peut très bien révéler le secret (la clé).
voilà ... donc après c'est une question de gestion des risques ... si c'est une application avec un niveau d'obfuscation non trivial et qui concerne peu de monde/peu de flux, ça peut s'envisager ... si c'est une application largement diffusée ou critique, ça me parait plus discutable comme choix.
(c'est ce qui s'est produit avec une clé de déchiffrement des DVD vidéo, il me semble)
oui un soft de Xing si ma mémoire est bonne, et plus récemment on a eu le cas FairUse4WM/DRMDebug ou le reverse engineering chinois (prouvé ?) de Skype ...
*core*administrator
On Fri, 17 Nov 2006 20:14:48 +0100, "Phil l'ancien" wrote:
(c'est ce qui s'est produit avec une clé de déchiffrement des DVD vidéo, il me semble)
Le système de "cryptage" (guillemets volontaires) utilisé pour les
DVD était tellement simple qu'il en était ridicule.
De plus quand un système doit être connu par un aussi grand nombre d'intervenants (TOUS les constructeurs) on est très très loin d'un système vraiment sécurisé.
On Fri, 17 Nov 2006 20:14:48 +0100, "Phil l'ancien"
<nicetry@noway.com> wrote:
(c'est ce qui s'est produit avec une clé de déchiffrement
des DVD vidéo, il me semble)
Le système de "cryptage" (guillemets volontaires) utilisé pour les
DVD était tellement simple qu'il en était ridicule.
De plus quand un système doit être connu par un aussi grand nombre
d'intervenants (TOUS les constructeurs) on est très très loin d'un
système vraiment sécurisé.
On Fri, 17 Nov 2006 20:14:48 +0100, "Phil l'ancien" wrote:
(c'est ce qui s'est produit avec une clé de déchiffrement des DVD vidéo, il me semble)
Le système de "cryptage" (guillemets volontaires) utilisé pour les
DVD était tellement simple qu'il en était ridicule.
De plus quand un système doit être connu par un aussi grand nombre d'intervenants (TOUS les constructeurs) on est très très loin d'un système vraiment sécurisé.
Phil l'ancien
Arisme
Phil l'ancien
Selon vous, peut-on obtenir le même résultat avec un logiciel (ou un module logiciel) ?
AMHA, purement logiciellement, non ...
Le problème avec cette "boite noire" logicielle est qu'elle est elle-même attaquable et peut très bien révéler le secret (la clé).
voilà ... donc après c'est une question de gestion des risques ... si c'est une application avec un niveau d'obfuscation non trivial et qui concerne peu de monde/peu de flux, ça peut s'envisager ... si c'est une application largement diffusée ou critique, ça me parait plus discutable comme choix.
Merci Arisme. D'accord avec toi. (en l'occurence, dans l'appli en question, le niveau d'obfuscation est trivial.)
Pour prolonger cette reflexion : que penses-tu des applis où l'expéditeur ne doit pas fournir au destinataire l'information à utiliser (pour des raisons juridiques, etc.), mais où en fait cet utilisateur connaît probablement l'information par ailleurs ?
Autrement dit : il ne s'agit pas tant de cacher l'information au destinataire que d'être certain qu'il ne l'apprend pas de l'émetteur.
Phil l'ancien-
Arisme
Phil l'ancien
Selon vous, peut-on obtenir le même résultat
avec un logiciel (ou un module logiciel) ?
AMHA, purement logiciellement, non ...
Le problème avec cette "boite noire" logicielle
est qu'elle est elle-même attaquable et peut
très bien révéler le secret (la clé).
voilà ... donc après c'est une question de gestion des risques ... si
c'est une application avec un niveau d'obfuscation non trivial et qui
concerne peu de monde/peu de flux, ça peut s'envisager ... si c'est une
application largement diffusée ou critique, ça me parait plus discutable
comme choix.
Merci Arisme. D'accord avec toi.
(en l'occurence, dans l'appli en question, le niveau
d'obfuscation est trivial.)
Pour prolonger cette reflexion : que penses-tu des applis
où l'expéditeur ne doit pas fournir au destinataire l'information
à utiliser (pour des raisons juridiques, etc.), mais où
en fait cet utilisateur connaît probablement l'information
par ailleurs ?
Autrement dit : il ne s'agit pas tant de cacher l'information
au destinataire que d'être certain qu'il ne l'apprend pas de
l'émetteur.
Selon vous, peut-on obtenir le même résultat avec un logiciel (ou un module logiciel) ?
AMHA, purement logiciellement, non ...
Le problème avec cette "boite noire" logicielle est qu'elle est elle-même attaquable et peut très bien révéler le secret (la clé).
voilà ... donc après c'est une question de gestion des risques ... si c'est une application avec un niveau d'obfuscation non trivial et qui concerne peu de monde/peu de flux, ça peut s'envisager ... si c'est une application largement diffusée ou critique, ça me parait plus discutable comme choix.
Merci Arisme. D'accord avec toi. (en l'occurence, dans l'appli en question, le niveau d'obfuscation est trivial.)
Pour prolonger cette reflexion : que penses-tu des applis où l'expéditeur ne doit pas fournir au destinataire l'information à utiliser (pour des raisons juridiques, etc.), mais où en fait cet utilisateur connaît probablement l'information par ailleurs ?
Autrement dit : il ne s'agit pas tant de cacher l'information au destinataire que d'être certain qu'il ne l'apprend pas de l'émetteur.
Phil l'ancien-
Phil l'ancien
Richard
Phil l'ancien
(c'est ce qui s'est produit avec une clé de déchiffrement des DVD vidéo, il me semble)
Le système de "cryptage" (guillemets volontaires) utilisé pour les DVD était tellement simple qu'il en était ridicule.
De plus quand un système doit être connu par un aussi grand nombre d'intervenants (TOUS les constructeurs) on est très très loin d'un système vraiment sécurisé.
Merci Richard. Pour toi, dans une appli similaire par le nombre d'intervenants (des constructeurs et des éditeurs de logiciels), quels moyens pourraient garantir une sécurité correcte ?
Phil l'ancien-
Richard
Phil l'ancien
(c'est ce qui s'est produit avec une clé de déchiffrement
des DVD vidéo, il me semble)
Le système de "cryptage" (guillemets volontaires) utilisé pour les
DVD était tellement simple qu'il en était ridicule.
De plus quand un système doit être connu par un aussi grand nombre
d'intervenants (TOUS les constructeurs) on est très très loin d'un
système vraiment sécurisé.
Merci Richard.
Pour toi, dans une appli similaire par le nombre d'intervenants
(des constructeurs et des éditeurs de logiciels), quels moyens
pourraient garantir une sécurité correcte ?
(c'est ce qui s'est produit avec une clé de déchiffrement des DVD vidéo, il me semble)
Le système de "cryptage" (guillemets volontaires) utilisé pour les DVD était tellement simple qu'il en était ridicule.
De plus quand un système doit être connu par un aussi grand nombre d'intervenants (TOUS les constructeurs) on est très très loin d'un système vraiment sécurisé.
Merci Richard. Pour toi, dans une appli similaire par le nombre d'intervenants (des constructeurs et des éditeurs de logiciels), quels moyens pourraient garantir une sécurité correcte ?
Phil l'ancien-
Alain
Si une personne ne doit pas connaître une information mais doit pouvoir l'utiliser, ce que tu veux faire d'ailleurs c'est un DRM.
est-il possible de lui fournir un logiciel (ou un module logiciel) capable de déchiffrer l'information et de produire le résultat attendu ? non, car si le logiciel est lisible, il suffit de construire une machine
virtuelle pour l'exécuter... on peut aussi par paresse faire de la rétro-conception et découvrir l'algorithme et les données utilisée
Je crois qu'il existe des boîtiers cryptographiques capables de faire ça : la clé est contenue dans le boîtier, et c'est la sécurité physique du boîtier qui garantit que l'utilisateur ne peut pas avoir accès au secret (la clé). le secret c'est le boîtier, qui cache le code et surtout la clé..
d'ailleurs en fait si tu cache le code, le code fais partie de la clé... mais comme les algorithmes ont une signature et ne sont pas aléatoires, le secret par "obscurité", c'est comme choisir une clé dans un livre écrit par des humains... facile à prévoir.
par contre la clé c'est un truc vraiment variable qui paramètre l'algorithme, qui peut (et doit) être public.
un exemple de tel boîtier c'est la carte à puce ! un processeur cryptographique, une clé, et une conception qui empêche la rétro-conception au rayons X,n au microscope.
Selon vous, peut-on obtenir le même résultat avec un logiciel (ou un module logiciel) ? ben non
Le problème avec cette "boite noire" logicielle est qu'elle est elle-même attaquable et peut très bien révéler le secret (la clé). ben oui...
(c'est ce qui s'est produit avec une clé de déchiffrement des DVD vidéo, il me semble) ben oui...
idem pour fairuseDRM
c'est pour ça que les futurs DRM seront basés sur un module matériel... d'ailleurs il y en a un de prévu dans Windows Vista. le projet de processeur Palladium (processeur qui refuse d'exécuter du code non certifié, et qui comprend un module cryptographique) est aussi dans cette lignée.
les lecteur Blueray aussi sont prévus pour avoir une clé qui puisse être mise à jours par internet pour éviter qu'elle ne fuite comme celle des DVD.
pour contourner la protection, il faut alors récupérer les info aux extrémités, typiquement en analogique via le câble audio ou le câble vidéo...
d'ailleurs pour garantir la protection, ils (HDDV) cryptent le canal numérique avec l'écran, qui lui aussi utilise une clé, qui elle aussi peut être mise à jours...
dans quelques années il faudra récupérer une clé pour son lecteur de DVD, son écran, son PC, comme on le fait pour son décodeur Canal+
la révolution DRM c'est que les médias ne nous appartiennent plus, surtout la vidéo qui est très dure à capturer... et comme avec les décodeurs pirates modernes, il faudra soit payer aux major, soit payer aux mafias qui ont le réseau pour capturer les clés rapidement et diffusent leur propre DRM pirate... fini le décodage de papa et le piratage bon enfant... c'est normal la prohibition crée le trafic...
Si une personne ne doit pas connaître une information
mais doit pouvoir l'utiliser,
ce que tu veux faire d'ailleurs c'est un DRM.
est-il possible de lui
fournir un logiciel (ou un module logiciel) capable
de déchiffrer l'information et de produire le résultat
attendu ?
non, car si le logiciel est lisible, il suffit de construire une machine
virtuelle pour l'exécuter...
on peut aussi par paresse faire de la rétro-conception et découvrir
l'algorithme et les données utilisée
Je crois qu'il existe des boîtiers cryptographiques capables
de faire ça : la clé est contenue dans le boîtier, et c'est
la sécurité physique du boîtier qui garantit que
l'utilisateur ne peut pas avoir accès au secret (la clé).
le secret c'est le boîtier, qui cache le code et surtout la clé..
d'ailleurs en fait si tu cache le code, le code fais partie de la clé...
mais comme les algorithmes ont une signature et ne sont pas aléatoires,
le secret par "obscurité", c'est comme choisir une clé dans un livre
écrit par des humains... facile à prévoir.
par contre la clé c'est un truc vraiment variable qui paramètre
l'algorithme, qui peut (et doit) être public.
un exemple de tel boîtier c'est la carte à puce !
un processeur cryptographique, une clé, et une conception qui empêche la
rétro-conception au rayons X,n au microscope.
Selon vous, peut-on obtenir le même résultat
avec un logiciel (ou un module logiciel) ?
ben non
Le problème avec cette "boite noire" logicielle
est qu'elle est elle-même attaquable et peut
très bien révéler le secret (la clé).
ben oui...
(c'est ce qui s'est produit avec une clé de déchiffrement
des DVD vidéo, il me semble)
ben oui...
idem pour fairuseDRM
c'est pour ça que les futurs DRM seront basés sur un module matériel...
d'ailleurs il y en a un de prévu dans Windows Vista.
le projet de processeur Palladium (processeur qui refuse d'exécuter du
code non certifié, et qui comprend un module cryptographique) est aussi
dans cette lignée.
les lecteur Blueray aussi sont prévus pour avoir une clé qui puisse être
mise à jours par internet pour éviter qu'elle ne fuite comme celle des DVD.
pour contourner la protection, il faut alors récupérer les info aux
extrémités, typiquement en analogique via le câble audio ou le câble
vidéo...
d'ailleurs pour garantir la protection, ils (HDDV) cryptent le canal
numérique avec l'écran, qui lui aussi utilise une clé, qui elle aussi
peut être mise à jours...
dans quelques années il faudra récupérer une clé pour son lecteur de
DVD, son écran, son PC, comme on le fait pour son décodeur Canal+
la révolution DRM c'est que les médias ne nous appartiennent plus,
surtout la vidéo qui est très dure à capturer...
et comme avec les décodeurs pirates modernes, il faudra soit payer aux
major, soit payer aux mafias qui ont le réseau pour capturer les clés
rapidement et diffusent leur propre DRM pirate...
fini le décodage de papa et le piratage bon enfant... c'est normal la
prohibition crée le trafic...
Si une personne ne doit pas connaître une information mais doit pouvoir l'utiliser, ce que tu veux faire d'ailleurs c'est un DRM.
est-il possible de lui fournir un logiciel (ou un module logiciel) capable de déchiffrer l'information et de produire le résultat attendu ? non, car si le logiciel est lisible, il suffit de construire une machine
virtuelle pour l'exécuter... on peut aussi par paresse faire de la rétro-conception et découvrir l'algorithme et les données utilisée
Je crois qu'il existe des boîtiers cryptographiques capables de faire ça : la clé est contenue dans le boîtier, et c'est la sécurité physique du boîtier qui garantit que l'utilisateur ne peut pas avoir accès au secret (la clé). le secret c'est le boîtier, qui cache le code et surtout la clé..
d'ailleurs en fait si tu cache le code, le code fais partie de la clé... mais comme les algorithmes ont une signature et ne sont pas aléatoires, le secret par "obscurité", c'est comme choisir une clé dans un livre écrit par des humains... facile à prévoir.
par contre la clé c'est un truc vraiment variable qui paramètre l'algorithme, qui peut (et doit) être public.
un exemple de tel boîtier c'est la carte à puce ! un processeur cryptographique, une clé, et une conception qui empêche la rétro-conception au rayons X,n au microscope.
Selon vous, peut-on obtenir le même résultat avec un logiciel (ou un module logiciel) ? ben non
Le problème avec cette "boite noire" logicielle est qu'elle est elle-même attaquable et peut très bien révéler le secret (la clé). ben oui...
(c'est ce qui s'est produit avec une clé de déchiffrement des DVD vidéo, il me semble) ben oui...
idem pour fairuseDRM
c'est pour ça que les futurs DRM seront basés sur un module matériel... d'ailleurs il y en a un de prévu dans Windows Vista. le projet de processeur Palladium (processeur qui refuse d'exécuter du code non certifié, et qui comprend un module cryptographique) est aussi dans cette lignée.
les lecteur Blueray aussi sont prévus pour avoir une clé qui puisse être mise à jours par internet pour éviter qu'elle ne fuite comme celle des DVD.
pour contourner la protection, il faut alors récupérer les info aux extrémités, typiquement en analogique via le câble audio ou le câble vidéo...
d'ailleurs pour garantir la protection, ils (HDDV) cryptent le canal numérique avec l'écran, qui lui aussi utilise une clé, qui elle aussi peut être mise à jours...
dans quelques années il faudra récupérer une clé pour son lecteur de DVD, son écran, son PC, comme on le fait pour son décodeur Canal+
la révolution DRM c'est que les médias ne nous appartiennent plus, surtout la vidéo qui est très dure à capturer... et comme avec les décodeurs pirates modernes, il faudra soit payer aux major, soit payer aux mafias qui ont le réseau pour capturer les clés rapidement et diffusent leur propre DRM pirate... fini le décodage de papa et le piratage bon enfant... c'est normal la prohibition crée le trafic...
Phil l'ancien
Alain
Phil l'ancien
Si une personne ne doit pas connaître une information mais doit pouvoir l'utiliser,
ce que tu veux faire d'ailleurs c'est un DRM.
Maintenant que tu le dis, c'est vrai que ça y ressemble. En résumé : utiliser, mais sans connaître.
est-il possible de lui fournir un logiciel (ou un module logiciel) capable de déchiffrer l'information et de produire le résultat attendu ?
non, car si le logiciel est lisible, il suffit de construire une machine virtuelle pour l'exécuter... on peut aussi par paresse faire de la rétro-conception et découvrir l'algorithme et les données utilisée
En effet. Comme le dit Arisme, c'est une question de gestion du risque.
Je crois qu'il existe des boîtiers cryptographiques capables de faire ça : la clé est contenue dans le boîtier, et c'est la sécurité physique du boîtier qui garantit que l'utilisateur ne peut pas avoir accès au secret (la clé).
... un exemple de tel boîtier c'est la carte à puce !
En effet... je n'y avais pas pensé, mais c'est exactement la même chose. Tu as des références là dessus ?
Phil l'ancien-
Alain
Phil l'ancien
Si une personne ne doit pas connaître une information
mais doit pouvoir l'utiliser,
ce que tu veux faire d'ailleurs c'est un DRM.
Maintenant que tu le dis, c'est vrai que ça y ressemble.
En résumé : utiliser, mais sans connaître.
est-il possible de lui
fournir un logiciel (ou un module logiciel) capable
de déchiffrer l'information et de produire le résultat
attendu ?
non, car si le logiciel est lisible, il suffit de construire une
machine virtuelle pour l'exécuter...
on peut aussi par paresse faire de la rétro-conception
et découvrir l'algorithme et les données utilisée
En effet. Comme le dit Arisme, c'est une question
de gestion du risque.
Je crois qu'il existe des boîtiers cryptographiques capables
de faire ça : la clé est contenue dans le boîtier, et c'est
la sécurité physique du boîtier qui garantit que
l'utilisateur ne peut pas avoir accès au secret (la clé).
...
un exemple de tel boîtier c'est la carte à puce !
En effet... je n'y avais pas pensé, mais c'est
exactement la même chose.
Tu as des références là dessus ?
Si une personne ne doit pas connaître une information mais doit pouvoir l'utiliser,
ce que tu veux faire d'ailleurs c'est un DRM.
Maintenant que tu le dis, c'est vrai que ça y ressemble. En résumé : utiliser, mais sans connaître.
est-il possible de lui fournir un logiciel (ou un module logiciel) capable de déchiffrer l'information et de produire le résultat attendu ?
non, car si le logiciel est lisible, il suffit de construire une machine virtuelle pour l'exécuter... on peut aussi par paresse faire de la rétro-conception et découvrir l'algorithme et les données utilisée
En effet. Comme le dit Arisme, c'est une question de gestion du risque.
Je crois qu'il existe des boîtiers cryptographiques capables de faire ça : la clé est contenue dans le boîtier, et c'est la sécurité physique du boîtier qui garantit que l'utilisateur ne peut pas avoir accès au secret (la clé).
... un exemple de tel boîtier c'est la carte à puce !
En effet... je n'y avais pas pensé, mais c'est exactement la même chose. Tu as des références là dessus ?
Phil l'ancien-
Alain
Alain En effet... je n'y avais pas pensé, mais c'est exactement la même chose. Tu as des références là dessus ? wikipedia le sais
http://fr.wikipedia.org/wiki/Carte_%C3%A0_puce
Alain
En effet... je n'y avais pas pensé, mais c'est
exactement la même chose.
Tu as des références là dessus ?
wikipedia le sais
Alain En effet... je n'y avais pas pensé, mais c'est exactement la même chose. Tu as des références là dessus ? wikipedia le sais
http://fr.wikipedia.org/wiki/Carte_%C3%A0_puce
Arisme
Phil l'ancien wrote:
Pour prolonger cette reflexion : que penses-tu des applis où l'expéditeur ne doit pas fournir au destinataire l'information à utiliser (pour des raisons juridiques, etc.), mais où en fait cet utilisateur connaît probablement l'information par ailleurs ?
Autrement dit : il ne s'agit pas tant de cacher l'information au destinataire que d'être certain qu'il ne l'apprend pas de l'émetteur.
Ca me parait assez flou vu comme ça, mais toujours AMHA je pense que c'est un problème qui se résoud plus facilement par une voie contractuelle (i.e. si jamais l'information sort c'est conséquence X) que par une voie logicielle :)
Phil l'ancien wrote:
Pour prolonger cette reflexion : que penses-tu des applis
où l'expéditeur ne doit pas fournir au destinataire l'information
à utiliser (pour des raisons juridiques, etc.), mais où
en fait cet utilisateur connaît probablement l'information
par ailleurs ?
Autrement dit : il ne s'agit pas tant de cacher l'information
au destinataire que d'être certain qu'il ne l'apprend pas de
l'émetteur.
Ca me parait assez flou vu comme ça, mais toujours AMHA je pense que
c'est un problème qui se résoud plus facilement par une voie
contractuelle (i.e. si jamais l'information sort c'est conséquence X)
que par une voie logicielle :)
Pour prolonger cette reflexion : que penses-tu des applis où l'expéditeur ne doit pas fournir au destinataire l'information à utiliser (pour des raisons juridiques, etc.), mais où en fait cet utilisateur connaît probablement l'information par ailleurs ?
Autrement dit : il ne s'agit pas tant de cacher l'information au destinataire que d'être certain qu'il ne l'apprend pas de l'émetteur.
Ca me parait assez flou vu comme ça, mais toujours AMHA je pense que c'est un problème qui se résoud plus facilement par une voie contractuelle (i.e. si jamais l'information sort c'est conséquence X) que par une voie logicielle :)
Arisme
Alain wrote:
Alain En effet... je n'y avais pas pensé, mais c'est exactement la même chose. Tu as des références là dessus ?
wikipedia le sais http://fr.wikipedia.org/wiki/Carte_%C3%A0_puce
mais bon si c'est pour un cas typique de DRM, la carte à puce peut aussi contribuer à donner une fausse impression de sécurité - il faut bien réfléchir à l'ensemble de l'architecture et surtout aux différents points d'échange entre les différents modules ... en gardant à l'esprit que se protéger d'une attaque de l'utilisateur sur un système pleinement contrôlé par l'utilisateur, c'est légèrement impossible, et que le maillon le plus faible de la chaîne définit le niveau de sécurité de la chaîne dans ce cas :)
Alain wrote:
Alain
En effet... je n'y avais pas pensé, mais c'est
exactement la même chose.
Tu as des références là dessus ?
wikipedia le sais
http://fr.wikipedia.org/wiki/Carte_%C3%A0_puce
mais bon si c'est pour un cas typique de DRM, la carte à puce peut aussi
contribuer à donner une fausse impression de sécurité - il faut bien
réfléchir à l'ensemble de l'architecture et surtout aux différents
points d'échange entre les différents modules ... en gardant à l'esprit
que se protéger d'une attaque de l'utilisateur sur un système pleinement
contrôlé par l'utilisateur, c'est légèrement impossible, et que le
maillon le plus faible de la chaîne définit le niveau de sécurité de la
chaîne dans ce cas :)
Alain En effet... je n'y avais pas pensé, mais c'est exactement la même chose. Tu as des références là dessus ?
wikipedia le sais http://fr.wikipedia.org/wiki/Carte_%C3%A0_puce
mais bon si c'est pour un cas typique de DRM, la carte à puce peut aussi contribuer à donner une fausse impression de sécurité - il faut bien réfléchir à l'ensemble de l'architecture et surtout aux différents points d'échange entre les différents modules ... en gardant à l'esprit que se protéger d'une attaque de l'utilisateur sur un système pleinement contrôlé par l'utilisateur, c'est légèrement impossible, et que le maillon le plus faible de la chaîne définit le niveau de sécurité de la chaîne dans ce cas :)
Alain
Alain wrote:
mais bon si c'est pour un cas typique de DRM, la carte à puce peut aussi contribuer à donner une fausse impression de sécurité - il faut bien réfléchir à l'ensemble de l'architecture et surtout aux différents points d'échange entre les différents modules ... en gardant à l'esprit que se protéger d'une attaque de l'utilisateur sur un système pleinement contrôlé par l'utilisateur, c'est légèrement impossible, et que le maillon le plus faible de la chaîne définit le niveau de sécurité de la chaîne dans ce cas :)
tout a fait, la carte se content de protéger la clé et d'appliquer un algorithme avec la clé...
comme expliqué le problème du DRM est de protéger le flux d'information une fois décodé... si on a un ordinateur généraliste non protégé il faut qu'un flux protégé sorte du système protégé de la carte vers un périphérique protégé qui décode... (en fait il devrait s'agir de clés temporaires échangées, pas de données)... le protocole est à bien étudier...
une idée comme ca, copiée sur des protocoles connus (ca doit être un système de chiffrement avec tiers de confiance, la carte)
un DVD est chiffré avec une clé KDVD générée alléatoirement. on ajoute sur le DVD KDVD chiffrée avec KMAJOR lors de la lecture du DVD la carte a puce sur le PC (ou le module DRM d'un lecteur DVD "assermenté") recoit la clé KDVD chiffrée, (éventuellement quelques info DRM chiffrées avec KMAJOR) et la déchiffre avec KMAJOR. elle la rechiffre avec KEQUIPEMENTIER et la retourne le lecteur donne KDVD rechiffré avec KEQUIPEMENTIER à l'écran, qui déchiffre tout...
l'avantage de ce système c'est que la puce ou le module ne chiffre que peu de donnée. seul l'écran déchiffre une masse d'info importante.
ainsi la futur super HDTV se fera sur des écrans à canaux DVI cryptés... ca sortira d'un lecteur blueray protégé comme une carte à puce, vers un écran protégé idem... on pourra peut être pirater les info au niveau des électrodes de l'écran, ou alors pirater les clés au niveau des majors elles mêmes ou des équipementiers... ou alors pirater les clés avec des analyseurs logiques dans l'écran ou dans le lecteur DVD si le module de cryptage n'est pas dédié.
à noter que l'attaque de RSA via le temps de calcul sur processeur superscalaire à spéculation, attaque peut être les cartes à puces... mais je ne serais pas étonné qu'elles en soient protégées à la conception... je serais pas étonne que les clés soient mal protégées dans les lecteurs si elles ne sont pas gérées dans un module dédié...
Alain wrote:
mais bon si c'est pour un cas typique de DRM, la carte à puce peut aussi
contribuer à donner une fausse impression de sécurité - il faut bien
réfléchir à l'ensemble de l'architecture et surtout aux différents
points d'échange entre les différents modules ... en gardant à l'esprit
que se protéger d'une attaque de l'utilisateur sur un système pleinement
contrôlé par l'utilisateur, c'est légèrement impossible, et que le
maillon le plus faible de la chaîne définit le niveau de sécurité de la
chaîne dans ce cas :)
tout a fait, la carte se content de protéger la clé et d'appliquer un
algorithme avec la clé...
comme expliqué le problème du DRM est de protéger le flux d'information
une fois décodé...
si on a un ordinateur généraliste non protégé il faut qu'un flux protégé
sorte du système protégé de la carte vers un périphérique protégé qui
décode... (en fait il devrait s'agir de clés temporaires échangées, pas
de données)... le protocole est à bien étudier...
une idée comme ca, copiée sur des protocoles connus (ca doit être un
système de chiffrement avec tiers de confiance, la carte)
un DVD est chiffré avec une clé KDVD générée alléatoirement.
on ajoute sur le DVD KDVD chiffrée avec KMAJOR
lors de la lecture du DVD
la carte a puce sur le PC (ou le module DRM d'un lecteur DVD
"assermenté") recoit la clé KDVD chiffrée, (éventuellement quelques info
DRM chiffrées avec KMAJOR) et la déchiffre avec KMAJOR.
elle la rechiffre avec KEQUIPEMENTIER et la retourne
le lecteur donne KDVD rechiffré avec KEQUIPEMENTIER à l'écran, qui
déchiffre tout...
l'avantage de ce système c'est que la puce ou le module ne chiffre que
peu de donnée. seul l'écran déchiffre une masse d'info importante.
ainsi la futur super HDTV se fera sur des écrans à canaux DVI cryptés...
ca sortira d'un lecteur blueray protégé comme une carte à puce, vers un
écran protégé idem...
on pourra peut être pirater les info au niveau des électrodes de l'écran,
ou alors pirater les clés au niveau des majors elles mêmes ou des
équipementiers...
ou alors pirater les clés avec des analyseurs logiques dans l'écran ou
dans le lecteur DVD si le module de cryptage n'est pas dédié.
à noter que l'attaque de RSA via le temps de calcul sur processeur
superscalaire à spéculation, attaque peut être les cartes à puces...
mais je ne serais pas étonné qu'elles en soient protégées à la conception...
je serais pas étonne que les clés soient mal protégées dans les lecteurs
si elles ne sont pas gérées dans un module dédié...
mais bon si c'est pour un cas typique de DRM, la carte à puce peut aussi contribuer à donner une fausse impression de sécurité - il faut bien réfléchir à l'ensemble de l'architecture et surtout aux différents points d'échange entre les différents modules ... en gardant à l'esprit que se protéger d'une attaque de l'utilisateur sur un système pleinement contrôlé par l'utilisateur, c'est légèrement impossible, et que le maillon le plus faible de la chaîne définit le niveau de sécurité de la chaîne dans ce cas :)
tout a fait, la carte se content de protéger la clé et d'appliquer un algorithme avec la clé...
comme expliqué le problème du DRM est de protéger le flux d'information une fois décodé... si on a un ordinateur généraliste non protégé il faut qu'un flux protégé sorte du système protégé de la carte vers un périphérique protégé qui décode... (en fait il devrait s'agir de clés temporaires échangées, pas de données)... le protocole est à bien étudier...
une idée comme ca, copiée sur des protocoles connus (ca doit être un système de chiffrement avec tiers de confiance, la carte)
un DVD est chiffré avec une clé KDVD générée alléatoirement. on ajoute sur le DVD KDVD chiffrée avec KMAJOR lors de la lecture du DVD la carte a puce sur le PC (ou le module DRM d'un lecteur DVD "assermenté") recoit la clé KDVD chiffrée, (éventuellement quelques info DRM chiffrées avec KMAJOR) et la déchiffre avec KMAJOR. elle la rechiffre avec KEQUIPEMENTIER et la retourne le lecteur donne KDVD rechiffré avec KEQUIPEMENTIER à l'écran, qui déchiffre tout...
l'avantage de ce système c'est que la puce ou le module ne chiffre que peu de donnée. seul l'écran déchiffre une masse d'info importante.
ainsi la futur super HDTV se fera sur des écrans à canaux DVI cryptés... ca sortira d'un lecteur blueray protégé comme une carte à puce, vers un écran protégé idem... on pourra peut être pirater les info au niveau des électrodes de l'écran, ou alors pirater les clés au niveau des majors elles mêmes ou des équipementiers... ou alors pirater les clés avec des analyseurs logiques dans l'écran ou dans le lecteur DVD si le module de cryptage n'est pas dédié.
à noter que l'attaque de RSA via le temps de calcul sur processeur superscalaire à spéculation, attaque peut être les cartes à puces... mais je ne serais pas étonné qu'elles en soient protégées à la conception... je serais pas étonne que les clés soient mal protégées dans les lecteurs si elles ne sont pas gérées dans un module dédié...
