Stockage d'une clé sécurisée dans la mémoire d'un appareil intégré

Je travaille sur un appareil embarqué qui envoie / reçoit des données et les stocke en mode texte chiffré (mode crypté). Quelle est la meilleure approche pour le stockage des clés (j'ai utilisé le MCU ARM CORTEX série M)?

1-Stockage des clés dans la mémoire SRAM et dans chaque séquence de démarrage, injectez les clés dans le MCU intégré et stockez-les dans la mémoire SRAM. C'est le meilleur moyen, je pense, puis lorsque le MCU détecte la pénétration (avec un capteur de sabotage ou ...), il peut effacer la SRAM rapidement et se réinitialiser. Inconvénient: si l'attaquant réussit à passer les tampons et à accéder à l'appareil, la sécurité de la mémoire SRAM est-elle sûre (contre l'extraction de code). Je ne trouve aucune capacité de sécurité pour cette mémoire dans les MCU.

2-Générez des clés et stockez-les dans la mémoire flash lors de la programmation du MCU. Prise en charge de la mémoire flash MCU CRP (protection en lecture de code) qui empêche l'extraction de code et avec l'aide de son moteur AES interne et du moteur RNG (génération de nombres aléatoires), nous pouvons créer une clé aléatoire et crypter la mémoire flash et stocker cette clé aléatoire dans l'OTP ( mémoire programmable une fois - une mémoire cryptée de 128 bits), puis lors de l'exécution du code, nous décodons la mémoire flash avec la clé RNG et l'accès à la clé et aux codes initiaux. Inconvénient: les clés stockées dans une mémoire non volatile, les tampons seront inutiles et l'attaquant aura beaucoup de temps pour extraire les clés.

Clé 3-stockée dans la mémoire EEPROM, combinaison des 2 approches ci-dessus, clé stockée dans la mémoire non volatile mais lorsque les tampons détectent la pénétration, l'EEPROM est effaçable.

Je considère LPC18S57FBD208 (cortex m3 avec 1 Mo de mémoire flash, 180 MHz, 136 Ko SRAM, 16 Ko EEPROM et un contrôleur LCD TFT dont j'ai besoin pour piloter un écran LCD TFT 7 "et un moteur de cryptage AES 128 bits) car y a-t-il une autre meilleure suggestion?

Aucune de ces options n'est particulièrement meilleure ou pire que les autres, car elles sont toutes très précaires. Je vais avec l'option 4.

1. SRAM est l'endroit le plus sûr pour stocker les clés, mais vous ne devez jamais les injecter du monde extérieur. Ils doivent TOUJOURS être générés dans le processeur, lors du démarrage. Faire quoi que ce soit d'autre invalide instantanément le reste - c'est automatiquement dangereux.

2. Ne stockez pas de clés dans une mémoire non volatile, vous avez raison. Peu importe que vous protégiez l'EEPROM ou la mémoire flash de la lecture. Ce fusible de protection contre la lecture de code est facilement inversé. Un attaquant n'a qu'à décaper (retirer ou graver chimiquement l'emballage en époxy noir pour exposer la puce de silicium à l'intérieur). À ce stade, ils peuvent couvrir la partie de la matrice qui est des cellules de mémoire non volatiles (ces sections sont très régulières et bien que les cellules de mémoire individuelles soient beaucoup trop petites pour être vues, la plus grande structure peut l'être) et un petit morceau de quelque chose opaque aux UV est masqué sur cette section. Ensuite, l'attaquant peut simplement faire briller une lumière UV sur la puce pendant 5 à 10 minutes et réinitialiser tous les fusibles, y compris le fusible CRP. La mémoire OTP peut désormais être lue par n'importe quel programmeur standard.

Ou, s'ils sont bien financés (disons, obtenir ces clés valent plus de 1000 $ à quelqu'un), ils peuvent simplement lire les cellules de mémoire directement avec plusieurs types de microscopes électroniques.

Pour être en sécurité, les clés doivent être effacées et non dissimulées.

3. Non, pour les mêmes raisons que ci-dessus.

Passons maintenant à l'option 4:

