14.4.1. Concepts : confiance, clés et format de fichier¶

Avant toute commande, trois éléments de contexte qui s’appliquent à toutes les autres pages de cette section.

14.4.1.1. Modèles de confiance¶

Une connexion TLS peut offrir trois niveaux d’assurance croissants :

Chiffrement seul – le trafic est chiffré mais aucune des deux parties ne prouve qui elle est. Facile à mettre en place (pas de validation de certificat) mais vulnérable à une attaque de l’homme du milieu. À n’utiliser que pour des tests locaux.
Authentification du serveur – le client vérifie le certificat du serveur par rapport à un certificat de confiance (le modèle HTTPS habituel). L’OpenMV Cam peut agir soit comme client (vérifiant un serveur distant), soit comme serveur (présentant son propre certificat).
Authentification mutuelle (mTLS) – les deux extrémités présentent et vérifient des certificats. Utilisée lorsque le serveur doit également s’assurer de l’identité du client.

14.4.1.2. Choisir un type de clé¶

La compilation mbedTLS de la caméra prend en charge ECDSA sur les courbes premières NIST/SEC ainsi que RSA. Il existe trois manières pratiques de créer une clé ; ECDSA P-256 (prime256v1) est recommandé :

ECDSA P-256 (prime256v1) – environ 128 bits de sécurité avec une clé de 256 bits. Clés et signatures minuscules, et de loin la négociation la plus rapide des options prises en charge sur un Cortex-M (les opérations sur courbes elliptiques sont bien moins coûteuses que les opérations de clé privée RSA). Universellement pris en charge par les pairs TLS. C’est le meilleur équilibre entre sécurité, vitesse, utilisation de RAM/flash et compatibilité sur un appareil embarqué, ce qui explique pourquoi c’est le choix par défaut ici.
ECDSA P-384 (secp384r1) – environ 192 bits de sécurité. Toujours à courbes elliptiques, donc raisonnablement efficace, mais plus volumineux et plus lent que P-256 pour une marge de sécurité dont les déploiements IoT typiques n’ont pas besoin. À n’utiliser que si un certificat de longue durée ou une exigence de conformité l’impose.
RSA-2048 – environ 112 bits de sécurité. Universellement compatible, y compris avec des pairs très anciens, mais les clés et certificats RSA sont bien plus volumineux et les opérations de clé privée RSA (effectuées par la partie qui présente le certificat) sont l’option la plus lente et la plus gourmande en mémoire sur un microcontrôleur. À n’utiliser que lorsqu’un pair ne peut pas faire d’ECDSA.

Note

Les clés Ed25519 / Curve25519 ne sont pas prises en charge. La compilation mbedTLS de l’OpenMV Cam n’active pas EdDSA ni Curve25519, de sorte qu’un certificat ou une clé Ed25519 échouera au chargement ou à la négociation. Utilisez l’une des trois options ci-dessus.

14.4.1.3. Format de fichier : utilisez DER¶

La compilation mbedTLS utilisée par l’OpenMV Cam n’inclut pas l’analyse PEM, de sorte que la caméra ne lit les certificats et les clés qu’au format DER (l’encodage binaire). La plupart des outils produisent par défaut le format PEM (texte en base64), c’est pourquoi chaque fichier destiné à la caméra est d’abord converti en DER – chaque recette de cette section se termine par cette étape de conversion. Vous aurez besoin de :

Une clé privée – gardée secrète, utilisée par la partie qui présente un certificat.
Un certificat – la partie publique, présentée à l’autre partie pendant la négociation.
Un certificat CA / de confiance – le certificat que la partie vérificatrice charge pour décider si le pair est de confiance. Pour une configuration auto-signée, il s’agit simplement du propre certificat du pair.