Est-ce une mauvaise pratique de conserver des certificats sur la mémoire externe?

Nous travaillons sur AWS-IoT à l'aide d'un microcontrôleur STM32.

Jusqu'à aujourd'hui, nous écrivions les certificats sur le flash et bloquions le flash de la lecture externe. Au fur et à mesure que le code d'application augmente, nous obtenons moins d'espace sur le flash.Nous prévoyions donc de déplacer le certificat en externe sur une carte SD / EEPROM et de le lire chaque fois que cela était nécessaire avant de se connecter à AWS-IoT.

Remarques:

• La politique écrite pour la chose permettra uniquement aux appareils avec des noms particuliers de se connecter sur ce certificat particulier.

• La chose est autorisée à publier sur seulement 2 canaux (c'est le nom et un canal de flux de données) qui est connecté à un processeur de données qui ignorera tous les paquets malveillants qui y arrivent.

• Si la chose publie / s'abonne à un autre sujet, AWS la déconnectera immédiatement.

Si je détecte qu'un appareil est volé / escroc, nous désactivons la clé du serveur.

Que peut faire un exploiteur avec les certificats (RootCA, clé serveur, clé client)?

Est-ce une mauvaise pratique de conserver des certificats pour une telle utilisation sur un stockage externe auquel un exploiteur peut accéder?

Vous parlez de «certificats», mais d'après le contexte, je pense que vous faites référence à deux choses différentes.

• Votre appareil possède une clé privée , unique à cet appareil et non connue à l'extérieur de l'appareil. Cette clé identifie votre appareil. Quiconque peut accéder à cette clé peut usurper l'identité de l'appareil. Cela signifie qu'ils peuvent notamment:

  • Publiez des données valides mais incorrectes sur les canaux sur lesquels votre appareil est légitimement autorisé à publier.
  • Publiez des données non valides qui interdiront l'appareil légitime.
  • Il est possible, selon le cas d'utilisation, d'exposer certaines informations privées du propriétaire de l'appareil.

  Cette clé privée ferait mieux de rester confidentielle.

• Votre appareil possède probablement au moins une clé publique , ce qui lui permet de reconnaître à quels serveurs il parle. C'est bon si quelqu'un peut lire cette clé: c'est public. Mais un attaquant ne devrait pas pouvoir modifier la clé. Sinon, ils pourraient communiquer avec le périphérique et emprunter l'identité du serveur. Cela pourrait leur permettre de faire des choses comme:

  • Envoyez une mise à jour du micrologiciel à l'appareil.
  • Envoyez une mise à jour de configuration à l'appareil.
  • Faites en sorte que l'appareil télécharge ses données vers un autre emplacement.

La bonne nouvelle est que cette analyse des menaces n'est en fait pas très pertinente. Vous n'avez pas besoin de sacrifier de sécurité ! (Au moins, pas de propriétés de confidentialité et d'authenticité - si vous stockez des éléments en externe, la disponibilité est alors mise à mal, car c'est une partie du système qui pourrait disparaître.)

Tant que vous disposez d'au moins 128 bits de stockage sur lesquels vous pouvez écrire au moins une fois, ce que vous avez et plus, vous pouvez implémenter une solution de stockage à distance sécurisée. Utilisez le stockage sur périphérique à espace limité pour stocker une clé secrète. Cette clé secrète doit être unique par appareil; le STM32 possède un RNG matériel, vous pouvez donc le générer sur l'appareil lors du premier démarrage. Si votre appareil n'avait pas de RNG matériel, vous pouvez générer la clé dans un emplacement sécurisé hors appareil et l'injecter sur l'appareil.

Avec cette clé, utilisez le cryptage authentifié pour les choses que vous stockez sur l'appareil. Lorsque vous souhaitez lire certaines données du stockage externe, chargez-les, déchiffrez-les et vérifiez-les. Lorsque vous souhaitez écrire des données sur un stockage externe, chiffrez-les et signez-les. Cela garantit que les données sont aussi confidentielles et authentiques que les données du stockage interne.

Le chiffrement authentifié suffit à garantir la confidentialité et l' authenticité des données, mais il ne garantit pas tout à fait leur intégrité .

• S'il y a plus d'un bloc de données, alors lorsque l'appareil lit un bloc de données, il ne peut pas être sûr qu'il s'agit du bloc correct. Solution: inclure un identifiant unique dans le contenu de chaque morceau (par exemple commencer chaque morceau avec l' un "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• Si vous mettez à jour les données à un moment donné, lorsque vous les relisez, vous ne pouvez pas être sûr d'obtenir la dernière version de ces données. Si quelqu'un peut modifier le stockage externe, il ne peut pas mettre de fausses données car cela échouerait au contrôle d'authenticité, mais il peut restaurer les anciennes données, car ce qui était authentique est toujours authentique. Solution: dans chaque bloc de données stocké en externe, incluez un compteur que vous incrémentez chaque fois que vous écrivez une nouvelle version de ce bloc. Lorsque vous lisez un morceau, vérifiez qu'il s'agit de la version attendue.

Pour éviter de bricker un appareil dans le cas où le stockage externe est endommagé ou perdu, dans l'espace limité dont vous disposez sur le stockage interne, vous devez donner la priorité à tout ce qui est nécessaire pour réinitialiser l'appareil à un «bon» état, par exemple une réinitialisation d'usine . La deuxième priorité sera les considérations de performances.

Un peu de contexte

Étant donné que vous utilisez MQTT avec AWS IoT, vous êtes censé utiliser des certificats X.509 pour l'authentification et la sécurité. Amazon a un peu de conseils sur la façon dont vous devez sécuriser vos certificats, je vais donc le citer ici:

Les certificats permettent aux clés asymétriques d'être utilisées avec les appareils. Cela signifie que vous pouvez graver des clés privées dans un stockage sécurisé sur un appareil sans jamais autoriser le matériel cryptographique sensible à quitter l'appareil.

Étant donné que vous utilisez actuellement la protection contre la lecture (RDP) de STM32 , tous les attaquants, à l'exception des plus déterminés, auront du mal à accéder à vos certificats dans votre schéma actuel:

La protection globale contre la lecture permet au code du micrologiciel intégré (préchargé dans la mémoire Flash) de se protéger contre l'ingénierie inverse, le vidage à l'aide d'outils de débogage ou d'autres moyens d'attaque intrusive.

• Niveau 0 - Aucune protection (par défaut)
• Niveau 1 - La mémoire flash est protégée contre la lecture par le débogage ou le vidage de code par le code chargé en RAM
• Niveau 2 - Toutes les fonctionnalités de débogage sont désactivées

Le stockage externe va-t-il être sécurisé?

Ce n'est probablement pas aussi sûr . Si la clé privée de votre client est volée, un attaquant peut envoyer des données qui semblent provenir de votre appareil, alors qu'elles ne le sont pas. Bien que les données que vous envoyez ne soient pas claires, toutes les données non fiables peuvent constituer un risque pour la sécurité.

Quels bits dois-je garder confidentiels?

Lorsque vous créez un certificat d'appareil sur AWS IoT, vous devriez voir une image comme celle-ci:

^{Image de la page Créer et activer un certificat de périphérique de la documentation AWS IoT.}

La clé privée est la chose que vous devez vraiment garder ... privée , et devrait certainement être stockée dans la mémoire protégée en lecture si possible. La clé publique et le certificat sont conçus pour être partagés, donc si vous manquez d'espace, vous pouvez les déplacer en toute sécurité vers un stockage externe. Vous pouvez obtenir un peu plus de contexte sur la page Comment fonctionne SSL / TLS? sur Information Security Stack Exchange et cryptographie à clé publique sur Wikipedia. Je pense que je vous rendrais un mauvais service si je n'incluais pas cette image pour expliquer pourquoi la clé privée doit être secrète:

.

^{Image de Wikipedia , publiée dans le domaine public.}

La clé publique de votre appareil est ce qu'AWS IoT utilise pour signer les messages à envoyer à votre appareil (mais cela ne prouve pas qui envoie le message ). Donc, vraiment, ce n'est pas un énorme désastre si quelqu'un vole la clé publique, car ce n'est pas censé être un secret.

La clé privée est ce que votre appareil utilise pour déchiffrer les messages, c'est donc un problème légèrement plus important si un attaquant vole cela.

Vous avez également demandé ce qui se passerait si l'attaquant volait le certificat RootCA. Si quelqu'un volait la clé privée d'AWS IoT , ce serait désastreux, mais le certificat RootCA sur votre appareil ne l'est pas . Ce RootCA.crtque Amazon vous donne est complètement public , et le but est de vous permettre de vérifier que vous n'êtes pas attaqué de quelque manière que ce soit (probablement un homme du milieu se faisant passer pour les serveurs d'AWS IoT).

