stockage et utilisation sécurisés des clés dans un système embarqué

J'utilise un microprocesseur - PIC32MZ2048efm144 MCU qui reçoit des commandes chiffrées avec une clé spécifique , les déchiffre et exécute la commande. Les commandes cryptées sont stockées hors ligne , donc je ne peux pas simplement changer la clé quand je veux. La clé est FIXE . Les commandes sont cryptées par un serveur et téléchargées par un téléphone . Le téléphone envoie les commandes cryptées au MCU ultérieurement, lorsqu'il n'est pas en ligne . Les commandes sont cryptées avant que le téléphone ne les communique au MCU, donc une clé de session n'est pas possible.

Je suis autorisé à connecter un module de cryptage / décryptage externe au PIC, mais les données passeront ensuite décryptées dans au moins une direction.

La solution apportée ici: Stockage d'une clé sécurisée dans la mémoire d'un appareil embarqué

utilise des clés à usage unique pour crypter, mais je dois stocker une seule clé super-secrète

Ce que mon employeur exige, c'est que les clés ne soient pas accessibles, donc la protection physique en plus de celle offerte par les modules de mémoire sécurisés et le MCU, n'est pas prise en compte.

En supposant qu'aucun équipement de qualité militaire n'est utilisé, y a-t-il des solutions connues que vous connaissez et pouvez recommander?

Merci d'avance!

— Sonja
source

Pouvez-vous expliquer davantage ce que vous essayez de prévenir? Que fait le microprocesseur? Pensez-vous que l'utilisation d'une clé publique / privée pourrait fonctionner? Si vous avez stocké la clé privée sur le microprocesseur? Ensuite, les appareils envoyant des commandes créeraient une clé de session, la chiffreraient à l'aide de la clé publique et vous l'enverraient. Après cela, les deux parties utilisent la clé de session. Que se passerait-il si un attaquant avait la clé publique (qui, même si elle est appelée "publique", n'a pas à être réellement publique)?

— mkeith

@mkeith J'ai mis à jour la question, j'espère que cela vous aidera :)

— Sonja

Puisque vous avez choisi ce PIC, pourquoi ne pas utiliser le "Stockage de clé sécurisé par programme" qu'il fournit? Il a son propre module de cryptage intégré!

— pjc50

Je ne pense pas que vous ayez clairement quantifié la valeur de votre secret. Il semble que vous vouliez une méthode bon marché et fiable (qui, je pense, est inconnue). Demandez des éclaircissements sur ce qui doit être possible après la découverte d'une vulnérabilité dans cette première solution. Les mises à jour du micrologiciel en direct signées seraient ma première fonctionnalité non négociable ... C'est un problème de système - toujours.

— Sean Houlihane

Eh bien, si la mémoire du PIC est protégée (et il a même un module de stockage de clés) pourquoi ne pas utiliser un simple cryptage AES? Je sais que c'est symétrique, mais si le serveur est sécurisé (ce que nous devons en quelque sorte assumer), il n'y a aucun risque ici - ou y a-t-il?

— Jan Dorniak

Réponses:

Je suis désolé, cette réponse ne résoudra pas réellement votre problème. Mais il est trop long pour tenir dans un commentaire, et il vous permettra de repenser votre problème de la bonne manière (car tel qu'il est, je pense qu'il est imparfait).

Ce type de problèmes doit être résolu en tenant compte de tous les composants du système et en faisant des hypothèses raisonnables sur ce qu'un pirate potentiel peut ou ne peut pas faire.

Par exemple:

Vous dites: "le PIC32MZ2048efm144 (MCU) reçoit des commandes chiffrées avec une clé spécifique, les déchiffre et exécute la commande". Je suppose que le résultat de l'exécution de la commande fait basculer certains GPIO pour actionner des choses.

Alors, pourquoi avez-vous peur que, potentiellement, certaines données passent décryptées entre le MCU et un module de cryptage / décryptage? Un pirate qui a accès au matériel pour voir les commandes décryptées serait, de toute façon, capable d'agir directement sur les GPIO du MCU et "d'activer les choses" aussi facilement.

Deuxième exemple:

L'utilisation de touches à temps est une idée. Mais comme vous le dites, où stockez-vous la clé principale principale utilisée pour générer les clés à usage unique? Vous serez confronté exactement aux mêmes questions que dans votre problème d'origine.

En fait, il n'y a aucun moyen de sécuriser votre système si vous supposez qu'un pirate peut potentiellement se faufiler à n'importe quel endroit de votre système (c'est ce que vous supposez actuellement, il me semble).

Qu'est-ce qui rend un système sûr, alors?

Une carte à puce est sécurisée car il est déraisonnable de supposer qu'un pirate peut sonder les routes internes au sein du CI, entre la mémoire et le bloc CPU.

Un verrou de porte électrique est sécurisé car il est déraisonnable de supposer qu'un pirate peut atteindre les fils qui actionnent le verrou.

