Évaluation de la sécurité d'une implémentation SSL/TLS héritée sur un appareil IoT
Je fais une évaluation de sécurité sur la sécurité des communications d'un ancien appareil IoT. L'objectif est d'évaluer et de trouver les failles de sécurité dans la conception/mise en œuvre actuelle.
Le mode d'évaluation est manuel, principalement avec la référence de la conception et du code existants. C'est uniquement côté client sur l'appareil ; tandis que le serveur est un serveur basé sur le cloud. L'appareil utilise un module GSM (SIMCom SIM900) et établit une communication HTTPS avec le serveur via Internet à l'aide des commandes GSM AT.
Sur la base de ma compréhension de SSL/TLS, j'envisage les paramètres ou critères ci-dessous pour cette évaluation :
un. Version du protocole TLS
b. Suites de chiffrement utilisées
c. gestion des certificats et des clés
ré. Autorités de certification racine installées sur l'appareil
e. Aspect PKI intégré pour la gestion de l'identité des appareils
F. Aspect crypto matériel (SHE/TPM)
Est-ce que je le fais de la bonne manière ? Bien que je pense que la liste de paramètres ci-dessus n'est pas spécifique à la plate-forme Device HW/SW ; plutôt générique. mais je suppose que c'est comme ça que ça devrait être! Je veux dire que la liste des paramètres sera à peu près la même; Cependant, l'évaluation réelle de ceux-ci dépendra des exigences de sécurité et d'autres aspects tels que l'empreinte de l'appareil et sa plate-forme, etc.
La liste des paramètres d'évaluation que je considère est-elle bonne et adéquate ?
Réponses
C'est un bon début, mais une évaluation approfondie nécessiterait d'aller beaucoup plus loin que cela. Par exemple:
Comment le client génère-t-il des nombres aléatoires ? Utilise- t-il un CSPRNG ? Ou utilise-t-il un générateur de nombres aléatoires faible, comme celui utilisé dans les premières versions de Netscape Navigator , où un attaquant passif pouvait deviner les nombres aléatoires générés pour les clés de session, et ainsi déchiffrer le texte chiffré passant sur le réseau.
Le client divulgue-t-il des informations lorsqu'il rencontre une erreur de remplissage ? Si c'est le cas, il pourrait être sensible à une attaque d'oracle de rembourrage , comme ce fut le cas avec le client de jeu Steam .
Comment le client implémente -t-il ECDSA ? Le client génère-t-il un nouveau k aléatoire pour chaque signature qu'il crée ? Sinon, il peut être possible pour un attaquant passif de calculer la clé de signature privée après avoir observé quelques signatures, comme ce fut le cas avec la Playstation 3 de Sony .
Ce ne sont que quelques exemples. Mais, comme vous pouvez le voir, des erreurs subtiles dans la mise en œuvre de la cryptographie peuvent avoir des conséquences désastreuses. C'est pourquoi la cryptographie est si difficile à maîtriser.