Übersetzungen dieser Seite:

Inhaltsverzeichnis

Security

Diese Seite beschreibt welche Security-Optionen wir haben.

Zuerst zur Begriffsklärung: Im Englischen unterscheidet man zwischen Safety und Security. Beides wird im Deutschen mit Sicherheit übersetzt. Safety bezeichnet Sicherheit gegen einen Angreifer, im Englischen Adversary (darunter fällt Geheimhaltung (Privacy), Schutz vor unerlaubter Veränderung, Schutz gegen Sabotage (Denial of Service). Safety bezeichnet die Sicherheit bei unvorhergesehenen Vorfällen die typischerweise nicht durch einen menschlichen Gegner verursacht sind.

Auf dieser Seite beschäftigen wir uns mit Security.

Konkret geht es darum, das unerlaubte Auslesen von Daten zu verhindern, als auch die Veränderung von Daten bzw. das Steuern von Aktuatoren.

Verschlüsselung

Für diese Aufgabe ist Verschlüsselung *eine* der Komponenten die benötigt werden. Für CoAP über 6loWPAN gibt es im Prinzip drei Möglichkeiten der Verschlüsselung:

  • MAC-Layer Verschlüsselung: Hier werden Punkt-zu-Punkt zwischen zwei Knoten die Pakete verschlüsselt auf Ebene 2 des OSI-Stacks (MAC-Layer).
  • IpSec: Hier werden IP-Pakete verschlüsselt, Ebene 3 des OSI-Stacks (Network)
  • CoAPS: Hier wird auf UDP-Ebene verschlüsselt unter Verwendung von Datagram Transport Layer Security (DTLS). Dies ist Ebene 4 des OSI-Stacks.

Mac-Layer Verschlüsselung Vor-Nachteile: Todo

IPSec Vor-Nachteile: Todo

CoAPS Vor-Nachteile: Todo

Symmetrische vs. Asymmetrische Verschlüsselung

Todo

Hardware-Unterstützung im Merkurboard

Das Merkurboard unterstützt bereits

  • AES Verschlüsselung in Hardware, wurde vor kurzem auch (von Harald) integriert dass es in unserem Contiki-Fork verfügbar ist.
  • Einen Hardware Zufallszahlengenerator der über den Radio-Teil mit Feldstärkemessung funktioniert

Was wir nicht haben:

  • Eine Echtzeituhr – aber da wir Netzwerk-Verbindung haben, kann z.B. das Simple Network-Time-Protokoll (SNMP) implementiert werden

Anforderungen an eine DTLS-Implementierung

  • Unterstützung von asymmetrischer Verschlüsselung
  • Insbesondere kann bei asymmetrischer Verschlüsselung auch eine Authentifizierung erfolgen (Client-Side Zertifikat).
  • AES Verschlüsselung für die symmetrische Verschlüsselung, weil AES in der Hardware des Merkurboards (und bei vielen anderen Boards) unterstützt ist.
  • Klein genug dass es in wenig Speicher (Flash und RAM) funktioniert
  • Verwendung von Elliptischen Kurven für die asymmetrische Verschlüsselung weil diese weniger CPU und Platz brauchen und daher für Mikrocontroller besser geeignet sind
Mögliche Implementierungen
  • TinyDTLS ist eine minimale DTLS-Implementierung die bereits für Contiki vorbereitet ist. Leider enthält DTLS eine eigene minimale (nicht sehr schöne) ASN.1 Implementierung (die für TLS Varianten nötig ist um Daten auszutauschen). Weiters enthält es derzeit *keine* asymmetrische Verschlüsselung sondern unterstützt nur symmetrische pre-shared keys.
  • mbed TLS (früher PolarSSL) ist von ARM übernommen worden und wird als Open Source TLS Implementierung für embedded Devices angeboten. Hier ist zu untersuchen, ob mit mbed TLS eine für Mikrocontroller geeignete Implementierung (Geschwindigkeit, Speicherbedarf) möglich ist.

Hinweise

der 6lbr branch von cetic hat dtls implementiert.

https://github.com/cetic/6lbr/wiki/Example-:-Dtls-Coap-Server

Ich glaube da kann man sich mal naschaun wie die das machen.(Harald Pichler)

Für den PC existiert ein Linux Client für coaps:

https://github.com/thecodemaiden/tinydtls-coap


de/ideen/security.txt · Zuletzt geändert: 2017/09/21 14:57 von runtux