Etc ... Fondamentalement, vous devez commencer par identifier les choses qu'un pirate ne pourra pas faire, et élaborer votre solution à partir de là. Par exemple, est-il possible de placer l'ensemble de votre système dans une boîte sécurisée et physiquement inviolable? Dans ce cas, vous pouvez librement faire décrypter des commandes via un bus interne.

Vous ne pouvez pas construire un système sécurisé sans savoir ce que le pirate ne peut raisonnablement pas faire. Tu ne nous l'as pas dit. Nous ne pouvons donc pas proposer de solution complète.

— faible
source

tout d'abord, merci pour la réponse élaborée! J'ai mis à jour la question d'une manière qui, je crois, vous répondra :)

— Sonja

Ce que je comprends de l'édition de votre message, c'est que seules les clés doivent être sécurisées. Les résultats réels des commandes n'ont pas besoin d'être sécurisés. Dans ce cas, placez les clés dans un module externe sécurisé comme vous l'avez suggéré, et acceptez que les commandes déchiffrées soient visibles en clair. Si ma suggestion n'est pas valide pour une raison quelconque, prenez le temps d'expliquer en détail ce qui est acceptable et ce qui ne l'est pas . Ce n'est pas juste une phrase de plus dans votre message dont nous avons besoin. Nous avons besoin d'une image complète de la chose. Vraiment.

— dim

De plus, je pense que le cryptage des commandes n'est pas vraiment ce que vous voulez faire. Habituellement, nous devons crypter des données (quelques informations sur quelque chose, ou un document ...). Mais nous avons rarement besoin de crypter les commandes envoyées à un appareil. Ce qui est généralement requis sur les commandes, c'est de les signer , pour garantir qu'elles proviennent de la partie autorisée. Mais leur contenu est rarement sensible, en fait. Vous devez donc également le confirmer.

— dim

Cela ressemble à un cas classique où un cryptage à clé asymétrique serait utile. Dans le cryptage à clé asymétrique, vous avez deux clés, une privée et une publique. Vous souhaitez protéger pleinement la clé privée, mais la clé publique peut être rendue publique et ne nécessite aucune protection. vous pourrez peut-être conserver la clé privée sur le système sécurisé et la clé publique sur le périphérique intégré.

— hildred
source

Le déchiffrement des données se fait avec la clé privée (et le chiffrement avec la clé publique). Sinon, cela signifie que tout le monde peut décrypter (car tout le monde a accès à la clé publique), ce qui serait un problème. Par conséquent, vous devez disposer de la clé privée dans l'appareil. Alors, maintenant, comment mettre la clé privée dans l'appareil? Eh bien, revenons au problème initial ...

— dim

pouvoir décrypter des commandes ne permet pas d'en créer de nouvelles à partir de zéro, donc avoir la clé publique accessible n'est pas vraiment un problème

— masterX244

C'est généralement la même chose que la signature cryptographique; ce qui présente l'inconvénient que si quelqu'un a la clé publique (ne doit pas être publique, peut être stocké de manière aussi sécurisée que la clé symétrique), il peut tout déchiffrer; mais, comme le dit masterX244, vous ne pouvez généralement pas créer / signer de nouvelles commandes. Je pense que c'est une bonne solution.

— CoderTao

Vous n'expliquez pas pourquoi vous souhaitez que les commandes soient chiffrées (en d'autres termes, quel est votre modèle de menace). Votre objectif est-il d'empêcher un adversaire en possession du périphérique basé sur PIC de déterminer quelles sont les commandes qui lui sont envoyées? Ou essayez-vous d'empêcher le périphérique basé sur PIC d'exécuter un ensemble de commandes substitué par un adversaire et de lui permettre uniquement d'exécuter des commandes provenant de votre serveur?

Dans le premier cas, vous faites face à une tâche presque impossible: votre appareil doit décrypter les commandes afin de les exécuter - la possession de l'appareil PIC signifie la possession de la clé de déchiffrement. Un adversaire peut soit extraire la clé (stockée dans le périphérique PIC qu'il possède), soit simplement attendre que votre micrologiciel déchiffre les commandes, puis les capturer de la mémoire.

Si, en revanche, vous essayez seulement de vous assurer que votre appareil n'exécutera que des commandes provenant de votre serveur, vous avez de la chance. Dans ce cas, vous pouvez utiliser le chiffrement à clé publique (par exemple RSA) ou un schéma de signature numérique à clé publique (par exemple DSS). Dans ceux-ci, votre appareil stocke uniquement la clé publique: cela suffit pour déchiffrer les commandes (ou vérifier la signature numérique), mais ne peut pas être utilisé pour chiffrer les commandes (ou générer une signature numérique) que l'appareil acceptera. Cela nécessite la clé privée, que vous utilisez pour crypter (ou signer) les commandes avant de les envoyer. La clé privée n'a jamais besoin de quitter votre serveur. Encore mieux, cryptez ou signez les commandes sur une machine qui ne communique pas en externe et copiez-les uniquement sur le serveur afin que la clé privée ne soit jamais trouvée sur un serveur accessible en externe.

— Stephen C. Steel
source