German Research Center for Artificial Intelligence Informationssicherheit 2 Sommersemester 2010 Prof. Dr. Dieter Hutter Deutsches Forschungszentrum für

German Research Center forArtificial Intelligence

Informationssicherheit 2Informationssicherheit 2

Sommersemester 2010Sommersemester 2010

Prof. Dr. Dieter HutterProf. Dr. Dieter Hutter

Deutsches Forschungszentrum für Künstliche IntelligenzDeutsches Forschungszentrum für Künstliche IntelligenzCartesium: Raum 2.47 Cartesium: Raum 2.47 Tel. 0421 218-64277Tel. 0421 218-64277

[email protected]@dfki.de


GenerellesGenerelles

• 6 ETCS-Punkte

• Vorlesung– Dienstag 8 Uhr (c.t.) – 10 Uhr (MZH 5210)

• Übungen: – Dienstag 10 – 12 Uhr (MZH 1110)

• Kenntnisse aus Informationssicherheit 1 sind (manchmal) hilfreich aber nicht nötig


Folien, Übungsblätter, etc.Folien, Übungsblätter, etc.

Folien

• Folien sind auf Englisch (Notationen!)• Folien der Vorlesung gibt es auf dem Web

– http://www.informatik.uni-bremen.de/agbkb/lehre/sicherheit2/

• Folien sind (üblicherweise) nach der Vorlesung verfügbar• Webseiten sind nur innerhalb der Uni Bremen verfügbar (VPN!)

Übungen

• Übungsblätter gibt es auf dem Web (s.o.)• Ausgabe immer Dienstags

– Erstes Übungsblatt gibt es nächsten Dienstag• Abgabe vor/während/nach der Vorlesung


LiteraturLiteratur

• Foliensätze als Kernmaterial

• Ausgewählte Fachartikel als Zusatzmaterial

• Es gibt (noch) keine Bücher, die den Vorlesungsinhalt komplett erfassen

• Zum weiteren Stöbern– Dieter Gollmann: Computer Security (Wiley)– Matt Bishop: Computer Security (Addison Wesley)– Joachim Biskup: Security in Computing Systems (Springer)


PrüfungPrüfung

• Fachgespräch oder Modulprüfung– Anmeldefristen beachten!– Individuelle Termine nach Absprache zwischen Juli und

September

• Fachgespräch– Voraussetzung: Erreichen von 50% der Punkte aus dem

Übungsbetrieb

• Modulprüfung– Keine Abgabe der Übungsblätter nötig

(aber dringend angeraten !)


Security vs. SafetySecurity vs. Safety

• Safety– Verhindern von Systemzuständen, die Benutzer gefährden – Bedrohung von “Innen”

• Fehlfunktion des Systems (z.B. Ampelanlage, Autopilot, etc.)– Fail–Safe Konzepte, Fehlertoleranz

• Security– Angriffe durch böswillige Teilnehmer, Beobachter etc.– Bedrohungen von “Aussen” – Analyse: was kann ein Angreifer

• Modellierung des Systems und (!) seiner (bösartigen) Umwelt• Analyse der möglichen Situationen

In dieser Vorlesung beschäftigen wir uns mit Security !


Modellierung von SicherheitModellierung von Sicherheit

• Was macht ein sicheres System aus?– Vertraulichkeit, Integrität, Verfügbarkeit, …

• Was sind potentielle Bedrohungen eines Systems?– Was sind die Fähigkeiten eines Angreifers– Modellierung eines Angreifers

• Wann ist man sich sicher, dass ein System sicher ist?– Entwicklungsmethodik für sichere Systeme– Verifikation, mathematische Beweise


SicherheitsprotokolleSicherheitsprotokolle

• Modellierung von Sicherheitsprotokollen– Abstraktion von unnötigen Details, aber was ist unnötig?

• Wann ist ein Protokoll sicher?• Modellierung des Angreifers

– Was kann der Angreifer, Wieviel Ressourcen hat der Angreifer?– Nachrichten abfangen, erzeugen, manipulieren,

alle Schlüssel aufzählen ?• Vom Testen zur Verifikation

– von unendlich vielen möglichen Protokollläufen zu endlich vielen Testfällen

– Theorie der Sicherheitsprotokolle und Formale Verifikation


SicherheitspolitikenSicherheitspolitiken

• Modellierung von formalen Sicherheitspolitiken– Zugriffskontrolle vs. Informationsflusstechniken

• Was lernt ein Beobachter aus einem Systemverhalten?– Hoffentlich nichts, aber…

• Modellierung und Verifikation von Informationsflusseigenschaften– Typsysteme für Programme, Programmanalysetechniken– Algebraische Modellierung für (abstrakte) Spezifikationen

• Anwendungen: Semantic Web, Service Orientierte Architekturen


IntroductionIntroduction


Security ObjectivesSecurity Objectives

• Privacy:– Confidentiality (of data) – Anonymity (of participants)

• Integrity:– Integrity (of data)– Authentication (of participants)

• Liability:– Availability (of resources)– Accountability (of participants)


owners

countermeasures

threat agents

vulnerabilities

risk

assets

threats

to reduce

leading to

that increase

that may bereduced by

that may possess

to

impose

give riseto

wish to abuse and/or may damage

may be aware of

thatexploit

Wish to minimize

value

to

Security (Common Criteria)Security (Common Criteria)


