Security auf kleinen Geräten

Transkript

2 Neue Domänen für Embedded-Systeme Physische Welt Wearable Smart Things: Erweiterung physischer Komponenten mit zusätzlicher Elektronik Elektronische Welt Sensoren für die Umgebung Embedded-Systeme bilden eine Brücke zur physischen Welt: direkt von relevanten physischen Komponenten Sensoren für die Umgebung Automatische Steuerung ohne manuelle Eingriffe 2

3 Embedded-Systeme statt vollwertiger Rechner Typische Anforderungen: Kompakte Elektronik Stromsparend Robust (Temperaturbereich, Vibration) Kabellose Anbindung 3

4 Herausforderungen bei Embedded-Systemen Sehr knappe Ressourcen Massgeschneidertes Design RTOS statt klassischem Betriebssystem Spezialisierte, eigene Software statt Einbindung grosser Bibliotheken Proprietäre Hardware-Kommunikationsprotokolle und formate Foto von Andrew Magill / CC BY 2.0 / beschnitten Neu: Energy Harvesting 4

5 Themenwechsel: Security

6 Security: betroffen sind immer nur die anderen 6

7 Massnahmen auf verschiedenen Ebenen Prozess Umsetzung des Systems Schulung Sicherheitsanforderungen Bedrohungsmodellierung Code-Review Penetrationtests Organisatorische Massnahmen Technische Massnahmen Emergency Response Team Kontrollierter Zugang zum Serverraum Verwaltung der Benutzer Firewall Benutzerauthentifizierung, Zugriffskontrolle Verschlüsselung 7

8 Fokus: Technische Massnahmen Prozess Organisatorische Massnahmen Technische Massnahmen 8

9 Technische Massnahmen Embedded System Gateway Server Client Buffer bank Welche bewährten Technologien gibt es für die Sicherheit? 9

10 Technische Massnahmen: Tiefe Sicherheit Physischer Schutz durch Gebäude Firewall VPN HTTPS Embedded System Gateway Buffer Server Passwortabfrage Client Sicherheitslücken durch Zugang ins Gebäude durch Unbefugte Falsch konfigurierte Firewall Social Engineering: Einschleusen von Malware Schwache Passwörter, gefälschte HTTPS-Zertifikate bank Bugs/Hintertüren in Betriebssystem und Dritt-Software Festplattenverschlüsselung 10

11 Technische Massnahmen: Hohe Sicherheit Ganzheitliche Massnahmen: auch Embedded-System einbeziehen Embedded System Gateway Server Client Schlüssel in externem Security-IC speichern Buffer bank Sicherheitskonzept: optimiert für die Applikation Umfassender und durchgehender Einsatz von Verschlüsselung! 11

12 Verschlüsselung als Basis für hohe Sicherheit Need-to-know-Prinzip: Nur die relevanten Komponenten sollten Zugriff auf die haben. Oder vertrauen Sie allen Komponenten wie Betriebssystemen, Dritt- Software oder Routern? In der Praxis nur umsetzbar mit Verschlüsselung. 12

13 Verschlüsselung als Basis für hohe Sicherheit Need-to-know-Prinzip: Nur die relevanten Komponenten sollten Zugriff auf die haben. Oder vertrauen Sie allen Komponenten wie Betriebssystemen, Dritt- Software oder Routern? In der Praxis nur umsetzbar mit Verschlüsselung. 13

14 Wieso ist Ende-zu-Ende-Verschlüsselung wichtig? Unsicherheit durch aufgeblähte Dritt-Software: Kaum verwendete Features Zu viele Möglichkeiten in der Protokollkonfiguration Nicht mehr benötigte Abwärtskompatibilität oder Fallbacks Unsicherheit durch zu viele (vertrauenswürdige?) Lieferanten: Zu viele Root-Zertifikate vorinstalliert Komplexe Lieferketten für Hardwarekomponenten Hintertüren in Software 14