Quels dommages un appareil piraté pourrait-il faire?

Votre appareil volé ne peut effectuer que les actions répertoriées dans la politique . Essayez de suivre le principe du moindre privilège ; accordez uniquement à votre appareil les privilèges dont il a absolument besoin , donc si le pire se produit, il ne peut pas faire trop de ravages. Pour votre cas spécifique:

La chose est autorisée à publier sur seulement 2 canaux (son nom et un canal d'alimentation de données) qui est connecté à un processeur de données qui ignorera tous les paquets malveillants qui lui parviennent.

C'est bon. Toute attaque doit être isolée uniquement des deux sujets MQTT sur lesquels l'appareil peut publier, afin de ne pas causer de dommages à grande échelle.

Idéalement, vous voulez que votre système global ait une conception telle que la dissection d'une seule unité ne brise que cette unité, et non le système en général.

Surtout si vous stockez des clés dans une mémoire distincte de sorte qu'elles traversent une interface électrique standard entre les puces, elles ne devraient être que des clés qui sont déjà sûres à publier ou uniques à cette instance physique particulière de l'appareil.

Si une clé individuelle est extraite d'un seul appareil et commence à être utilisée abusivement ou à apparaître dans un volume de trafic qui doit provenir de plusieurs clones non autorisés, vous pouvez interdire cette clé côté serveur.

Vos clés devraient bien sûr avoir la propriété de ne pas être quelque chose qu'une partie non autorisée peut deviner à partir de quelques exemples extraits ou générer leurs propres instances compatibles d'origine - c'est-à-dire que vous avez besoin d'un enregistrement des clés que vous avez générées là où celles qui sont valides sont seulement une petite partie imprévisible d'un immense espace de possibilités, ou bien vous devez signer les clés que vous générez et faire en sorte que votre système n'accepte qu'une clé en combinaison avec sa preuve de signature.

Vous devez essayer de garder le secret de la clé client (mais comprendre l'implication de la perdre (1), comme décrit dans les autres réponses). La clé publique du serveur et le certificat public AWS sont importants à sécuriser à la fin de l'appareil non pas parce que vous souhaitez garder le secret, mais parce qu'en remplaçant le certificat AWS (sur un appareil compromis), un attaquant peut persuader l'appareil d'effectuer une échangez avec l'hôte de l'attaquant, ou à l'homme du milieu vos communications avec AWS.

En procédant ainsi (2), un attaquant peut supprimer la sécurité TLS, ce qui peut entraîner une réduction suffisante de la sécurité afin qu'il puisse effectuer une rétro-ingénierie de la clé client.

Par ce raisonnement, la seule clé qu'il est sûr d'exposer dans un périphérique de mémoire externe est la clé publique du serveur. La modification de cette (3) ne permettrait qu'à votre appareil d'être obligé de se connecter à un service AWS escroc auquel il est probablement difficile d'accéder par l'ingénieur. Même une simple fuite de cette clé pourrait permettre à quelqu'un d'espionner ou de simuler certaines transmissions (par exemple, si la couche TLS peut être rétrogradée d'une manière ou d'une autre).

Donc, en résumé, le risque ne réside pas simplement dans la fuite d'informations, il existe un risque si le micrologiciel (supposé fiable) peut être fourni avec des informations sécurisées non fiables.