4. Utilisez simplement le cryptage. La distribution des clés est un problème résolu. Utilisez donc cette solution facilement disponible. La puce doit utiliser son RNG et diverses autres considérations doivent être prises pour s'assurer qu'elle dispose d'un approvisionnement suffisant en entropie, et le chargeur de démarrage doit démarrer directement dans le programme qui génère la ou les clés secrètes nécessaires, qui doivent être à usage général. s'enregistre et s'installe directement dans SRAM, où ils resteront jusqu'à ce qu'ils soient effacés.

Il y a un problème cependant, c'est que rien sauf le CPU n'a la moindre idée de la clé secrète. Pas de problème: utilisez la cryptographie à clé publique. Ce que vous avez stocké dans la mémoire OTP est votre clé publique. Cette clé peut être lue par n'importe qui, vous pouvez la poster sur un échange de pile, vous pouvez la peindre sur le côté d'un pétrolier en lettres de 5 pieds de haut, peu importe. La chose merveilleuse à propos de la cryptographie à clé publique est qu'elle est asymétrique. La clé pour chiffrer quelque chose ne peut pas le déchiffrer, cela nécessite la clé privée. Et inversement, la clé pour déchiffrer quelque chose chiffré par la clé publique ne peut pas être utilisée pour chiffrer quelque chose. Ainsi, le CPU génère les clés secrètes, utilise votre clé publique stockée pour crypter les clés secrètes et les envoie simplement via USB ou RS232 ou tout ce que vous voulez. La lecture de la clé secrète nécessite votre clé privée, qui ne doivent pas être stockés, envoyés ou jamais impliqués avec la puce. Une fois que vous avez déchiffré la clé secrète avec votre clé privée (ailleurs, en dehors de la puce), vous êtes prêt. Vous disposez d'une clé secrète transmise en toute sécurité qui a été GÉNÉRÉE entièrement dans la puce, sans avoir à stocker quoi que ce soit, sauf une clé publique - qui, comme indiqué précédemment, n'a pas du tout besoin d'être protégée contre la lecture.

Ce processus est officiellement appelé négociation clé, et tout l'utilise. Vous l'avez utilisé plusieurs fois aujourd'hui. Il existe de nombreuses ressources et bibliothèques disponibles pour le gérer. S'il vous plaît, n'injectez jamais de clés dans quoi que ce soit.

Une dernière chose à mentionner: tout cela est théorique car la clé AES peut être facilement récupérée à l'aide d'attaques de canal latéral, qui reposent sur l'alimentation et mesurent les moindres changements dans le tirage actuel et le délai entre ces changements causés par le basculement des bits dans le CPU comme registres. Ceci, combiné à la connaissance du fonctionnement d'AES (ou de l'un des très petits algorithmes de chiffrement possibles pouvant être utilisés), rend la récupération de la clé relativement facile et peu coûteuse. Il ne permettra pas de lire la clé, mais il peut réduire l'espace des clés à quelque chose de ridiculement petit, comme 255 clés possibles. La puce ne peut pas non plus la détecter, car elle est en amont.

Cela a vaincu les chargeurs de démarrage cryptés AES-256 sur les processeurs de cryptage `` sécurisés '' et ce n'est même pas si difficile. Pour autant que je sache, il n'y a pas de véritables contre-mesures matérielles à cette attaque. Cependant, ce sont les algorithmes de chiffrement eux-mêmes, et la façon dont ils nécessitent un processeur pour retourner les bits, qui sont à l'origine de cette vulnérabilité. Je soupçonne que des algorithmes résistants aux canaux latéraux ou résistants aux canaux latéraux devront être (et, espérons-le, sont) en cours de développement.

Donc, dans l'état actuel des choses, la vraie réponse à la façon de stocker une clé (ou même simplement d'utiliser une clé temporaire) sur un appareil intégré en toute sécurité est: vous ne pouvez pas.

Mais au moins si vous générez une nouvelle clé à chaque fois en utilisant la négociation de clé dans l'option 4, alors une attaque de canal latéral ne peut compromettre la clé d'un canal en cours d'utilisation, et seulement si elles ont un certain temps pour surveiller la puissance pendant qu'elle crypte les données . Si vous négociez fréquemment de nouvelles clés générées en interne, cela peut offrir des niveaux de sécurité utiles.

Générez des clés et stockez-les le moins longtemps possible.