Model-based Security Security: ganzheitliche Engineering - PDF document

2 Herausforderung: Security Model-based Security Security: ganzheitliche Engineering Eigenschaft: Jan Jürjens • Sicherheits-Mechanismen umgehen statt brechen. • Sichere Systems aus Computing Department unsicheren Komponenten ? The Open University „Those who think that their problem can be solved by simply applying cryptography don`t understand cryptography and don`t understand their problem“ http://www.umlsec.org (B. Lampson / R. Needham). Jan Jürjens, Open University: Model-based Security Engineering 2 Modellbasiertes Security Engineering MBSE vs. Entwicklungsphasen Idee: Modelle aus Anforderungen Security External Static Penetration Artefakten in requirements review analysis testing (tools) Ein- Analy- Risk-based Entwicklung und Abuse Risk Risk Security fügen sieren Security tests cases analysis analysis Gebrauch von breaks (UML) Modelle Verif. Software. Gener. Code-/ Requirements Design Test Code Test Field Reverse Konfigurationsdaten and use cases plans results Testgen. feedback Engin. Model-based Security Engineering Konfigur. [McGraw 2003] Programm Design: Security Engineering Lösungen als Pattern. � Automatisch unterstützte und theoretisch Analyse: Automatisch, formal fundierte Werkzeuge. Anm.: Schwerpunkt auf „abstrakten“ Anforderungen fundierte Security Design & Analyse. Jan Jürjens, Open University: Model-based Security Engineering 3 Jan Jürjens, Open University: Model-based Security Engineering 4 [FASE01,UML02, UMLsec Beispiel: Kryptobasiertes Verteiltes System FOSAD05,ICSE05] Häufige Sicherheits-Anforderungen und A B Angreifer Mechanismen und Angreiferszenarien m(x) m(x) als vordefinierte Markierungen einfügen. Damit verbundene logische Bedingungen [arg b,1,1 = x] verifizieren mit Modell-Checkern und return({z} k ) return({y::x} z ) Automatischen Theorembeweisern auf Basis einer formalen Semantik. Angreifer kann … Angreifer- k -1 , y, x • Systemteile kontrollieren, Stellt sicher, dass UML- {z} k, z Wissen: • Vorwissen haben, Modell die Sicherheits- • Nachrichten lesen, Anforderungen erfüllt. (vgl. [Dolev, Yao 1982]) löschen, einfügen. Jan Jürjens, Open University: Model-based Security Engineering 5 Jan Jürjens, Open University: Model-based Security Engineering 6 1

2 Sicherheitsanalyse Logische Axiome Definiere knows(E) für jedes E im Vorwissen Angreiferwissen von oben approximieren: des Angreifers. Prädikat knows(E) bedeutet: Angreifer kann Definiere Kryptosystem. Z.B.: Dec K-1 ({E} K )=E E ggf. während Ausführung des Systems lernen. Für evolvierendes Angreiferwissen: Z.B. für Vertraulichkeit: ∀ E 1 ,E 2 .(knows(E 1 ) ∧ knows(E 2 ) ⇒ Für vertrauliche Daten s : überprüfen, ob knows({E 1 } E 2 ) ∧ knows(s) von den vom Modell erzeugten knows(Dec E 2 (E 1 )) ∧ Formeln abgeleitet werden kann. …) [ICSE05] Jan Jürjens, Open University: Model-based Security Engineering 7 Jan Jürjens, Open University: Model-based Security Engineering 8 Interaktionen des Angreifers Beispiel: TLS Variante Protokoll-Interaktion Siehe IEEE TR1=(in( msg_in ),cond( msg_in ),out( msg_out )) Infocom 1999. gefolgt von TR2 gibt Prädikat PRED(TR1)= Ziel: ∀ msg_in . [knows( msg_in ) ∧ cond( msg_in ) ⇒� knows( msg_out ) geheime Daten ∧ PRED(TR2)] übertragen, mit Abstraktion (z.B. von Sender, Empfänger) Sitzungs- zwecks Effizienz: findet alle hier betrachteten schlüssel Angreifer, es gibt aber auch false positives. verschlüsselt. Forall-Quantifizierung über Iterationszähler. Jan Jürjens, Open University: Model-based Security Engineering 9 Jan Jürjens, Open University: Model-based Security Engineering 10 Analyse Logische Überprüfen, ob Formeln knows(s) ableitbar (z.B. mit e-Setheo). Überraschung: Ja ! � Vertraulichkeit von s nicht bewahrt. knows ( N ) ∧ knows ( K C ) ∧ knows ( Sign K C-1 (C::K C ) ) Warum ? ∧ ∀ init 1 ,init 2 ,init 3 . [ knows ( init 1 ) ∧ knows ( init 2 ) ∧ � Prolog-basierter knows ( init 3 ) ∧ snd ( Ext init 2 (init 3 ) ) = init 2 Angriffsgenerator. ⇒ knows ( {Sign K S-1 (…)} … ) ∧ [ knows ( Sign… )] ∧ ∀ resp 1 ,resp 2 . [ … ⇒ ... ] ] Jan Jürjens, Open University: Model-based Security Engineering 11 Jan Jürjens, Open University: Model-based Security Engineering 12 2

