14.4.1. Konzepte: Vertrauen, Schlüssel und Dateiformat

Vor allen Befehlen drei Hintergrundinformationen, die für jede andere Seite in diesem Abschnitt gelten.

14.4.1.1. Vertrauensmodelle

Eine TLS-Verbindung kann drei zunehmende Stufen der Sicherheit bieten:

  • Nur Verschlüsselung – der Datenverkehr ist verschlüsselt, aber keine Seite weist nach, wer sie ist. Einfach einzurichten (keine Zertifikatsvalidierung), aber anfällig für einen Man-in-the-Middle-Angriff. Nur für lokales Testen verwenden.

  • Serverauthentifizierung – der Client verifiziert das Zertifikat des Servers gegen ein vertrauenswürdiges Zertifikat (das vertraute HTTPS-Modell). Die OpenMV Cam kann entweder als Client (der einen entfernten Server verifiziert) oder als Server (der sein eigenes Zertifikat vorlegt) agieren.

  • Gegenseitige Authentifizierung (mTLS) – beide Enden legen Zertifikate vor und verifizieren sie. Wird dort verwendet, wo der Server sich auch der Identität des Clients sicher sein muss.

14.4.1.2. Auswahl eines Schlüsseltyps

Der mbedTLS-Build der Kamera unterstützt ECDSA auf den NIST/SEC-Primkurven sowie RSA. Es gibt drei praktische Wege, einen Schlüssel zu erstellen; ECDSA P-256 (prime256v1) wird empfohlen:

  • ECDSA P-256 (prime256v1) – etwa 128-Bit-Sicherheit mit einem 256-Bit-Schlüssel. Winzige Schlüssel und Signaturen und mit Abstand der schnellste Handshake der unterstützten Optionen auf einem Cortex-M (Operationen auf elliptischen Kurven sind viel günstiger als RSA-Operationen mit privatem Schlüssel). Universell von TLS-Gegenstellen unterstützt. Dies ist die beste Balance aus Sicherheit, Geschwindigkeit, RAM-/Flash-Verbrauch und Kompatibilität auf einem eingebetteten Gerät, weshalb es hier die Standardwahl ist.

  • ECDSA P-384 (secp384r1) – etwa 192-Bit-Sicherheit. Weiterhin elliptische Kurve, also einigermaßen effizient, aber größer und langsamer als P-256 für eine Sicherheitsmarge, die typische IoT-Bereitstellungen nicht benötigen. Nur verwenden, wenn ein langlebiges Zertifikat oder eine Compliance-Anforderung dies verlangt.

  • RSA-2048 – etwa 112-Bit-Sicherheit. Universell kompatibel, auch mit sehr alten Gegenstellen, aber RSA-Schlüssel und -Zertifikate sind viel größer, und RSA-Operationen mit privatem Schlüssel (durchgeführt von der Seite, die das Zertifikat vorlegt) sind die langsamste und speicherhungrigste Option auf einem Mikrocontroller. Nur verwenden, wenn eine Gegenstelle kein ECDSA beherrscht.

Bemerkung

Ed25519- / Curve25519-Schlüssel werden nicht unterstützt. Der mbedTLS-Build der OpenMV Cam aktiviert weder EdDSA noch Curve25519, sodass ein Ed25519-Zertifikat oder -Schlüssel beim Laden oder Handshake fehlschlägt. Verwenden Sie eine der drei obigen Optionen.

14.4.1.3. Dateiformat: DER verwenden

Der von der OpenMV Cam verwendete mbedTLS-Build enthält kein PEM-Parsing, sodass die Kamera Zertifikate und Schlüssel nur in DER-Form (der binären Kodierung) liest. Die meisten Werkzeuge geben standardmäßig die PEM-Form (Base64-Text) aus, sodass jede für die Kamera bestimmte Datei zuerst nach DER konvertiert wird – jede Anleitung in diesem Abschnitt endet mit diesem Konvertierungsschritt. Sie benötigen:

  • Einen privaten Schlüssel – geheim gehalten, verwendet von der Seite, die ein Zertifikat vorlegt.

  • Ein Zertifikat – der öffentliche Teil, der der anderen Seite während des Handshakes vorgelegt wird.

  • Ein CA- / Vertrauenszertifikat – das Zertifikat, das die verifizierende Seite lädt, um zu entscheiden, ob der Gegenstelle vertraut wird. Bei einem selbstsignierten Setup ist dies einfach das eigene Zertifikat der Gegenstelle.