Jump to content
Sign in to follow this  
DSpot

NFC et amitilé

Recommended Posts

Bonsoir,

Je viens de me rendre compte que le Nexus S que je viens de commander a la capacité de communiquer en NFC.

Je suis actuellement dans une université qui utilise des cartes d'étudiants et une identification par RFID pour ouvrire les portes et payer à la caf. De plus, je ne pense pas me tromper en disant que les cartes de métro utilise aussi ce système (je suis Suisse, donc je sais pas, on a pas ça ici).

Est-ce que ce NFC dans le NS serait aussi lecteur???

Non mais je ne sais pas si vous vous rendez compte de la chose : loin de moi l'envie de pousser à l'illégalité, mais ma carte étudiante contient de l'argent (en fait, c'est le centre de contrôle qui sait que j'ai de l'argent, ma carte ne contient qu'une puce qui envoie mon identifiant). Une personne mal intentionné qui prendrait ma carte et qui l'approcherait de son NS pourrait copier mon empreinte RFID et utiliser son téléphone pour payer à la caisse avec mon argent! (comme si ma carte avait été volé).

Je suis presque sûr que le NFC est compatible avec tous les types de RFID et qu'il peut être utiliser en mode lecteur (cf ici). Donc quelqu'un qui prendrait un abonnement de métro pourrait le "partager" (bon gré mal gré) avec une personne qui n'en a pas... Pire, si vous avez une carte de crédit avec un telle système!

J'ai peur de comprendre la porté d'un tel lecteur sur nos empruntes virtuelles...

Edited by DSpot

Share this post


Link to post
Share on other sites

NFC et RFID sont légerement différents.

De plus le nexus S ne peut que lire, il ne peut pas emettre.

Share this post


Link to post
Share on other sites