2 Man-in-the-Middle Angriff Korrektur e-Setheo: Beweis: knows(s) nicht ableitbar. Logik 1. Stufe vollständig (aber auch unentscheidbar). Jan Jürjens, Open University: Model-based Security Engineering 13 Jan Jürjens, Open University: Model-based Security Engineering 14 Verfeinerung und Modularität Sicherheits-Schichten „Verfeinerungsparadox“: Sicherheits- Systemebene oben benutzt Sicherheit von eigenschaften durch manche unten. client authenticity Verfeinerungsbegriffe nicht bewahrt. confidentiality, integrity, server authenticity Problem: muss jeweils neu verifizieren. ? Theorem: Unser Begriff der Verfeinerung = (vgl. Broy: Focus) bewahrt unsere confidentiality, … + client authenticity Sicherheitsanforderunge. [FME01] Analog: Sicherheitseigenschaften bewahrt Sicherheitseigenschaften additiv ? [Safecomp03] durch Komposition von Komponenten (unter Theorem: Ja, unter gegebenen gegebenen Voraussetzungen). Voraussetzungen. [Concur01] Jan Jürjens, Open University: Model-based Security Engineering 15 Jan Jürjens, Open University: Model-based Security Engineering 16 Analyse: Modell vs. Programm Erfahrungen Modell: Kann Verhaltensmodelle vom Programm + früher (weniger Kosten bei Korrektur) generieren (z.B. CFGs). Problem: zu wenig Abstraktion + abstrakter � effizienter � Verständnis und Verifikation schwierig. - abstrakter � Fokus auf bestimmte Angriffe � Annahme: Textuelle Spezifikation gegeben. - Programmierer können Schwachstellen Dann: einfügen - Codegeneratoren auch (wenn nicht verifiziert) • Schnittstellenspezifikation erstellen • Sicherheitsanalyse (s.o.) Programm: • Verifizieren, dass Software + „the real thing“ (das ausgeführt wird) Schnittstellenspezifikation erfüllt. � Beides verifizieren (wenn möglich). Jan Jürjens, Open University: Model-based Security Engineering 17 Jan Jürjens, Open University: Model-based Security Engineering 18 3

2 Modell vs. Implementierung r Schnittstellen „meaning“ „meaning“ Spec: SSL compare meaning! Defined during p Backtrace model creation assignments Sent and received data Elements of connections q Find Has g Implement- Implement- I) Programmpunkte identifizieren: ation ation Equal? value ( r ), receive ( p ), guard ( g ), send ( q ) II) Überprüfen dass Bedingungen umgesetzt. .java Abstract model Jan Jürjens, Open University: Model-based Security Engineering 19 Jan Jürjens, Open University: Model-based Security Engineering 20 p Bedingungen Prüfen msg = Handshake.read(din, certType); Bedingung g umgesetzt ? p q g catch a) Runtime Check für g bei try q from Diagramm generieren: einfach + effectiv (aber Performanz). g only possible way b) Testen gegen Checks (aber Verwendung without throwing session.trustManager.checkServerTrusted exception (peerCerts,suite.getAuthType()); von Krypto). [ICFEM02] c) Automatische formale lokale Verifikation: q Bedingungen zwischen p und q implizieren g (mit automatischem Beweiser). msg = new Handshake(Handshake.Type.CLIENT_KEY_EXCHANGE, ckex); [ASE05,ASE06] msg.write (dout, version); Jan Jürjens, Open University: Model-based Security Engineering 21 Jan Jürjens, Open University: Model-based Security Engineering 22 Anwendungen von MBSE [ICSE07] Designs / Implementierung / Werk- Konfiguration für zeuge • Biometrie-, smart-card basierte Identifizierung • Authentisierung • Authorisierung (Benutzerberechti- gungen, z.B. in SAP Systemen) Analyse von Security Policies. [UML04, FASE05,ICSE06] Jan Jürjens, Open University: Model-based Security Engineering 23 Jan Jürjens, Open University: Model-based Security Engineering 24 4

2 Common Electronic Purse Specifications Globaler Standard für eGeldbörsen (Visa et al.). Smart card enthält Kontostand, sichert Transaktionen mithilfe Krypto. Formale Analyse von Load und Purchase Protokollen: signifikante Schwachstellen: Kauf- Umleitung, Betrug Ladegerätbetreiber vs. Bank. [ASE01] Jan Jürjens, Open University: Model-based Security Engineering 25 Jan Jürjens, Open University: Model-based Security Engineering 26 Schwachstelle I Schwachstelle II ml n : „Beweis“ rc nt : „Beweis“ für Bank für LSAM dass dass Lade- Ladegerät nur gerät Geld m n erhalten. erhielt. Aber: r n Aber: LSAM geteilt kann Validität zwischen nicht prüfen. Bank und Ladegerät. Jan Jürjens, Open University: Model-based Security Engineering 27 Jan Jürjens, Open University: Model-based Security Engineering 28 Biometrische Authentisierung Bankanwendung Sicherheitsanalyse von webbasierter Smart card basiertes System. Bankanwendung (“digitaler Analysiert parallel zur Entwicklung. Formularschrank”). Entdeckten drei signifikante Schwachstellen Geschichtete Architektur (SSL Protokoll, darauf in verschiedenen Versionen Client Authentisierungs-Protokoll) (Fehlbedienungszähler umgangen durch Anforderungen: löschen / wiederholen von Nachrichten; • Vertraulichkeit Smart-card unzureichend authentisiert • Authentisierung durch Mischen von Sitzungen). Jan Jürjens, Open University: Model-based Security Engineering 29 Jan Jürjens, Open University: Model-based Security Engineering 30 5