Le SSL unidirectionnel peut-il sécuriser un appareil IoT?

9

J'envisage un appareil IoT connecté à mon réseau local (paramètres par défaut, pas de VPN, pas de NAT, pas de DMZ) avec ou sans accès à Internet. Mon appareil fonctionnera comme un serveur HTTP offrant un mécanisme RPC avec authentification et autorisation. Il s'annonce avec mDNS et je lui parle en utilisant mon application mobile ou mon RaspberryPi.

Il semble que la norme dans le développement de l'IoT soit d'avoir un SSL mutuel (bidirectionnel). Est-ce à dire que SSL unidirectionnel ne peut pas sécuriser mon trafic? Pourquoi?

Remarques:

Je comprends les différences techniques entre SSL unidirectionnel et bidirectionnel, je ne comprends pas pourquoi unidirectionnel (presque) n'est jamais pris en compte dans la production IoT.
Je comprends qu'il est difficile d'avoir un SSL mutuel pour un appareil local: vous devez partager la clé publique et le certificat du serveur au client et vice-versa. Unidirectionnel, en revanche, semble plus facile (ne nécessite aucune action de l'utilisateur).
Certains appareils produits en série comme Philips Hue préféreraient qu'un point de terminaison http local soit ouvert et non sécurisé plutôt qu'un cryptage SSL unidirectionnel. Pourquoi ferait-on ce choix?
Je m'attends à ce que cette question ne soit pas fondée sur l'opinion. Toutes mes excuses si tel est le cas.

— Valentin
source

8

SSL / TLS fonctionne bien lorsque le "serveur" est à un emplacement connu (un nom d'hôte fixe) qui peut correspondre au CN du certificat qu'il présente.

Cela ne fonctionne pas bien pour les appareils sur les réseaux domestiques (par exemple la plupart des appareils IoT) car ils ont tendance à obtenir des adresses IP émises à partir des blocs RFC1918 et n'ont pas d'entrées DNS. Cela signifie qu'ils ne peuvent pas être délivrés de certificats (bien qu'ils le peuvent, mais la plupart des navigateurs les rejetteront). C'est pourquoi des appareils comme Philips Hue utilisent des points de terminaison HTTP non sécurisés de l'appareil, ils dépendent essentiellement de l'accès au réseau sécurisé pour protéger l'appareil.

Lorsque le TLS mutuel est utilisé, c'est lorsque l'appareil se connecte à un service central, le client possède sa propre clé de certification / privée pour authentifier qu'il est capable d'agir au nom du propriétaire avec ce serveur central.

Pour clarifier votre question, vous n'avez pas besoin de distribuer le certificat / clé du serveur à tous les clients, seul le certificat de l'autorité de certification qui a émis le certificat est nécessaire pour prouver que le certificat est approuvé.

ÉDITER:

Un bon exemple de connexion sécurisée à un appareil local est l'éclairage Tradfri d'IKEA qui utilise COAP sur DTLS avec une clé pré-partagée (dans un code QR) sur l'appareil qui est utilisée pour générer une clé par client. Cela garantit un accès physique pour configurer un nouveau client et protège les données en vol sur le réseau local.

— hardillb
source

Si l'hôte ne se trouve pas à un nom DNS fixe ou à une adresse IP, la vérification normale du certificat échoue, car le certificat affirme que le périphérique à cette adresse est bien celui qu'il dit (SSL "simple face" normal). Pour SSL authentifié mutuellement, vous ne devez pas utiliser la même clé / certificat pour les deux parties. Le serveur et le client doivent avoir leur propre certificat / clé signé par une autorité de certification

— mutuelle de

Merci pour la réponse et désolé pour le long silence @hardillb. "Cela signifie qu'ils ne peuvent pas recevoir de certificats (ils le peuvent, mais la plupart des navigateurs les rejetteront)." Compte tenu d'une communication avec mon appareil IoT, je ne vois pas quand j'utiliserai un navigateur pour le faire ... "vous n'avez pas besoin de distribuer le serveur cert / clé à tous les clients, juste le certificat de l'AC" pour TLS unidirectionnel, correct? Parce que pour les mutuelles, je pense que vous devez donner le certificat et la clé, ce qui rend les choses beaucoup plus difficiles. En ce qui concerne Tradfri, la clé pré-partagée est destinée à l'authentification, pas au cryptage.

— valentin

Non, la clé pré-partagée tradrfi consiste à établir une poignée de main et à créer une clé par périphérique pour le chiffrement

— hardillb

1

En règle générale, TLS est bon pour bien plus que x.509, mais de nombreuses implémentations le limitent à seulement x.509.

x.509 est une technique pour une confiance indirecte sécurisée. "A" fait confiance à "B", si "B" a un certificat, qui est signé par "C" et "C" est approuvé par "A". Cela fonctionne aussi dans la vraie vie; vous faites confiance à quelqu'un que vous ne connaissez pas, si une lettre présentée est signée par une personne de confiance. Peut-être que vous voyez l'écueil: si la lettre le dit, donnez une tasse de café que vous ne donnerez pas à votre voiture. Par conséquent, les informations supplémentaires contenues dans le certificat sont également pertinentes pour l'étendue de l'approbation. C'est pourquoi un serveur a généralement son nom DNS ou son adresse IP dans son certificat. En général, vous pouvez inclure des informations différentes (par exemple, "lampe de salon"), mais de nombreuses implémentations sont également au moins préconfigurées pour utiliser / vérifier les éléments DNS / IP. Et tout cela ne fonctionne que si quelqu'un se soucie de la confiance "

Si vous pouvez y consacrer du temps, vérifiez votre implémentation, si elle propose également des suites de chiffrement PSK. Sinon, vous pouvez peut-être ajuster le "contrôle de validation" du certificat des serveurs. Mais il faut beaucoup de lecture pour trouver une bonne solution. Et parfois, l'implémentation TLS utilisée n'offre tout simplement pas cela.

— Achim Kraus
source