15 Wieso ist Ende-zu-Ende-Verschlüsselung wichtig? Unsicherheit durch aufgeblähte Dritt-Software: Kaum verwendete Features Zu viele Möglichkeiten in der Protokollkonfiguration Nicht mehr benötigte Abwärtskompatibilität oder Fallbacks Unsicherheit durch zu viele (vertrauenswürdige?) Lieferanten: Zu viele Root-Zertifikate vorinstalliert Komplexe Lieferketten für Hardwarekomponenten Hintertüren in Software 15

16 Security in Embedded-Systemen

17 Security in Embedded-Systemen Auch das Embedded-System muss sich an der Security beteiligen. Herausforderung: Verschlüsselung bei knappen Ressourcen? 17

18 Verwendung eines Standard-Protokolls (z.b. HTTPS)? Mögliche Einschränkungen durch das Embedded-System: Kleine Bandbreite / kleine Paketgrösse: Nur wenige Bytes Overhead möglich Seltenes Aufwachen: Kein aufwändiger Handshake möglich Verbindungslose Kommunikation Unidirektionaler Kanal Geringe Ressourcen: kb Code, kb RAM Langsame CPU Codegrösse von Bibliotheken: mbed TLS benötigt mind. 60kB Code und 64kB RAM wolfssl ist etwa ähnlich 18

19 Anpassbarkeit von Software-Bibliotheken Können unnötige Algorithmen entfernt werden? (wegen Codegrösse) Kann externes Security-IC eingebunden werden? Verwendung der Hardware-Algorithmen (kein Auslesen des Schlüssels) Limitierte Funktionalität: Ableitung anderer Security-Features aus vorhandenen Algorithmen (z.b. Authentifikation mit AES, ohne Hash-Algorithmus) Was auch noch fehlt: Standardisierte Protokolle und formate für Ende-zu-Ende- Verschlüsselung. 19

20 Konsequenz: Massgeschneiderte Security Vollwertige Rechner oder «grosse» Embedded-Systeme «Kleine» Embedded-Systeme Standard-Protokolle Gängige Software-Bibliotheken Alle Algorithmen, Protokollvarianten, Kompatibilitätsmodi, usw. Massgeschneidertes Protokoll Spezialisierte / abgespeckte Software- Bibliotheken (wenn überhaupt) Vereinfachte, vorgegebene Protokollvariante 20

21 Konsequenz: Massgeschneiderte Security Vollwertige Rechner oder «grosse» Embedded-Systeme Statt HTTPS: «Kleine» Embedded-Systeme Einfaches, proprietäres Protokoll? Standard-Protokolle Gängige Software-Bibliotheken Alle Algorithmen, Protokollvarianten, Kompatibilitätsmodi, usw. Massgeschneidertes Protokoll Spezialisierte / abgespeckte Software- Bibliotheken (wenn überhaupt) Vereinfachte, vorgegebene Protokollvariante 21

22 Konsequenz: Massgeschneiderte Security Vollwertige Rechner oder «grosse» Embedded-Systeme Statt einer Suite wie OpenSSL: «Kleine» Embedded-Systeme Nur einfache Crypto++ Bibliothek Standard-Protokolle Gängige Software-Bibliotheken Alle Algorithmen, Protokollvarianten, Kompatibilitätsmodi, usw. Massgeschneidertes Protokoll Spezialisierte / abgespeckte Software- Bibliotheken (wenn überhaupt) Vereinfachte, vorgegebene Protokollvariante 22

23 Konsequenz: Massgeschneiderte Security Vollwertige Rechner oder «grosse» Embedded-Systeme «Kleine» Embedded-Systeme Standard-Protokolle Gängige Software-Bibliotheken Alle Algorithmen, Protokollvarianten, Kompatibilitätsmodi, usw. Statt 3DES, AES-128/256, RC4, Twofish: Nur AES-256 Massgeschneidertes Protokoll Spezialisierte / abgespeckte Software- Bibliotheken (wenn überhaupt) Vereinfachte, vorgegebene Protokollvariante 23

24 Stopp! Darf man ein Security-Protokoll selbst entwerfen? Gängiges Security-Protokoll Hohe Sicherheit Selbst entworfenes Security-Protokoll Mittlere Sicherheit - Keine Sicherheit Ihre Entscheidung! Gängige Protokolle wurden leider nicht für Kleinstsysteme wie Sensoren entworfen. 24

