Methodische Grundlagendes Software-Engineering

(1)

Methodische Grundlagen Methodische Grundlagen des Software-Engineering des Software-Engineering

SS 2011 SS 2011

Willkommen zur Vorlesung

Methodische Grundlagen des Software-Engineering

im Sommersemester 2011 Prof. Dr. Jan Jürjens

TU Dortmund, Fakultät Informatik, Lehrstuhl XIV

(2)

SS 2011 SS 2011

22. Kryptographische Protokolle:

Sicherheitsanalyse

(3)

SS 2011 SS 2011

Einordnung

Protokolle mit UMLsec

(4)

SS 2011 SS 2011

Einordnung

Einführung UML / UMLsec

●

Business Prozesse

●

Qualitätsmanagement

●

Testen

●

Sicherheit

●

Sicheres Software Design

−

Einführung UML / UMLsec

−

Kryptographische Protokolle

−

Biometrische Authentifizierung

−

Elektronische Geldbörse

−

Weitere Anwendungsbeispiele

(5)

SS 2011 SS 2011

Angreifer-Wissen

Gegeben sei die Menge als initiales Wissen eines

Angreifers des Typs A. Sei die Menge der Krypto- Terme, die aus der Menge von Krypto-Termen und aus den Ausdrücken, die nach der n+1sten Iteration des Protokolls empfangen wurden, durch Anwendung der

Krypto-Operationen gebildet werden kann.

Definition (Dolev, Yao 1982).

Ein Datenwert M bleibt vertraulich gegen einen Angreifer

des Typs A, wenn es kein n mit M gibt. ∈

(6)

SS 2011 SS 2011

Sicherheitsanalyse in Logik erster Stufe

Idee: Menge der Datenwerte, die der Angreifer möglicherweise kennenlernen kann, von oben approximieren.

Das logische Prädikat knows(E) bedeutet, dass der Angreifer den Ausdruck E während der Ausführung des Protokolls möglicherweise kennenlernen kann.

Für jedes Geheimnis s kann man dann überprüfen, ob knows(s) aus den logischen Formeln, die das Systemverhalten repräsentieren, abgeleitet

werden kann.

(7)

SS 2011 SS 2011

Sicherheitsanalyse:

Grundlegende Regeln

Für initiales Angreiferwissen (K

⁰

): Definiere Axiom knows(E) für jeden Datenwert E, der dem Angreifer initial bekannt ist (protokoll-spezifisch, z.B. K

_A

, K

_A^-1

).

Modellieren, dass der Angreifer selber Krypto-Algorithmen einsetzen kann: Definiere Axiome:

∀ E

₁

,E

₂

