Sécurisation de la communication entre des systèmes embarqués limités
J'essaie actuellement de renforcer la communication sur un canal de communication physique limité sur un système embarqué.
Le scénario
Je pense que le système est plutôt typique pour les petites applications embarquées:
Les systèmes embarqués impliqués sont de petits microcontrôleurs sans OS, que l'on peut supposer être dans un environnement physique sécurisé. Le canal de connexion est physiquement accessible aux agresseurs, ils peuvent interférer avec les messages à volonté.
Différents canaux de communication sont possibles: par exemple RS485 ou RS232. Il existe un protocole grossier qui gère des choses comme l'adressage et l'intégrité brute (par exemple CRC16 pour les bitflips) sur lequel nous pouvons construire. Pensez-y comme étant un TCP lent.
Chaque partenaire de communication connaît un certificat racine qui peut agir en tant qu'autorité de certification et possède son propre certificat unique (+ clé) signé par lui. Les certificats sont auto-signés, courbe elliptique prime256v1
La bibliothèque mbedTLS est disponible pour ces systèmes (avec DH, AES, ..).
La plupart du temps, Internet n'est pas disponible.
Les systèmes peuvent garder le temps et peuvent créer suffisamment de nombres aléatoires
Je veux atteindre la confidentialité, l'authenticité et l'intégrité.
Comment cela pourrait être résolu
Une règle dans les protocoles cryptographiques est de ne jamais les implémenter vous-même. Malheureusement, je n'ai rien trouvé qui corresponde à ce cas d'utilisation.
J'ai également parcouru les questions existantes, mais rien n'a fourni la solution complète que je recherchais.
Enfin, dans cette réponse, l' implémentation d'un propre protocole est donnée comme dernière option.
C'est pourquoi j'ai proposé la solution décrite ci-dessous - mais je n'en suis pas entièrement sûr. Je me suis orienté sur cette réponse sur la façon d'authentifier un échange de clés Diffie-Hellmann , cette réponse sur la façon de vérifier l'intégrité et ce fil me donnant quelques idées sur la façon de mettre en œuvre un tel protocole .
Protocole pour sécuriser la communication
La première chose à faire est de générer aléatoirement une clé symétrique K. La première chose envoyée est un message de prise de contact. Il comprend les champs suivants:
| Champ | La description |
|---|---|
| DH | L'échange de clés Diffie-Hellmann msg g K |
| Cert | Le certificat (-chain) de l'appareil émetteur |
| MsgIdNonce | Une valeur aléatoire de 64 bits |
| Signature | Une signature du message complet à l'aide de la clé privée de Cert |
Les deux appareils envoient (et reçoivent) un tel message.
Lorsqu'un message est reçu, les opérations suivantes sont effectuées:
- Vérifiez si le certificat est signé par l'autorité de certification attendue (doit être en chaîne)
- Vérifiez si le msg est correctement signé avec cert et sa clé
Lorsque ces vérifications réussissent, les messages DH g K envoyés et reçus sont utilisés pour calculer une clé symétrique.
À partir de ce moment, les applications peuvent envoyer des messages cryptés avec AES-CBC. Comme les messages peuvent être perdus relativement souvent, IV est toujours dans le message.
Voici le format du message:
| Champ | La description | Crypté |
|---|---|---|
| IV | Initialy Random IV pour AES | Non |
| MsgIdNonce | Handshake / Last MsgIdNonce + 1 ou + 2 | Oui |
| Application Data | Les données / commandes à protéger | Oui |
| CMAC tronqué à 64 bits | MAC pour vérifier l'intégrité | Oui |
Pour qu'un message soit accepté, il doit
- Avoir le MsgIdNonce attendu (1 ou 2 au-dessus du dernier reçu) - empêchant les attaques de relecture, permettant de perdre 1 message
- Avoir un CMAC valide - empêchant les attaques contre l'intégrité
- Être reçu max. T secondes après le dernier message - prévention des attaques par retard
Si quelque chose n'est pas comme prévu, Handshake est envoyé à nouveau, puis le message est renvoyé avec les paramètres nouvellement échangés.
Des questions
Suis-je sur la bonne voie ou devrais-je essayer quelque chose de complètement différent?
Est-ce que cela fournit mes objectifs de sécurité ou est-ce que je manque des vulnérabilités évidentes ici?
Cela peut-il fonctionner?
J'espère que vous pourrez m'aider, moi et d'autres ingénieurs embarqués confrontés à des problèmes similaires!
Réponses
Une règle dans les protocoles cryptographiques est de ne jamais les implémenter vous-même. Malheureusement, je n'ai rien trouvé qui corresponde à ce cas d'utilisation.
Avez-vous envisagé DTLS ? Cela tente de résoudre le même problème (sauf pour les horodatages; cela pourrait être ajouté en insérant l'horodatage dans le datagramme), et a déjà réfléchi. Une autre possibilité serait IPsec; cependant DTLS semble plus proche de résoudre le problème que vous avez (à moins que le trafic de données que vous protégez soit le trafic IP).
Cela dit, voici quelques réflexions sur le protocole que vous avez décrit:
Que se passe-t-il si deux messages séquentiels sont supprimés (par exemple, reçus de manière incorrecte)? Les deux parties réaliseront-elles ce qui s'est passé ou vont-elles procéder à la suppression de tous les messages ultérieurs (à cause de la règle du «nonce ne doit pas incrémenter plus de 2»)?
En supposant qu'ils tentent une nouvelle clé, comment est-ce coordonné? Si un côté pense qu'ils n'ont pas encore recléé et que l'autre pense qu'ils le sont, qu'adviendra-t-il des messages chiffrés avec l'ancienne clé? Nous trouvons généralement utile d'inclure une balise «quelle clé est chiffrée sous» avec le texte chiffré (en DTLS, c'est «l'époque»).
Votre canal de communication peut-il réorganiser les messages? Je soupçonne que ce n'est pas le cas dans votre cas, mais si c'est possible, vous devriez réfléchir à la façon dont cela devrait être géré.
Que se passe-t-il si quelqu'un injecte un précédent message d'établissement de liaison (valide)? Comment cela va-t-il confondre les choses?
Dans le chemin de cryptage des données, vous utilisez le cryptage CBC et l'intégrité CMAC. Bien qu'il s'agisse d'une solution viable, elle est sujette à diverses attaques de remplissage si elles ne sont pas intégrées correctement. La mode actuelle est d'utiliser un mode AEAD (comme GCM ou Chacha20 / Poly1305) qui fait les deux.
Le trafic chiffré est-il unidirectionnel ou bidirectionnel? Si le trafic va dans les deux sens, utilisez-vous le même ensemble de clés pour protéger les deux ensembles de trafic?
"Si quelque chose n'est pas comme prévu, la prise de contact est à nouveau envoyée, puis le message est renvoyé avec les paramètres nouvellement échangés." - Comment ça marche? Si le destinataire décide qu'il n'aime pas le message, comment l'expéditeur sait-il qu'il doit le renvoyer?