Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
20 Sichere Architekturen
1
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011
Willkommen zur VorlesungMethodische Grundlagen des Software-
Engineeringim Sommersemester 2011
Prof. Dr. Jan JürjensTU Dortmund, Fakultät Informatik, Lehrstuhl XIV
20 Sichere Architekturen
2
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011
20. Sichere Architekturen
19 Modell-basierte Sicherheit mit UML
3
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011
EinordnungEinführung UML / UMLsec
19 Modell-basierte Sicherheit mit UML
4
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011
EinordnungEinfü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
20 Sichere Architekturen
5
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Java Sicherheits-Architektur
Ursprünglich (JDK 1.0): Sandkasten-Modell.
Zu simplistisch und restriktiv.
JDK 1.2/1.3: feinere Sicherheitskontrolle (signing,
sealing, guarding objects, . . . )
Aber: komplex, also Verwendung fehleranfällig.
20 Sichere Architekturen
6
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Java Sicherheits-Politiken
Berechtigungseinträge bestehen aus:
• Schutzdomänen (URL's und Signaturschlüssel)
• Ziel-Resourcen (z.B. Dateien auf lokaler Machine)
• zugehörige Berechtigungen (z.B. read, write, execute)
20 Sichere Architekturen
7
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Signed und Sealed Objects
Brauchen Integritätsschutz für Objekte, die zur Authentisierung verwendet oder zwischen JVMs ausgetauscht werden.
SignedObject enthält Objekt und seine Signatur.
Für Vertraulichkeitsschutz: SealedObject ist ein
verschlüsseltes Objekt.
20 Sichere Architekturen
8
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Guarded Objects
java.security.GuardedObject schützt Zugang zu anderen Objekten.
● Zugang über getObject Methode.● checkGuard Methode in java.security. Guard
kontrolliert Zugang.● Gibt Referenz oder
SecurityException.
20 Sichere Architekturen
9
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Problem: Komplexität
• Rechtevergabe abhängig von Ausführungskontext. • Zugangskontrollentscheidungen bezüglich
verschiedener Threads.• Können verschiedene Schutzdomäne betreffen.• Methode doPrivileged() unabhängig von
Ausführungskontext.Gibt Werkzeuge zur Überprüfung.
20 Sichere Architekturen
10
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Entwurfsprozess
• Zugangskontroll-Anforderungen für sensitive Objekte formulieren.
• Guard objects mit Zugangskontrollen definieren.• Überprüfen, dass Schutz der guard objects
hinreichend ist.• Überprüfen, dass Zugangskontrolle konsistent
mit Funktionalität ist.• Überprüfen, dass mobile Objekte hinreichend
geschützt sind.
20 Sichere Architekturen
11
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Frage
Guarded objects korrekt eingesetzt ?
20 Sichere Architekturen
12
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011<<guarded access>>
Stellt sicher, dass in Java <<guarded>> Klassen nur durch {guard} Klassen aufgerufen werden können.
Constraints:
• Referenzen der <<guarded>> Objekte bleiben geheim.
• Jede <<guarded>> Klasse ist durch eine zugehörige {guard} Klasse abgesichert.
20 Sichere Architekturen
13
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Example <<guarded access>>
<<guarded access>> überprüft, dass Guard korrekt definiert.
20 Sichere Architekturen
14
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Beispiel: Finanz-Anfrage
Die Internetbank bankeasy.com und ein Finanzberater finance.com bieten Dienstleistungen an. Die Applets benötigen dabei bestimmte Privilegien.
• Applets von der Bank, die signiert sind, sollen Daten zwischen 13 und 14 Uhr lesen und schreiben dürfen.
• Applets von dem Finanzdienstleister, die signiert sind, sollen den Micropayment-Schlüssel 5 mal die Woche nutzendürfen.
20 Sichere Architekturen
15
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Finanz-Anfrage: Klassendiagramm
Für Integrität und Vertraulichkeit werden Daten als Signed- und Sealed-Objekte über Internet gesendet.
GuardedObjects kontrollieren Zugriff.
20 Sichere Architekturen
16
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011
Finanz-Anfrage:
Guard Objects (Schritt 2)
timeslot true zwischen
13 und 14 Uhr.
weeklimit true bisZugang fünf malgewährt wird;incThisWeek erhöhtZähler.
20 Sichere Architekturen
17
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Finanz-Anfrage: Validierung
Guard Objekt gibt genügend Schutz (Schritt 3):
Analyse-Ergebnis: UML Spezifikation für Guard Objekte erteilt nur Genehmigungen, die durch Zugangsanforderungen impliziert sind.– z.B.: Unter der Annahme, dass das aktuell ausgeführte Applet von
Finance stammt und signiert ist, wird der Zugriff gewährt, wenn ein Micropayment Key genutzt wird, der bisher weniger als 5 mal zum Einsatz kam.
Zugangskontrolle konsistent mit Funktionalität (Schritt 4):
Analyseergebnis: Jedes Objekt, das laut Spezifikation Zugriff auf ein guarded Objekt erhalten soll, erhält diesen auch.
Mobile Objekte ausreichend geschützt (Schritt 5), da Objekte, die über das Internet gesendet werden signiert und versiegelt sind.
20 Sichere Architekturen
18
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011CORBA Zugangskontrolle
Objekt-Zugangskontrolle kontrolliert Zugang von Client zu Objekt über gegebene Methode.
Realisiert durch ORB und Security Service.
Access Decision Functions entscheiden, ob Zugang erlaubt. Abhängig von:
– Aufgerufener Operation,
– Privilegien des Principals, in dessen Vertretung der Client agiert,
– Kontrollattribute des Zielobjektes.
20 Sichere Architekturen
19
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011
Example: CORBA Access Control with UMLsec
20 Sichere Architekturen
20
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011
Example: CORBA Access Control with UMLsec
20 Sichere Architekturen
21
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011
Example: CORBA Access Control with UMLsec
20 Sichere Architekturen
22
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011
Example: CORBA Access Control with UMLsec
20 Sichere Architekturen
23
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Frage
Kein partielle Preisgabe von Geheimnissen?
20 Sichere Architekturen
24
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011<<no down–flow>>
Stelle sicheren Informationsfluss sicher.
Bedingung:
Jeder Datenwert, der als {secrecy} spezifiziert ist, darf nur die Datenwerte beeinflussen, die auch als {secrecy} spezifiert sind.
(Kann die Bedingung mit Bezug auf formale Ausführungsemantik formalisieren).
20 Sichere Architekturen
25
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Beispiel <<no down-flow>>
Information über „money“ darf nicht offen gelegt werden
20 Sichere Architekturen
26
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Beispiel <<no down-flow>>
money < 1000
money >= 1000
20 Sichere Architekturen
27
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Beispiel <<no down-flow>>
Externer Zugang
20 Sichere Architekturen
28
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Beispiel <<no down-flow>>
money < 1000
money >= 1000Externer Zugang
Information über „money“ darf nicht offen gelegt werden
+
20 Sichere Architekturen
29
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Beispiel <<no down-flow>>
<<no down–flow>> verletzt: Partielle Information über das Geheimnis von wm() werden vom nicht geheimen rx() zurückgegeben.
20 Sichere Architekturen
30
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Sicherer Einsatz von Kryptographie
Variante von TLS (INFOCOM`99).
Kryptoprotokoll sicher gegen Standard- Angreifer?
20 Sichere Architekturen
31
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011<<data security>>
Stellt Sicherheitsanforderungen an Daten, die als <<critical>> markiert sind, sicher. Dabei wird das Bedrohungsszenario aus dem zugehörigen Verteilungsdiagramm (Deployment-Diagramm) zugrundegelegt.
Constraints: Daten, die als {secrecy}, {integrity},
{authenticity}, {fresh} markiert sind, erfüllen die auf
Basis der Ausführungssemantik der UML Diagramme
formalisierten Sicherheitsanforderungen.
20 Sichere Architekturen
32
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011Beispiel <<data security>>
Variante von TLS (INFOCOM`99).
Verletzt {secrecy} von s gegen Standard Angreifer.
20 Sichere Architekturen
33
Methodische Grundlagen Methodische Grundlagen des Software-Engineeringdes Software-Engineering
SS 2011SS 2011UMLsec Intro: Übersicht
Sicherheitsanforderungen: <<secrecy>>,…
Angriffszenarien: Benutze Threatsadv
(ster).
Sicherheitskonzepte: Beispiel <<smart card>>.
Sicherheitsmechanismen: Beispiel <guarded access>>.
Sicherheitsalgorithmen: Verschlüsselung eingebaut.
Physikalische Sicherheit: Gegeben in Verteilungsdiagramm.
Sicherheitsmanagement: Benutze Aktivitätsdiagramme.
Technologie-spezifisch: Java-, CORBA-Sicherheit.