Question:
Communication sécurisée sur la bande amateur HSMM / 802.11 aux États-Unis
Mike Pennington
2013-10-23 05:40:33 UTC
view on stackexchange narkive permalink

Je suis assez intéressé par le 802.11 sur les fréquences radio amateur; cependant, tout ce que j'ai fait à ce stade est la lecture (je n'ai pas encore de licence de jambon). La sagesse conventionnelle (adoptée dans cette réponse ham.SE) est que vous ne pouvez pas du tout crypter les communications radio. Cette limitation semble aller à l'encontre des contre-mesures normales utilisées pour sécuriser les transferts de données via Internet.

Le cryptage est donc hors de propos; cependant, cela laisse encore des problèmes tels que l'authentification et l'intégrité des données. J'ai lu que les hachages CRAM-MD5 sont parfois utilisés dans le cadre des services de données implémentés sur la radio amateur 802.11, car les hachages CRAM-MD5 sont autorisés selon les règles de la FCC. Le contenu des messages signés avec CRAM-MD5 est toujours visible; cependant, la paternité du message peut être vérifiée (car CRAM-MD5 fonctionne de la même manière que PGP). Pour autant que je sache, l'utilisation de CRAM-MD5 vous rend vulnérable car:

  • Il n'effectue pas d'authentification mutuelle (c'est-à-dire que le client ne peut pas vérifier l'identité du serveur)
  • Il est possible d'exécuter des attaques par dictionnaire hors ligne contre les hachages capturés (bien que le hachage HMAC-MD5 sous-jacent ne présente pas les mêmes vulnérabilités que MD5 ).

Ce qui me préoccupe le plus, c'est l'attaque de l'homme au milieu, car CRAM-MD5 n'offre aucune authentification mutuelle entre le client et le serveur. Ce type de vulnérabilité est également le type de dynamique qui rend PEAP pire que l'absence d'authentification 802.11 (puisque PEAP n'applique pas l'authentification mutuelle entre le client wifi et le serveur RADIUS, comme le fait EAP-TLS). Il a été démontré que les clients PEAP faibles offrent librement leurs hachages de mot de passe à un AP wifi masquant le même SSID que le vrai AP. Mon souci avec le 802.11 sur les fréquences ham est de déterminer que je donne mon mot de passe / mes données au bon point de terminaison de l'autre côté (et non à un attaquant).

Questions

  • Existe-t-il un autre schéma d'authentification en plus de CRAM-MD5, qui est à la fois légal aux États-Unis et effectue une authentification mutuelle?
  • Si je souhaitais implémenter un service HTTP authentifié via ham radio, y a-t-il un autre schéma d'authentification que je devrais envisager en plus de CRAM-MD5?
Un répondre:
#1
+7
Amber
2013-10-23 05:50:17 UTC
view on stackexchange narkive permalink

Je dirais que votre meilleur pari est d'éviter de remettre entièrement votre mot de passe haché. Utilisez plutôt un schéma d ' authentification sans connaissance; consultez cette question security.SE pour plus de détails. L'authentification Zero Knowledge fera en sorte que peu importe à qui vous "donnez" votre réponse - même si un serveur malveillant demande une authentification (ou intercepte une autre authentification), il n'apprend rien sur votre mot de passe.

Si vous intégrez la réponse à l'authentification sans connaissance dans le cadre de la requête signée par clé publique, vous devriez être en mesure de formuler un système qui à la fois (a) est signé par le client et (b) révéler des informations à des tiers qui leur permettraient de falsifier de futures demandes, car la réponse au défi de connaissance zéro formerait un nonce.

En ce qui concerne la vérification du serveur, une signature de clé publique devrait suffire.


(Réponse précédente, avant la clarification du PO ...)

IANAL, mais ...

Il y a une différence entre cryptage et authentification . Le premier exige que personne ne puisse dire quelles données sont transmises; ce dernier n'exige que personne ne soit capable de produire quelque chose qui est accepté comme légitime sans certaines connaissances (non publiques).

Par exemple, les signatures à clé publique permettent l'authentification de l'expéditeur d'un message sans obscurcir le contenu du message.

Tant que vous êtes d'accord avec le contenu de vos demandes visible mais pas forgeable , vous pouvez probablement utiliser un système de clé publique sans enfreindre les règlements FCC.

Si, par contre, vous ne voulez pas que quiconque puisse voir ce qu'il y a dans vos demandes et réponses, vous n'avez pas de chance .

Encore une fois, IANAL.

Salut Ambre, merci pour ta réponse. Cependant, je suis tout à fait conscient des différences entre l'authentification et le cryptage. Ma préoccupation (que j'ai clarifiée dans une modification pendant que vous construisiez votre réponse) est de savoir si je donne mon mot de passe haché PKI au bon serveur. Est-ce que ça a du sens? EDIT: Ugg, maintenant je comprends pourquoi vous avez répondu comme vous l'avez fait ... mea culpa ... J'ai supprimé le mot sur la rotation des mots de passe.
Je t'ai eu. Permettez-moi de modifier ma réponse.
Réponse mise à jour, faites-moi savoir si cela aide.
Je digère toujours les exigences de l'authentification zéro connaissance (ZKA) ... tout cela semble assez abstrait pour le moment. Cela aiderait si je trouvais un code client / serveur (ou pseudo code) qui illustre comment cela fonctionne dans la pratique
Hm. C'est encore un peu académique, mais il y a un exemple de pseudocode dans cet article: http://www.cs.nyu.edu/~zaremba/docs/zkp.pdf
En fait, je lisais juste ça ... merci


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...