ConfidentialityConfidentiality

Confidentiality (of owners data): No unauthorized participant (user) can discover content of (storage) “locations” and/or” messages (communication).

• Encryption of data (Cryptography)• Hiding of data (Steganography)• Restricting (read) access to data (Access Control)

Who is allowed to read which data under which conditions ? (Security policies)


AnonymityAnonymity

Anonymity: A participant (user) can access resources or services without disclosing his/her identity.

• Pseudonyms• Network: Proxy-server, Mixes

Who communicates with whom or reads which data ?


IntegrityIntegrity

Integrity (of owners data): No unauthorized participant (user) can manipulate data.

• (Digital) Signatures• Hash functions• Restricting (write) access to data (Access

Control)

Who is allowed to change which data under which conditions ? (Security policies)


AuthenticationAuthentication

Authentication: Identity of a participant (user) can be determined (checked, proved).

• Passwords (shared knowledge)• Biometric methods• Public – Key infrastructures

Who is using a system or sending a message?


AvailabiltyAvailabilty

Availability: No unauthorized impairment of services is possible.

Examples: Blocking CPU-resources by Java-appletsFlooding network with e-mails


AccountabilityAccountability

Accountability: Sender and/or receiver of information cannot (successfully) deny having sent or received information. Communication takes place in a provable way.

• Proof of communication (active agreement) required.

• Digital Signatures


Security ObjectivesSecurity Objectives

Security objectives are not always independent.

Examples:

• Anonymity weakens Accountability• Confidentiality weakens Accountability• Access Control relies on Authentication


Multilateral SecurityMultilateral Security

• Each participant has its own security issues• Each participant can formulate its own issues• Conflicts have to be resolved and enforced


Towards Certified Secure SystemsTowards Certified Secure Systems

Existing systems are insufficent with respect to

– Usage– Administration– Construction

Problems– Consequences of individual

decisions? – Are all security aspects

covered?

Challenges of IT-security– Increased complexity of

systems and their requirements

– Formal foundation of system-wide security guarantees

– Intuitive understanding of security in the large


Schwerpunktprogramm (DFG): Schwerpunktprogramm (DFG): „Zuverlässig sichere „Zuverlässig sichere Softwaresysteme“Softwaresysteme“

Schwerpunktprogramm Zuverlässig Sichere SoftwaresystemeSchwerpunktprogramm Zuverlässig Sichere Softwaresysteme

Formales Sicherheits-Engineering

Zuverlässig sichere Softwaresysteme

Wun

sch

nach

Si

cher

heits

info

rmati

onAn

ford

erun

gs-d

efini

tion

Syst

emar

chite

ktur

Verfeinerung / Dekomposition

Fundierte und

verständliche

Sicherheitsgarantie

Reparatur

Erklärung der Sicherheitsaspekte

Formal abstrahierte Sicherheitseigenschaft

Abstraktion der Eigenschaften

Modellierung der Sicherheits-

anforderungen

Formal spezifizierte Sicherheitseigenschaft

Formal fundiertes Zertifikat für

Sicherheitsgarantie

Implementierung/ Modellierung

Programm / FormaleSystemspezifikation

Sicherheits-analyse

Initiatoren:

Heiko Mantel (Darmstadt)Dieter Hutter (Bremen)Günter Müller (Freiburg)Tobias Nipkow (München)Gregor Snelting (Karlsruhe)


ModelingModeling

WorldWorldWorldWorld

ModelModelModelModel

InterpretationInterpretation(relating results in the (relating results in the

model to the real world)model to the real world)

AbstractionAbstraction(not all aspects (not all aspects

are modeled)are modeled)

(calculus to reason inside model)(calculus to reason inside model)

Models are specific to individual purposesModels are specific to individual purposes

e.g.e.g.

• CryptographyCryptography

• Security protocolsSecurity protocols

• Security policiesSecurity policies

• … …


Modeling Security AspectsModeling Security Aspects

Modeling both: system and attacker !

InterpretationInterpretationAbstractionAbstraction

WorldWorld

ModelModel


Calculi for ModelingCalculi for Modeling

• Executional models– We want to compute / reason in the model !

• Mathematical models– Numerical calculations

• Logical models– Symbolic calculations– Operations on syntactical entities– Semantic interpretation of syntactical entities


Example: Evaluation of BooleanExample: Evaluation of Boolean

< true, < true, > > !! true true

< false, < false, > > !! false false

< a< a00, , > > !! n < a n < a11, , > > !! m m

< a< a00 = a = a11, , > > !! true true

< a< a00, , > > !! n < a n < a11, , > > !! m m

< a< a00 = a = a11, , > > !! false false

< b, < b, > > !! true true

< < :: b, b, > > !! false false

< b, < b, > > !! false false

< < :: b, b, > > !! true true

If n and m are equalIf n and m are equal

If n and m are not equalIf n and m are not equal


Security AspectsSecurity Aspects

• Security engineering and its modeling

– Description and analysis of security mechanisms cryptography: basic mechanisms ) special lecture building secure systems on a sound scientific

(mathematical) basis: formal approaches () verification of solutions)

existing technical solutions as background

- Development in-the-large part of general software engineering assessment of security features examples for real systems

Documents

German Research Center for Artificial Intelligence Informationssicherheit 2 Sommersemester 2010 Prof. Dr. Dieter Hutter Deutsches Forschungszentrum für