Un petit article avec une vidéo un peu longuette,
http://www.hackaday.com/2008/01/01/24c3-mifare-crypto1-rfid-completely-broken/
Résumé très grossier en français : deux chercheurs ont disséqué la puce
Mifare pour tenter de casser l'algorithme d'authentification et de
chiffrement (Crypto1, algorithme propriétaire Philips, vieux de plus de 10
ans et utilisant des clés de 48 bits). Ils auraient entre autre choses
identifiés une faille du générateur aléatoire.
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
Sylvain
johann.d wrote on 04/01/2008 15:59:
Bonjour et bonne année...
bonne année Johann !
Résumé très grossier en français : deux chercheurs ont disséqué la puce Mifare pour tenter de casser l'algorithme d'authentification et de chiffrement (Crypto1, algorithme propriétaire Philips, vieux de plus de 10 ans et utilisant des clés de 48 bits). Ils auraient entre autre choses identifiés une faille du générateur aléatoire.
ce n'est pas un scoop je n'ai jamais fait bcp d'effort pour comprendre les détails de Mifare, mais:
existe-t-il encore des raisons fortes d'utiliser de telles puces plutôt qu'une puce 3DES et ISO 14443 A ou B ? (hormi les pbs de migration d'une vaste flotte évidemment).
le cout du chip ne me parait plus un obstacle (mais je serais p.e. sorti du prix d'un tag mifare) quant aux lecteurs les prix sont (encore plus certainement) comparables.
Sylvain.
johann.d wrote on 04/01/2008 15:59:
Bonjour et bonne année...
bonne année Johann !
Résumé très grossier en français : deux chercheurs ont disséqué la puce
Mifare pour tenter de casser l'algorithme d'authentification et de
chiffrement (Crypto1, algorithme propriétaire Philips, vieux de plus de 10
ans et utilisant des clés de 48 bits). Ils auraient entre autre choses
identifiés une faille du générateur aléatoire.
ce n'est pas un scoop je n'ai jamais fait bcp d'effort pour comprendre
les détails de Mifare, mais:
existe-t-il encore des raisons fortes d'utiliser de telles puces plutôt
qu'une puce 3DES et ISO 14443 A ou B ? (hormi les pbs de migration d'une
vaste flotte évidemment).
le cout du chip ne me parait plus un obstacle (mais je serais p.e. sorti
du prix d'un tag mifare) quant aux lecteurs les prix sont (encore plus
certainement) comparables.
Résumé très grossier en français : deux chercheurs ont disséqué la puce Mifare pour tenter de casser l'algorithme d'authentification et de chiffrement (Crypto1, algorithme propriétaire Philips, vieux de plus de 10 ans et utilisant des clés de 48 bits). Ils auraient entre autre choses identifiés une faille du générateur aléatoire.
ce n'est pas un scoop je n'ai jamais fait bcp d'effort pour comprendre les détails de Mifare, mais:
existe-t-il encore des raisons fortes d'utiliser de telles puces plutôt qu'une puce 3DES et ISO 14443 A ou B ? (hormi les pbs de migration d'une vaste flotte évidemment).
le cout du chip ne me parait plus un obstacle (mais je serais p.e. sorti du prix d'un tag mifare) quant aux lecteurs les prix sont (encore plus certainement) comparables.
Sylvain.
johann.d
"Sylvain" a écrit dans le message de news:47940434$0$880$
johann.d wrote on 04/01/2008 15:59:
Bonjour et bonne année...
bonne année Johann !
Bonjour et de même.
ce n'est pas un scoop je n'ai jamais fait bcp d'effort pour comprendre les détails de Mifare, mais:
D'autant plus que les détails sont plutôt difficiles à obtenir, NXP (Philips) vend d'un côté des cartes Mifare et de l'autre des composants (MfRC) qui incluent la crypto propriétaire associée, les entreprises qui ont acheté une licence pour faire leurs propres cartes ou leurs propres composants compatibles doivent se compter sur les doigts d'une main.
existe-t-il encore des raisons fortes d'utiliser de telles puces plutôt qu'une puce 3DES et ISO 14443 A ou B ? (hormi les pbs de migration d'une vaste flotte évidemment).
Les flottes sont effectivement très vastes. Maintenant, je vois au moins trois raisons qui font qu'on lance encore aujourd'hui de nouveaux projets sur cette techno :
- dans 90% des applications de ces cartes, on peut sans aucun problème se contenter d'une carte à crypto faible voire sans crypto du tout (lisible en clair, tant qu'on n'a pas de contrainte de confidentialité). Tout ce qu'il faut c'est faire confiance à l'unicité des numéros de série (après l'application utilise soit une liste de numéros autorisés, soit une signature statique stockée sur la carte pour vérifier qu'elle est authentique, sans aucune considération d'authentification dynamique).
- le composant MfRC est le seul SAM immédiatement disponible sur le marché et accessible au commun des développeurs (c'est un peu de la provocation de dire ça abruptement comme ça, mais je suis prêt à étayer dans un très long développement s'il le faut...). De plus il est déjà physiquement placé dans le lecteur, et l'application n'a pas à s'en soucier, ce qui n'est pas négligeable.
- la plupart des prescripteur et les intégrateurs de solutions "carte sans contact" n'ont qu'une faible culture sécurité. Pour faire un parallèle avec le monde de la carte à contacts, on peut dire sans caricaturer qu'ils se contenteraient des caractéristique d'une SLE 4442 pour l'essentiel de leurs applications.
le cout du chip ne me parait plus un obstacle (mais je serais p.e. sorti du prix d'un tag mifare) quant aux lecteurs les prix sont (encore plus certainement) comparables.
C'est de moins en moins cher chaque jour... Pour ce qui est des lecteurs, il faut préciser ce dont on parle :
- si le lecteur (coupleur) est un dispositif passif entre la carte et l'application, tout va bien on sait faire de moins en moins cher année après année,
- si le lecteur (re)devient un dispositif actif qui intègre au moins une partie de l'application (c'est le cas notamment des lecteurs Mifare qui grâce au composant MfRC stockent les clés et prennent en charge la crypto), alors il faut lui adjoindre un SAM, sécuriser la liaison côté host, etc, les impacts sont lourds.
-- johann.d
"Sylvain" <noSpam@mail.net> a écrit dans le message de
news:47940434$0$880$ba4acef3@news.orange.fr...
johann.d wrote on 04/01/2008 15:59:
Bonjour et bonne année...
bonne année Johann !
Bonjour et de même.
ce n'est pas un scoop je n'ai jamais fait bcp d'effort pour comprendre
les détails de Mifare, mais:
D'autant plus que les détails sont plutôt difficiles à obtenir, NXP
(Philips) vend d'un côté des cartes Mifare et de l'autre des composants
(MfRC) qui incluent la crypto propriétaire associée, les entreprises qui ont
acheté une licence pour faire leurs propres cartes ou leurs propres
composants compatibles doivent se compter sur les doigts d'une main.
existe-t-il encore des raisons fortes d'utiliser de telles puces plutôt
qu'une puce 3DES et ISO 14443 A ou B ? (hormi les pbs de migration d'une
vaste flotte évidemment).
Les flottes sont effectivement très vastes. Maintenant, je vois au moins
trois raisons qui font qu'on lance encore aujourd'hui de nouveaux projets
sur cette techno :
- dans 90% des applications de ces cartes, on peut sans aucun problème se
contenter d'une carte à crypto faible voire sans crypto du tout (lisible en
clair, tant qu'on n'a pas de contrainte de confidentialité). Tout ce qu'il
faut c'est faire confiance à l'unicité des numéros de série (après
l'application utilise soit une liste de numéros autorisés, soit une
signature statique stockée sur la carte pour vérifier qu'elle est
authentique, sans aucune considération d'authentification dynamique).
- le composant MfRC est le seul SAM immédiatement disponible sur le marché
et accessible au commun des développeurs (c'est un peu de la provocation de
dire ça abruptement comme ça, mais je suis prêt à étayer dans un très long
développement s'il le faut...). De plus il est déjà physiquement placé dans
le lecteur, et l'application n'a pas à s'en soucier, ce qui n'est pas
négligeable.
- la plupart des prescripteur et les intégrateurs de solutions "carte sans
contact" n'ont qu'une faible culture sécurité. Pour faire un parallèle avec
le monde de la carte à contacts, on peut dire sans caricaturer qu'ils se
contenteraient des caractéristique d'une SLE 4442 pour l'essentiel de leurs
applications.
le cout du chip ne me parait plus un obstacle (mais je serais p.e. sorti
du prix d'un tag mifare) quant aux lecteurs les prix sont (encore plus
certainement) comparables.
C'est de moins en moins cher chaque jour... Pour ce qui est des lecteurs, il
faut préciser ce dont on parle :
- si le lecteur (coupleur) est un dispositif passif entre la carte et
l'application, tout va bien on sait faire de moins en moins cher année après
année,
- si le lecteur (re)devient un dispositif actif qui intègre au moins une
partie de l'application (c'est le cas notamment des lecteurs Mifare qui
grâce au composant MfRC stockent les clés et prennent en charge la crypto),
alors il faut lui adjoindre un SAM, sécuriser la liaison côté host, etc, les
impacts sont lourds.
"Sylvain" a écrit dans le message de news:47940434$0$880$
johann.d wrote on 04/01/2008 15:59:
Bonjour et bonne année...
bonne année Johann !
Bonjour et de même.
ce n'est pas un scoop je n'ai jamais fait bcp d'effort pour comprendre les détails de Mifare, mais:
D'autant plus que les détails sont plutôt difficiles à obtenir, NXP (Philips) vend d'un côté des cartes Mifare et de l'autre des composants (MfRC) qui incluent la crypto propriétaire associée, les entreprises qui ont acheté une licence pour faire leurs propres cartes ou leurs propres composants compatibles doivent se compter sur les doigts d'une main.
existe-t-il encore des raisons fortes d'utiliser de telles puces plutôt qu'une puce 3DES et ISO 14443 A ou B ? (hormi les pbs de migration d'une vaste flotte évidemment).
Les flottes sont effectivement très vastes. Maintenant, je vois au moins trois raisons qui font qu'on lance encore aujourd'hui de nouveaux projets sur cette techno :
- dans 90% des applications de ces cartes, on peut sans aucun problème se contenter d'une carte à crypto faible voire sans crypto du tout (lisible en clair, tant qu'on n'a pas de contrainte de confidentialité). Tout ce qu'il faut c'est faire confiance à l'unicité des numéros de série (après l'application utilise soit une liste de numéros autorisés, soit une signature statique stockée sur la carte pour vérifier qu'elle est authentique, sans aucune considération d'authentification dynamique).
- le composant MfRC est le seul SAM immédiatement disponible sur le marché et accessible au commun des développeurs (c'est un peu de la provocation de dire ça abruptement comme ça, mais je suis prêt à étayer dans un très long développement s'il le faut...). De plus il est déjà physiquement placé dans le lecteur, et l'application n'a pas à s'en soucier, ce qui n'est pas négligeable.
- la plupart des prescripteur et les intégrateurs de solutions "carte sans contact" n'ont qu'une faible culture sécurité. Pour faire un parallèle avec le monde de la carte à contacts, on peut dire sans caricaturer qu'ils se contenteraient des caractéristique d'une SLE 4442 pour l'essentiel de leurs applications.
le cout du chip ne me parait plus un obstacle (mais je serais p.e. sorti du prix d'un tag mifare) quant aux lecteurs les prix sont (encore plus certainement) comparables.
C'est de moins en moins cher chaque jour... Pour ce qui est des lecteurs, il faut préciser ce dont on parle :
- si le lecteur (coupleur) est un dispositif passif entre la carte et l'application, tout va bien on sait faire de moins en moins cher année après année,
- si le lecteur (re)devient un dispositif actif qui intègre au moins une partie de l'application (c'est le cas notamment des lecteurs Mifare qui grâce au composant MfRC stockent les clés et prennent en charge la crypto), alors il faut lui adjoindre un SAM, sécuriser la liaison côté host, etc, les impacts sont lourds.