Bon, j'avoue avoir faire des recherches que hier soir à ce sujet... Donc, ce que j'en ai retenu, c'est que :

  • un RFID ne peut être que lu par un appareil lui envoyant des ondes (l'énergie) pour émettre ce pourquoi il a été programmé et construit. Il ne peut donc par changer de signature durant sa vie.
  • un NFC peut lire les RFID en étant justement cette source d'énergie et en envoyant la longueur d'onde approprié (il y a plusieurs fréquences, mais le NFC est capable de toutes les couvrires)
  • un NFC est un émetteur-récepteur. C'est un des argument de vente du NS : sa capacité à communiquer avec des objets ou des appareils à courte distance, notamment en envoyant sa carte de visite par simple juxtaposition de deux téléphones équipés. Donc, c'est aussi un émetteur.

Après, je me trompe peut-être. C'est peut-être utilisé que comme déclencheur de Bluetooth, qui à son tour émet les informations (dans ce cas, c'est évident qu'il ne peut pas avoir de communication avec d'autres bornes lecteurs de RFID). Mais au vu des Wikis et d'autres sites, j'ai vraiment l'impression que ce que j'avance est possible... Peut-être qu'un bridage matérielle a été fait pour justement éviter cela, mais quoi qu'il en soit, il ne peut être que logiciel (puisqu'il émet et réceptionne).

Je fais vraiment totalement fausse route et fais une crise de paranoïa seul dans mon coin ou il y a un tant soit peu de vérité dans mes propos?

Edited by DSpot

Share this post


Link to post
Share on other sites

Il peut émettre, seulement que Google ne l'a pas encore 'totalement' développé. D'après eux, c'est en étude.

Share this post


Link to post
Share on other sites

Bon, comme je le pensais, c'est réellement dangereux (voir un topic chez xda ici) Tout ce que j'avançais était plus ou moins fondé.

Plus qu'à trimbaler ces cartes avec des RFID dans de petites boites en aluminium.

@griphine : Alors Google développe de son côté pour nous proposer une expérience sympa, mais moi, je parle de ce que les hackers pourraient faire (et en effet, ils s'y sont déjà attelés... tu m'étonnes...)

Pour l'instant je n'ai pas encore trouvé ce genre d'application courir sur la toile, mais ça risque d'arrivé très prochainement...

Share this post


Link to post
Share on other sites

j'ai tout de même un gros doute qu'on puisse exploiter une puce RFID "critique" en claquant des doigts. Pas de cryptage ? rien ? je doute fort.

De plus, c'est comme tout, il y a toujours des "failles" quelque part. Ta CB tu te la fait tiré t'es ruiné, ton pass navigo pareil, etc. Si les concepteur de puce RFID n'ont rien sécurisé tant pis, fallait y penser, depuis le temps qu'on parle de paiement "contactless" c'était à prévoir que ça allait pas tarder à sortir. Mais encore une fos, je doute fort qu'il soit simple de faire ce genre de chose.

Share this post


Link to post
Share on other sites

des lecteur RFID programmables, ca se trouve dans le commerce pour 50 fois moins cher qu un nexus, laisse google tranquille :-p

moi je continue de lire la doc du sdk pour lire le tag de mon passeport, mais ca ne semble pas accessible.

Edit: et aparemment il y aura moyen de jouer avec: http://www.flyertalk.com/forum/travel-safety-security/527150-global-rfid-passport-encryption-standard-cracked-2-hours.html

Share this post


Link to post
Share on other sites

@ verbalinsurection : tu as raison, on dirait que c'est crypté... Mais ce n'est pas plus rassurent que ça... (cf la suite)

@ Profete162 : ah bah du coup... plus de ouf... hum... j'ai pas lu tout ce qui est écrit dans ton lien, mais j'ai beau chercher, je ne trouve nul part la méthode de cryptage... Voilà ce que j'ai compris :

  • Le lecteur (ici le NFC) envoie une onde de longuer de 13.56GHz pour exciter la puce RFID
  • La puce, une fois excitée, émet ce pourquoi elle a été produite : une information de 96 bits.
  • Cette info est lu par le lecteur et est transformé en URL, carte de visite, etc... pour être utilisé

S'il y a cryptage, je ne vois pas à quel moment, car le cryptage signifierait que le RFID émettrait des informations de 96 bits DIFFERENTES à chaque demande de lecture (en prenant comme variable aléatoire un algorithme avec le temps, par exemple). Hors, cela est impossible! Pour plusieurs raisons : il n'y a pas d'énergie interne dans la RFID, ce qui l’empêche d'avoir une horloge et donc de se synchroniser. De plus, le RFID est une information statique, et ne pourra jamais changer de valeur durant une vie! (d'où de gros doute sur des cartes RFID programmable... j'ai aussi lu ça quelque par, mais c'était des cartes justement qui aurait besoin de se modifier dans une vie, ce qui n'est pas le cas des cartes de métro, de crédits etc...)

Donc dès le moment qu'on arrive à créer un programme qui n'essaie pas de "comprendre" ce que sont ces 0 et ces 1, mais qui arrive à les imiter, c'est fini : on a dupliqué la carte et le centre de contrôle qui lira cette carte sera dupé car il croira lire une carte à identifiant unique alors que c'est une copie...

Pour résumé, je ne vois pas l'utilité de "comprendre" le cryptage ou l'info de la RFID. Il suffit de dupliquer cette information. Car ça n’intéresse pas les hackers de savoir à qui appartient cette carte, mais ils veulent simplement l'utiliser... Et en la dupliquant, ils en sont capables.

SVP prouvez moi le contraire, dites moi que je me trompe et dites moi pourquoi et/ou où je peux trouver l'info. Merci!

Share this post


Link to post
Share on other sites

Voici ce que j'ai trouvé dans ce document :

http://actes.sstic.org/SSTIC06/RFID_et_securite/SSTIC06-article-Avoine-RFID_et_securite.pdf

Le standard EPG Global de deuxième génération distingue quatre classes de tags. La classe 1 correspond aux tags les moins performants et donc les moins chers. Ils sont dotés d’une mémoire accessible en lecture seulement, qui contient un identifiant unique (typiquement 128 bits). Lorsque le tag est interrogé par un lecteur, il envoie simplement son identifiant. Les tags de classe 1 se trouvent dans les bibliothèques, les chaînes logistiques, etc. La classe 2 permet d’implémenter des fonctions sur le tag, typiquement un algorithme cryptographique symétrique et de posséder quelques centaines de bits de mémoire ré-inscriptible. Cependant, les tags des classes 1 et 2 sont passifs c’est-à-dire qu’il ne possèdent pas de batterie et doivent donc être présents dans le champ du lecteur pour communiquer et effectuer des calculs

Il y a 2 autres classes supérieurs, qui permettent de faire encore plus de chose, mais la classe 2 semble suffire à effectuer un cryptage des données.

L'émetteur doit sans doute envoyer une information (l'heure, un identifiant, etc.) qui est stocké dans la mémoire de la puce. Ces informations doivent ensuite être utilisées pour crypter l'informations inscrite sur la puce, puis le résultat est envoyé à l'émetteur (128 bits).

Je n'ai pas le temps de lire la suite, mais peut-être que ce document te donnera de plus amples informations.

Share this post


Link to post
Share on other sites

Wahou! Parfait! Je l'ai lu, c'est exactement ce que je cherchait! Bon, je suis rassuré^^ Merci pour cet article, si t'en as d'autres, n'hésite surtout pas!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  





×
×
  • Create New...