.(knows(E

₁

) ∧ ^knows(E

₂

⁾ ⇒

knows(E

₁

::E

₂

) ∧ ^knows({E

1

}

_E2

) ∧

^knows(Dec

E2

(E

₁

)) ∧ ^knows(Sign

E2

(E

₁

)) ∧

^knows(Ext

E2

(E

₁

)))

∀ E.(knows(E) ⇒

knows(head(E)) ∧ knows(tail(E)))

(8)

SS 2011 SS 2011

Gegebenes Sequenzdiagramm für

o.g. Variante von TLS …

(9)

SS 2011 SS 2011

… und Verteilungsdiagramm …

Abgeleitete Angreifer-Aktionen auf

Kommunikationsdaten: read, delete, insert.

(10)

SS 2011 SS 2011

… Übersetzung in Logik erster Stufe

Gegeben eine Nachrichtenspezifikation

TR1=(in(msg_in),cond(msg_in),out(msg_out))

im Sequenzdiagramm, gefolgt von der Nachrichtenspezifikation TR2, ergibt Prädikat

PRED(TR1)= ^∀ msg_in. [knows(msg_in) ∧ cond(msg_in) ⇒ knows(msg_out)

∧ PRED(TR2)]

(Annahme: Nachrichtenreihenfolge überprüft (!).)

Hohe Abstraktion (zum Beispiel vom Sender und Empfänger der

Nachrichten) mit dem Ziel einer effizienten automatischen Analyse.

Nachteil: Es können “falsch-positive“ Ergebnisse auftreten (d.h.

angebliche Angriffsmöglichkeiten, die sich bei näherer

Untersuchung als unpraktikabel herausstellen).

(11)

SS 2011 SS 2011

knows(N) ∧ ^knows(K

_C

⁾ ∧ ^knows(Sign

_KC-1

^(C::K

_C

⁾⁾

∧ 8 ^init

¹

^,init

²

^,init

³

.[knows(init

₁

) ∧ knows(init

₂

) ∧

knows(init

₃

) ∧ ^snd(Ext

_{init 2}

^(init

₃

^{)) = init}

₂

⇒ knows({Sign

_KS-1

(…)}

_…

) ∧ [knows(Sign…)] ∧ .∀ resp

₁

,resp

₂

. [… ⇒ ^...]]

Beispiel:

TLS

Variante

(12)

SS 2011 SS 2011

Ausführung im Systemkontext

Aktivitätsdiagramm

(13)

SS 2011 SS 2011

Sicherheitsanforderungen an Daten

Klassendiagramm.

Frage: Vertraulichkeit von Sitzungsschlüssel s

bewahrt, d.h. knows(s) ableitbar ?

(14)

SS 2011 SS 2011

Überblick Variante von TLS:

Gesamtes Modell

(15)

SS 2011 SS 2011

Übersetzung in Logik in

Theorembeweiser-Notation I

(16)

SS 2011 SS 2011

Übersetzung in Logik in

Theorembeweiser-Notation II

(17)

SS 2011 SS 2011

Überraschung …

(18)

SS 2011 SS 2011

… Was bedeutet das ?

Kann knows(s ) ableiten (!).

Daher: Protokoll bewahrt nicht die Vertraulichkeit des Sitzungsschlüssels s gegen Angreifer.

 Absolut unsicher in Bezug auf festgesetzte Ziele.

Aber wieso ?

Kann Angriffszenario mittels prologbasierten

Angriffsgenerator erzeugen.

(19)

SS 2011 SS 2011

Man-in-the-Middle Angriff

(20)

SS 2011 SS 2011

Korrigiertes Protokoll

Analyse: knows(s) nicht ableitbar, d.h. Vertraulichkeit von s

bewahrt.

(21)

SS 2011 SS 2011

Zusammenfassung

●

TLS-Variante

●

Protokollmodellierung

●

Sicherheitsanalyse

●

Korrigierte Version

(22)

SS 2011 SS 2011

Methodische Grundlagendes Software-Engineering

Willkommen zur Vorlesung

Methodische Grundlagen des Software-Engineering

im Sommersemester 2011 Prof. Dr. Jan Jürjens

TU Dortmund, Fakultät Informatik, Lehrstuhl XIV

22. Kryptographische Protokolle:

Sicherheitsanalyse

Einordnung

Protokolle mit UMLsec

Einordnung

Einführung UML / UMLsec

Business Prozesse

Qualitätsmanagement

Testen

Sicherheit

Sicheres Software Design

Einführung UML / UMLsec

Kryptographische Protokolle

Biometrische Authentifizierung

Elektronische Geldbörse

Weitere Anwendungsbeispiele

Angreifer-Wissen

Gegeben sei die Menge als initiales Wissen eines

Angreifers des Typs A. Sei die Menge der Krypto- Terme, die aus der Menge von Krypto-Termen und aus den Ausdrücken, die nach der n+1sten Iteration des Protokolls empfangen wurden, durch Anwendung der

Krypto-Operationen gebildet werden kann.

Definition (Dolev, Yao 1982).

Ein Datenwert M bleibt vertraulich gegen einen Angreifer

des Typs A, wenn es kein n mit M gibt. ∈

Sicherheitsanalyse in Logik erster Stufe

Idee: Menge der Datenwerte, die der Angreifer möglicherweise kennenlernen kann, von oben approximieren.

Das logische Prädikat knows(E) bedeutet, dass der Angreifer den Ausdruck E während der Ausführung des Protokolls möglicherweise kennenlernen kann.

Für jedes Geheimnis s kann man dann überprüfen, ob knows(s) aus den logischen Formeln, die das Systemverhalten repräsentieren, abgeleitet

werden kann.

Sicherheitsanalyse:

Grundlegende Regeln

Für initiales Angreiferwissen (K

): Definiere Axiom knows(E) für jeden Datenwert E, der dem Angreifer initial bekannt ist (protokoll-spezifisch, z.B. K

, K

).

Modellieren, dass der Angreifer selber Krypto-Algorithmen einsetzen kann: Definiere Axiome:

∀ E

,E

.(knows(E

) ∧ knows(E

) ⇒

knows(E

::E

) ∧ knows({E

}

) ∧

knows(Dec

(E

)) ∧ knows(Sign

(E

)) ∧

knows(Ext

(E

)))

∀ E.(knows(E) ⇒

knows(head(E)) ∧ knows(tail(E)))

Gegebenes Sequenzdiagramm für

o.g. Variante von TLS …

… und Verteilungsdiagramm …

Abgeleitete Angreifer-Aktionen auf

Kommunikationsdaten: read, delete, insert.

… Übersetzung in Logik erster Stufe

Gegeben eine Nachrichtenspezifikation

TR1=(in(msg_in),cond(msg_in),out(msg_out))

im Sequenzdiagramm, gefolgt von der Nachrichtenspezifikation TR2, ergibt Prädikat

PRED(TR1)= ∀ msg_in. [knows(msg_in) ∧ cond(msg_in) ⇒ knows(msg_out)

∧ PRED(TR2)]

(Annahme: Nachrichtenreihenfolge überprüft (!).)

Hohe Abstraktion (zum Beispiel vom Sender und Empfänger der

Nachrichten) mit dem Ziel einer effizienten automatischen Analyse.

Nachteil: Es können “falsch-positive“ Ergebnisse auftreten (d.h.

angebliche Angriffsmöglichkeiten, die sich bei näherer

Untersuchung als unpraktikabel herausstellen).

knows(N) ∧ knows(K

) ∧ knows(Sign

(C::K

) ∧ ^knows(E

⁾ ⇒

) ∧ ^knows({E

^knows(Dec

)) ∧ ^knows(Sign

^knows(Ext

PRED(TR1)= ^∀ msg_in. [knows(msg_in) ∧ cond(msg_in) ⇒ knows(msg_out)

knows(N) ∧ ^knows(K

⁾ ∧ ^knows(Sign

^(C::K

⁾⁾

∧ 8 ^init

^,init

^,init

) ∧ ^snd(Ext

^(init

^{)) = init}

. [… ⇒ ^...]]