25 Welche Teile aus gängigen Protokollen übernehmen? HTTPS SSL/TLS: Steuerung, Konfiguration SSL/TLS: strom formate Nachrichten Authentifizierung des Gegenübers Aushandeln der Algorithmen Schlüsselaustausch Modus der Blockverschlüsselung Padding, IV, MAC, Salt, Nonce Diffie- Hellman AES SHA-2 ECC Algorithmen 25

26 Welche Teile aus gängigen Protokollen übernehmen? Massgeschneidertes, Applikationsspezifisches Protokoll formate Authentifizierung des Gegenübers Vorgängig ausgetauschte Schlüssel (PSK) strom Modus der Blockverschlüsselung Padding, IV, MAC, Salt, Nonce AES SHA-2 Algorithmen 26

27 Beispiele von Vereinfachungen (1) Nur symmetrische Algorithmen & vorgängig ausgetauschte Schlüssel (z.b. TLS PSK) Paketbasierte (DTLS) statt verbindungsbasierte (TLS) Kommunikation Weniger Algorithmen: Verschiedene Aufgaben mit dem selben Algorithmus (z.b. AES) erledigen Prüfcode (MAC) basierend auf AES CCM-Mode statt SHA-256 Authentifizierung das Gegenübers 27

28 Beispiele von Vereinfachungen (2) Falls nicht genug Platz für einen guten Algorithmus (z.b. AES): Statt eine eigene XOR-Verschlüsselung zu erfinden: Einen einfachen Algorithmus wie RC5, PRESENT oder XXTEA nehmen. Der Bereich «Lightweight Cryptography» ist noch jung, aber es gibt laufend Fortschritte, auch dank dem Internet der Dinge. 28

29 Konkretes Beispiel

30 Topologie Client Sensor Bluetooth Gateway Internet (HTTPS) Server Internet (HTTPS) bank Sensor überträgt regelmässig an einen Server. Über einen Client (GUI) kann der Benutzer die anschauen. 30

31 1. Schritt: verschlüsselt Client Sensor Sensor- Schlüssel verschlüsselt Gateway verschlüsselt Server Sensor-Schlüssel bank Durchgehende Verschlüsselung zwischen Sensor und Server: Das Gateway ist nicht mehr sicherheitskritisch. 31

32 2. Schritt: MAC Client Sensor Sensor- Schlüssel verschlüsselt + MAC Gateway verschlüsselt + MAC Server Sensor-Schlüssel bank Hinzufügen eines MAC (abhängig von Zeitstempel / Counter): Schutz der integrität und gegen Replay-Attacken. 32

33 3. Schritt: Abgeleiteter Schlüssel Client Sensor Sensor- Schlüssel verschlüsselt + MAC Gateway verschlüsselt + MAC Server Sensor- Masterschlüssel Sensor-ID bank Jeder Sensor hat einen eigenen Schlüssel (von einem Masterschlüssel und einer eindeutigen ID abgeleitet): Schutz des Gesamtsystems, wenn ein Sensor gehackt. 33

34 4. Schritt: Auslagerung der Schlüssel Client Sensor verschlüsselt + MAC Gateway verschlüsselt + MAC Server Security-IC Sensor- Schlüssel Sensor-ID Security-Service Sensor- Masterschlüssel bank Die Schlüssel werden in besonders geschützte Komponenten ausgelagert (separate Hardware oder separater Rechner). 34

35 5. Schritt: Beglaubigung der Sensor verschlüsselt + MAC Gateway verschlüsselt + MAC Client Server signiert Signatur: Öffentlicher Schlüssel signiert Security-IC Sensor- Schlüssel Sensor-ID Security-Service Signatur: Privater Schlüssel Sensor- Masterschlüssel bank Nach der Entschlüsselung werden die unmittelbar signiert, damit später auch der Client die Authentizität prüfen kann. 35

36 Vielen Dank für Ihre Aufmerksamkeit! Tel

37 37