Systemsicherheit - tu-ilmenau.de · Systemsicherheit, Sommer 2018 © wk - 3 - Begriffe TCB (Trusted Computing Base) Die Menge aller Funktionen eines IT -Systems, die zur Herstellung

System sicherheit, Som m er 2018 © w k - 1 -

SystemsicherheitKapitel 5: Sicherheitsarchitekturen

Winfried E. KühnhauserSommer 2018

W infried E . Kühnhauser

C SI

Technische U niversität Ilm enau

w w w .tu-ilm enau.de


Roadmap

5 Sicherheitsarchitekturen

Sicherheitsmechanismen

SicherheitspolitikenModellierung und Spezifikation

Sicherheitsarchitekturen

Sicherheitsanforderungen


Begriffe

TCB (Trusted Computing Base)

Die Menge aller Funktionen eines IT-Systems, die zur Herstellung derSicherheitseigenschaften notwendig und hinreichen sind

SicherheitsarchitekturDer Teil einer Systemarchitektur, der die TCB implementiert

SicherheitsmechanismenAlgorithmen und Datenstrukturen zur Implementierung der Funktionen einerTCB



Sicherheitsarchitekturen kennen wir schon lange …



ArchitekturkomponentenGebäude, Mauern, Fenster, Türen, Wassergräben, Zugbrücken

ArchitekturAufgaben und Zusammenspiel der Komponenten

Ziel einer SicherheitsarchitekturKonstruktion einer Burganlage so, dass Sicherheitspolitiken durchsetzbar sind

Vorhandensein geeigneter Komponenten/Mechanismen

Unumgehbarkeit

Manipulationssicherheit

→ Architekturprinzipien

5 S icherheitsarchitekturen


MonolithischeBetriebssystem-

architektur

: involvierte Systemkomponenten

Ein (schlimmes) BeispielZugriffssteuerungspolitikimplementierung in Linux

Filesystem Sockets Pipes

Proz.mgmt

open(filename, openmode)

{ ino=namei(filename);switch ino.objecttype of

file:

if (filesystem.checkpermission(ino,openmode))

{ fd=filesystem.open(ino, ...) ...}socket: ...

}

Man beurteile die Politikimplementierung in dieser Architektur bzgl.§ Unumgehbarkeit der Zugriffssteuerung (und deren Nachweisbarkeit)§ Manipulationssicherheit der Politikimplementierung (und deren Nachweisbarkeit)§ Korrektheit der TCB (und deren Nachweisbarkeit)

. . . (ca. 250 Systemaufrufe)

Betriebssystem-Schnittstelle (Application Programmer´s Interface (API))



Problemfelder PDPs (policy decision points)PEPs (policy enforcement points)

sindverstreut über einen weiten Bereich des Betriebssystems→ Problem des Sicherheitsarchitekturdesigns

nicht robust gegenüber Fehlern/Malware◆ innerhalb des gesamten Betriebssystems◆ insbesondere in dynamisch geladenen BS-Modulen

→ Problem der Sicherheitsarchitekturimplementierung



... und damit nicht genug:

Linux set-user-id-Programmeführen sicherheitssensitive Funktionen aus

nehmen während ihrer Ausführung andere User-Id ein als die des Aufrufershaben damit andere, i.d.R. erweiterte Rechte

insbesondere die der „root“ User-Id

→ sämtliche solche Programme gehören zur TCB (und damit zur Sicherheitsarchitektur!)

z.B. /usr/bin/passwd

/opt/google/chrome/chrome-sandbox (Autor: Google!)/usr/lib/virtualbox/VirtualBox (Autor: Oracle!)

Über die beobachtbaren Konsequenzen braucht man sich somit nicht zu wundern ...



Problem alsoBSe, Middleware-Plattformen und Applikationssysteme sind großlediglich eine kleine Menge ihrer Funktionen gehört logisch zur TCB

→ Sicherheitsarchitekturdesign so, dass die TCB-Funktionen in einem◆ unumgehbaren (Vollständigkeit der Kontrolle)◆ isolierten (Manipulationssicherheit) ◆ vertrauenswürdigen (Korrektheit)

Kern realisiert sind→ Sicherheitsarchitekturimplementierung so, dass diese Eigenschaften

aufrecht erhalten sind



5.1 Architekturprinzipien

Zielvollständigemanipulationssicherenachweisbare

Beherrschung aller sicherheitsrelevanten Operationen in einem IT-System

WegDefinition grundlegender Designprinzipien für Sicherheitsarchitekturen

5.1 Architekturprinzip ien


Die Referenzmonitor-Architekturprinzipien

Es gibt eine Architekturkomponente, die

(RM 1) bei sämtlichen Subjekt/Objekt-Interaktionen involviert ist→ total mediation property

(RM 2) geschützt ist vor unautorisierter Manipulation→ tamperproofness

(RM 3) hinreichend klein und wohlstrukturiert ist, um formalen Analysemethoden zugänglich zu sein→ verifyability

Nach diesen Prinzipien gebaute Sicherheitsarchitekturkomponente:„Referenzmonitor“



Idee

→ 1 PDP (Politikimplementierung)viele PEPs (Interzeptoren, Politikdurchsetzung)

Filesystem Sockets Pipes

Proz.mgmt

open(filename, openmode)

{ ino=namei(filename);switch ino.objecttype of

file:

if (filesystem.checkpermission(ino,openmode))

{ fd=filesystem.open(ino, ...) ...}socket: ...

}

. . . (ca. 250 Systemaufrufe)

Betriebssystem-Schnittstelle (Application Programmer´s Interface (API))


Security Server

Policy


Referenzmonitor Kernkomponente einer TCBumfasst typischerweise◆ Implementierung der Sicherheitspolitik(en) (PDPs)

• Modellzustand (z.B. ZM, Subjekt/Objekt-Attributierung)• Modelllogik (z.B. Autorisierungsschema)

◆ Durchsetzungsmechanismen (PEPs)

klammert in der Regel aus (wg. Komplexität und Größe, RM 3)◆ Authentisierung◆ kryptografische Mechanismen

◆ z.T. auch Modellzustand (z.B. ZSLs)



Folgen von (RM 3) für TCBsgeringe Größe, wenig Funktionengeringe Komplexität, einfache Funktionenstarke Isolationpräzise bestimmter Perimeter

TCBs



Highway to Hell:TCBTCB ImplementierungSicherheitsarchitekturBeachtung der Referenzmonitorprinzipien

heutiger IT Systeme, z.B.politikkontrollierte BSepolitikkontrollierte Anwendungssystemepolitikkontrollierte MiddlewareMikrokern basierte BSe ?



Politik kontrolliertes BS – Monolithischer BS KernPolitik auf Systemebene

Application

Process

Application

Process

Application

Process

Application

Process

OSFile System Policy Server

S={s ,s ,s }, O={o,o,so }...commandread(s,o)if readÎm(s,o)

enter(s,o) in h;"oÎO, (o,o)ÎC: delete read from m(s,o);"oÎO, o¹o: delete write inm(s,o);

end ifend...



Politik kontrolliertes BS – Monolithischer BS Kern

Application

Process

Application

Process

Application

Process

Application

Process




end ifend...

TCB – Funktionale Sicht



Politik kontrolliertes BS – Monolithischer BS Kern

Application

Process

Application

Process

Application

Process

Application

Process




end ifend...

TCB – Aus Sicht ihrer Implementierung



Politik kontrolliertes BS – Mikrokernarchitektur (Nizza)Politik auf Systemebene

Microkernel

Paravirtualized Legacy OS

Trusted Loader

TrustedName Server

SecurityPolicy

TrustedGUI…

LegacyApplication

LegacyApplication

LegacyApplication

SecureApplication



Politik kontrolliertes BS – Mikrokernarchitektur (Nizza)

Microkernel


Trusted Loader

TrustedName Server

SecurityPolicy

TrustedGUI…

LegacyApplication

LegacyApplication

LegacyApplication

Secure

Application




Politik kontrolliertes BS – Mikrokernarchitektur (Nizza)

Microkernel


Trusted Loader

TrustedName Server

SecurityPolicy

TrustedGUI…

LegacyApplication

LegacyApplication

LegacyApplication

Secure

Application




Politik kontrolliertes Anwendungssystem

Politik auf Middleware-Ebene

OS OS

WebServices

Application

Process

Application

Process

S={s ,s ,s }, O={o,o,so }...commandread(s,o)

if readÎm(s,o)enter(s,o) in h;"oÎO, (o,o)ÎC:

delete read from m(s,o);"oÎO, o¹o:

delete write inm(s,o); end ifend...



in flow

Handlerm

Handler2

Handler1• • •

AxisEngine

instanciates

out flow

TransportSender

Handler1

Handler2

Handlern• • •

AxisEngine

instanciates

Client

Stub

SOAP Reply

CoordinatorOutInAxisOperation

instanciates

SOAP Request(by HTTP, JMS ...)

MCreq MCresp

MCresp



out flow

Handlerm

Handler2

Handler1• • •

AxisEngine

in flow

Handler1

Handler2

Handlern• • •

AxisEngine

MCreq

MCresp

SOAP Reply

SOAP Request

Axi

sSer

vlet

HTT

P/JM

STr

ansp

ort U

tiliti

es

TransportSender

Web

Ser

vice

MessageReceiver

MCreq

MCresp



in flow

Handlerm

Handler2

Handler1• • •

AxisEngine

instanciates

out flow

TransportSender

Handler1

Handler2

Handlern• • •

AxisEngine

instanciates

Client

Stub

SOAP Reply


instanciates


MCreq MCresp

MCresp




out flow

Handlerm

Handler2

Handler1• • •

AxisEngine

in flow

Handler1

Handler2

Handlern• • •

AxisEngine

MCreq

MCresp

SOAP Reply

SOAP Request

Axi

sSer

vlet

HTT

P/JM

STr

ansp

ort U

tiliti

es

TransportSender

Web

Ser

vice

MessageReceiver

MCreq

MCresp




OS

in flow

Handlerm

Handler2

Handler1• • •

AxisEngine

instanciates

out flow

TransportSender

Handler1

Handler2

Handlern• • •

AxisEngine

instanciates

Client

Stub

SOAP Reply


instanciates


MCreq MCresp

MCresp



OS

out flow

Handlerm

Handler2

Handler1• • •

AxisEngine

in flow

Handler1

Handler2

Handlern• • •

AxisEngine

MCreq

MCresp

SOAP Reply

SOAP Request

Axi

sSer

vlet

HTT

P/JM

STr

ansp

ort U

tiliti

es

TransportSender

Web

Ser

vice

MessageReceiver

MCreq

MCresp



Politik kontrolliertes AnwendungssystemPolitik auf Anwendungsebene

Application

Process

Application

Process

Application

Process

Policy ServerS={s ,s ,s }, O={o,o,so }...commandread(s,o)if readÎm(s,o)

enter(s,o) in h;"oÎO, (o,o)ÎC: deletereadfromm(s,o);"oÎO, o¹o: deletewriteinm(s,o);

end ifend...

OS




Application

Process

Application

Process

OS

Application

Process

Policy Server

S={s ,s ,s }, O={o,o,so }

...

commandread(s,o)if readÎm(s,o)enter(s,o) in h;

"oÎO, (o,o)ÎC: delete read from m(s,o);

"oÎO, o¹o: delete write inm(s,o);

end ifend...





Application

Process

Application

Process

OS

Application

Process

Policy Server

S={s ,s ,s }, O={o,o,so }

...

commandread(s,o)if readÎm(s,o)enter(s,o) in h;

"oÎO, (o,o)ÎC: delete read from m(s,o);

"oÎO, o¹o: delete write inm(s,o);

end ifend...




Stand der Kunstzahlreiche eher schwache Realisierungen in◆ Standard-BSen

◆ Middleware◆ Applikationen

stärkere Ansätze◆ in Mikrokern basierten BS-Architekturen (e.g. L4/Nizza)

◆ in jüngeren BSen (e.g. SELinux, Trusted BSD, Open Solaris)



5.2 Sicherheitsarchitekturen von Betriebssystemen

ProblemImplementierung der BS-TCB so, dass

Referenzmonitorprinzipiendie vielschichtigen Sicherheitsanforderungen der Anwendungssysteme

erfüllt werden

5.2 S icherheitsarchitekturen von Betriebssystem en


5.2.1 Nizza(TU Dresden)

ZieleSicherheitsarchitektur mit kleiner TCB◆ vollständige Kontrolle (RM 1)

◆ manipulationssichere Implementierung (RM 2)◆ kleine Implementierung (RM 3)

Wahrung der Funktionalität heutiger ◆ Standard-BSe

◆ Standard-Anwendungssysteme

5.2.1 N izza


KonzepteReferenzmonitorprinzipien: Trennung

◆ des BS◆ der Anwendungen

in sicherheitskritische und unkritische Komponenten→ präzise Identifikation einer (minimalen) TCB

Funktionalitätswahrung→ Paravirtualisierung von Standard-BSen

5.2.1 N izza


BS-Ebene

vertrauenswürdiger Mikrokern

vertrauenswürdige Basisdienste

nicht vertrauenswürdiges (paravirtualisiertes) BS

5.2.1 N izza

Microkernel

LegacyApplication

LegacyOperating System

Microkernel

Trusted Services

Network

Driver Loader GUISecure

Storage…


AnwendungsebeneAnfälligkeit für Fehler und Angriffe steigt mit funktionaler Komplexität→ Reduktion der Verwundbarkeit sicherheitskritischer Komponenten durch

AbspaltungIsolation

LegacyApplication

SecureComponent

5.2.1 N izza

EmailClient

EnigmailSigner

Beispiel Email-Klient■ unkritisch: Lesen/Schreiben/Senden von Mails■ kritisch: Signieren von Mails


Sicherheitsarchitektur

5.2.1 N izza

Microkernel

LegacyOperating System

EmailClient

EnigmailSigner

Trusted Services

NetworkDriver Loader GUI

Secure Storage…


Sicherheitsarchitektur

TCB

Größe der TCB: 105.000 LOCMikrokern (L4/Fiasco): 15.000 LOC

vertrauenswürdige Dienste: 35.000 LOCEnigmail Signer: 55.000 LOC

5.2.1 N izza

L4 Microkernel

EmailClient

EnigmailSigner

ParavirtualisiertesL4Linux

Trusted Services

NetworkDriver Loader GUI Secure

Storage…


ErgebnisseReduktion der Code-Größe der TCB um 2 Größenordnungen(100.000 LOC vs. 10.000.000 LOC)Wahrung der Funktionsfähigkeit von Standard-BSen und Applikationen

Kosten(moderate) PerformanzeinbußenParavirtualisierung von Standard-BSen

Dekomposition von Anwendungssystemen

5.2.1 N izza


5.2.2 Security Enhanced Linux

ZielBetriebssystem mit leistungsfähigen Sicherheitskonzepten

state-of-the-art Betriebssystem

state-of-the-art Sicherheitsparadigmen

Ideepolitikgesteuerter (Linux) BS-Kern

Technischer Ansatz

SELinux =

Linux (DAC, IBAC)

MAC, RBAC, ABAC, TAM, MLS



Sicherheitspolitiken in SELinux (vgl. auch 3.3.2)

Anwendungsdomäne: ZS-Politiken für BSeRealisierung: neue BS-Abstraktion (die erste seit 40 Jahren)nicht gänzlich unähnlich dem Prozessparadigma◆ Spezifikation

• eines Prozesses:Programm; Algorithmus in formaler Notation (C++, Java, ...)

• einer Sicherheitspolitik:Sicherheitsmodell; Regeln in formaler Notation (HRU, BLP, Skippy, ...)

◆ Laufzeitumgebung• eines Prozesses:

Prozessmanager; Ablaufumgebung für Programme• einer Sicherheitspolitik:

Security Server; Ablaufumgebung für Sicherheitsmodelle



SELinux-Architektur

Security Server (policy decision point, PDP)Laufzeitumgebung für Politik in Schutzdomäne des Kerns

Interzeptoren (policy enforcement points, PEPs)■ vollständige Interaktionskontrolle in den Objektmanagern (Teil des „Linux

Security Module Frameworks“)

SocketsDateisystemeProzess-management

AnwendungsprozessAnwendungsprozess AnwendungsprozessAnwen-dungs-ebene

Betriebs-system

Systemweites Ressourcenmanagement

Prozessor-Ressourcen

Speicher-Ressourcen

Kommunikations-Ressourcen

Betriebssystem-Schnittstelle (Application Programmer‘s Interface (API))

BS-Dienste

. . . Security ServerPolicy

Prozess-Management

Datei-systeme

Sockets



Implementierungskonzepte

Referenzmonitorprinzipien■ vollständige Kontrolle sicherheitsrelevanter Interaktionen

→ Platzierung der PEPs (LSMs): Integration in die Objektmanager■ Manipulationssicherheit der Politikimplementierung

→ Platzierung des PDPs: Integration in den BS-Kern (security server)

PolitikunterstützungSicherheitspolitiken erfordern

Authentizität der Entitäten: eindeutige Subjekt-/Objektidentifikationen→ security identifier („SID“)politikspezifische Entitätenattribute (Typ, Rolle, MLS Label)→ security contextWeg: funktionale Erweiterung der Objektmanager



Implementierungskonzepte

ProblemIn Linux,

Subjekt/Objekt Ids sind◆ Weder eineindeutig◆ Noch gleichartig

→ security identifier (SID)politikspezifische Subjekt/Objekt-Attribute (type, role, MLS label)◆ nicht Teil der Subjekt/Objekt-Metadaten

→ security context

→ Lösung: die Objektmanager helfen



Authentizität der EntitätenObjektmanager helfen: implementieren injektive Abbildung SÈO → SID

■ Generierung der SID durch Security Server

■ Mapping der SIDs auf Objekte durch Objektmanager

Objektmanager

(Objekt→SID)-Map

Security Server

SID Anfrage

ObjA SID

A

ObjB SID

B NewObj

neue SID anfordern mit(SIDS, object type)

PolitikNeue SID


Subjekt (mit SIDS)create object


Attributierung der EntitätenSicherheitspolitik implementiert injektive Abbildung SID → security context

Objektmanager

(Objekt→SID)-Map

Security Server

(SID→Context)-Map

SID Anfrage

ObjA SID

A

ObjB SID

B NewObj

neue SID anfordern mit(SIDS, object type)

Politik

Attributierungsregeln

Neue SID

■ Erzeugung des security contexts nach politikspezifischen Attributierungsregeln

■ Eintrag in SID→security context Mapping-Tabelle


Subjekt (mit SIDS)

create object


Security Contextumfasst

Standard-Entitätenattribute wie z.B.

◆ User Id

◆ Rolle

◆ Typ (user_t, tomCat_t, …)

◆ Klasse (process, file, …)

politikspezifische Entitätenattribute wie z.B.

◆ Vertraulichkeitsklasse (BLP-Label)


Security Server

SID→context map

Politik

Attributierungsregeln


Problem: die Security Contexts persistenter EntitätenPersistenzeigenschaft einer Entität ist Sicherheitspolitik unbekannt→ Persistenz der security contexts ist Aufgabe der ObjektmanagerLayout der Metadaten persistenter Speicher (z.B. I-Nodes in Dateisystemen) muss kompatibel zu Standard-Layout bleiben→ Integration der security contexts in existierende

Metadatenstrukturen persistenter Objekte (I-Nodes) problematisch



Lösungpersistente Objekte erhalten zusätzlich eine (Objektmanager-lokale) persistente SID: „PSID“

Objektmanger bilden diese auf SID ab

$ 3 versteckte Bereiche (» Dateien) auf persistenten Speichermedien (Dateisystemen)

◆ security context des Dateisystems selbst

◆ bijektive Abbildung I-Node → PSID

◆ bijektive Abbildung PSID → security context


File Object Manager

SID/PSID

Map

Inode T

able

FilesystemSecurity Context

I-Node/PSIDMap

PSID/Security

Context

Files and

Directories


Access Vector Cache (AVC)lokalisiert in Objektmanagern (user-level) bzw. im Security Server

speichert Entscheidungen des Security Servers

Objektmanager

Performanz (+5%...)

Security Server

Objekt-Zugriff

PEP:AccessCheck

(SIDs, SIDo, Perm)

Politik

AVC

Subjekt (mit SIDS)


Anfrage

Entscheidung


Zusammenfassung SELinux

Motivationveraltete und schwache Sicherheitsmechanismen in heutigen Standard-BSen

Folgeunzulängliche und unangemessene Spezifikationsmöglichkeitenzahlreiche Sicherheitslücken

ReaktionSicherheitspolitiken als neue BS-Abstraktion→ politikkontrolliertes BS: DAC & MAC, IBAC, RBAC, ABAC, TAM, MLS



Einhaltung der Referenzmonitorprinzipien1. Total Mediation Property (Platzierung der PEPs)

hmm ...(noch?) manuell





Speicher-Ressourcen


Betriebssystem-Schnittstelle

BS-Dienste


Prozess-Management

Datei-systeme

Sockets


2. TamperproofnessGrundsätzliches Problem monolithischer (SAS-) Architekturen→ TCB-Implementierung verletzbar durch gesamten BS-Code

Security Serversämtliche ObjektmanagerSpeichermanagementIPC-ImplementierungE/A-System

Es geht auch kleiner: Nizza





Speicher-Ressourcen



BS-Dienste


Prozess-Management

Datei-systeme

Sockets


3. VerifyabilityGröße und Komplexität der Politik (Referenzpolitik » 50.000 Regeln)→ Werkzeug gestützte Analyse

Generalitätsanspruch der Politik-RTEVollständigkeit der PEP-Platzierung

Isolation der Politik


SocketsDateisystemeProzess-

management



Speicher-Ressourcen



BS-Dienste


Prozess-Management

Datei-systeme

Sockets


StubStub

Sicherheits-politik

Sicherheits-politik

5.3 Sicherheitsarchitekturen verteilter Systeme

Szenario

Verteilte Middleware-Plattform (e.g. CORBA, Web Services)

Klient Objekt

AuditServerTicket

ServerAuthenti-sierungsserver

BS-Ebene

5.3 S icherheitsarchitekturen verte ilter System e

BS-Ebene BS-Ebene


...msg.subject=myCredentials;msg.method_Id=writeAssignment_Id;msg.params= myHomework;send(server, msg);...

...Kurs.writeAssignment(myHomework);...

5.3.1 CORBA

Integration von Sicherheitspolitiken

Klienten-Stubmit

Proxy-Objekt(hier ohne

PEP und PDP)

Klient

msg: myCredentials

writeAssignment_Id

myHomework

5.3.1 C O R BA


PDP: CORBA Policy Object (Skizze)

Server-

Skeleton

Server

class fernUniPolicy{ public:

bool check(msgType msg)

{ if (s=checkCredentials(msg.myCredentials))

{ o=msg.myHomework;

switch (msg.method_Id)

{ case writeAssignment_Id:

{ if (write Î m[s,o]) m[s,o] += read;

return (write Î m[s,o]);}

case readSample_Id:

{ if (read Î m[s,o])m[s,o] -= write;

return (read Î m[s,o]);}

default: return false;

}

} else return false;

}

private:

rightsetType m[subjectType,objectType];}

PEP:

„if (fernUniPolicy.check(msg)) ...“

msg: myCredentials

writeAssignment_id

myHomework

5.3.1 C O R BA


Integration von SicherheitspolitikenBeispiel: Apache Axis-2 Webserver

5.3.2 Web Services

5.3.2 W eb Services

H a n d le r

m

H a n d le r

2 Policy• • •

A x is E n g in e

H a n d le r

1

H a n d le r

2 Policy• • •

A x is E n g in e

M C req

M C resp

S O A P R e p ly

S O A P R e q u e s t

Ax

isS

erv

let

HT

TP

/JM

S

Tra

ns

po

rt U

tilit

ies

T r a n s p o r t

S e n d e r

We

b S

erv

ice

M e s s a g e

R e c e iv e r

M C req

M C respPolicy

H a n d le r

2

H a n d le r

1• • •

A x is E n g in e

T r a n s p o r t

S e n d e rPolicy

H a n d le r

2

H a n d le r

n• • •

A x is E n g in e

C l ie n t

Stu

b

S O A P R e p ly

C o o r d in a to r

O u tIn A x is O p e r a t io n

S O A P R e q u e s t

( b y H T T P , J M S . . . )

M C reqM C resp

M C resp


5.3.3 Kerberos

Authentisierungs- und Autorisierungsarchitektur für verteilte Systeme mit geschlossenen Benutzergruppen

Szenarioorganisationseigenes verteiltes IT-SystemArbeitsplatzrechner und Server 2 Kerberos-Server◆ Authentisierungsserver (AS)◆ Autorisierungsserver (TGS)

■ entwickelt im MIT-Projekt Athena, ab1986■ Konzepte sind u.a. Teil der Spezifikation der Basic CORBA Security Architecture■ Entwicklungsumgebung: 650 Workstations, 65 Server, 5000 Benutzer (1988)

lokalesRechnernetz

AS

TGS

5.3.3 Kerberos


Architekturkomponenten

Authentication Server (AS)◆ authentisiert Nutzer

• Grundlage: gemeinsamer (symmetrischer) Schlüssel von Nutzer und AS

• Ergebnis: Personalausweis („authenticator“)◆ autorisiert Nutzung des TGS

• Grundlage: gemeinsamer Schlüssel von AS und TGS• Ergebnis: Capability („ticket“) für TGS

Ticket Granting Server (TGS)◆ stellt Tickets für alle Server aus

• Grundlage: gemeinsamer Schlüssel von TGS und jeweiligem Server

• Ergebnis: Ticket(s) für Server(s)

Kerberos Datenbank◆ enthält je Benutzer Abbildung Name → Authentisierungsschlüssel◆ wird benutzt vom AS◆ ist mehrfach repliziert (Verfügbarkeit, Skalierbarkeit)

TGS

AS

5.3.3 Kerberos

Daten-bank


Überblick: Typische Nutzung

1. Authentisierung + Anforderung TGS-Ticket

2. Personalausweis, TGS-Ticket3. Anforderung weiterer Server-Tickets

4. Server-Tickets5. Dienstanforderung: Server treffen Entscheidung basierend auf

◆ Personalausweis des Klienten◆ Server-Ticket◆ (eventuell) lokale Sicherheitspolitiken

12

5

TGSAS

Server-Zoo

Daten-bank

Anna

43

5.3.3 Kerberos


Inside Kerberos Tickets

Ticketswerden vom Ticket Granting Server ausgegeben

spezifizieren Nutzungsrecht genau eines Klienten bzgl. genau eines Servers (persönliche Capabilities)haben Lebenszeit (Erschwerung kryptographischer Angriffe)

» 1 Tag; Abwägung sicher / bequem◆ kurz: unbequem, sicher: wenn Ticket gestohlen wird, gilt es nicht mehr lange◆ lang: unsicher, bequem: nicht so oft neues Ticket besorgen

sind in diesem Rahmen mehrfach benutzbar

enthalten einen Sitzungsschlüsselsind vom TGS versiegelt mit Schlüssel des betreffenden Servers (MAC)

TKlient/Server={Klient, Server, Klient.Netzadresse, Zeitstempel, Lebenszeit, SessionKeyKlient/Server}KTGS/Server

5.3.3 Kerberos


Maßnahmen gegen Ticket-MissbrauchManipulation durch Klienten zwecks Rechteerschleichung für anderen Server

→ Maßnahme: Integritätssicherung durch MAC mittels KTGS/Server

Abfangen und Verwendung durch Dritte

→ Maßnahme: Personalisierung durch ◆ Name und Netzadresse des Klienten in Verbindung mit

• begrenzter Lebenszeit• authenticator des Klienten →

5.3.3 Kerberos

TKlient/Server={Klient, Server, Klient.Netzadresse, Zeitstempel, Lebenszeit, SessionKeyKlient/Server}KTGS/Server


Inside Kerberos Authenticators

AuthenticatorsNachweis der Identität eines Klienten gegenüber Server

erzeugt mittels Sitzungsschlüssel Klient/Server→ können erzeugt und geprüft werden durch

◆ Klient (ohne Hilfe des AS, da er Sitzungsschlüssel kennt (s.u.))◆ Server

◆ TGS (vertrauenswürdig)können nur ein einziges Mal verwendet werden

→ Schutz vor Replay-Angriff durch Frische-Prüfung

AKlient={Klient, Klient.Netzadresse, Zeitstempel} SessionKeyKlient/Server

5.3.3 Kerberos


Inside Kerberos Authenticators

Anmerkung zur Implementierung der 1x-Nutzungsemantikfreies Nonce (statt Zeitstempel)

◆ präzise Implementierung der einmaligen Nutzung ist teuer(Buchführung in jedem Server, lebenslang, ähnlich TANs)

Zeitstempel als Nonce◆ gibt authenticator beschränkte (sehr kurze) Lebensdauer

◆ führt zur Notwendigkeit synchronisierter Uhren aus Sicherheitsgründen

AKlient={Klient, Klient.Netzadresse, Zeitstempel} SessionKeyKlient/Server

5.3.3 Kerberos


Kerberos Login 1/3

Gesamtablauf

TGS Ticket mitTGS Sitzungsschlüssel

Name, Passwort Auth. RequestAnna Kerberos

AS

Anna, TGS

2. Anna´s Workstation stellt Anfrage an AS

Im Einzelnen:1. Anna identifiziert sich

AnnaAnna

KerberosAS

5.3.3 Kerberos


Kerberos Login 2/3

3. Der ASerzeugt frischen Zeitstempel

erzeugt frischen Sitzungsschlüssel für Anna´s Kontakt zum TGS: SessionKeyAnna/TGS

erzeugt Anna´s Ticket für TGS und verschlüsselt dies mit KAS/TGS (dadurch durch Anna nicht modifizierbar):

TicketAnna/TGS={Anna, TGS, ..., SessionKeyAnna/TGS}KAS/TGSverschlüsselt dies alles mit KAnna/AS (dadurch kann nur Anna aus der Botschaft den SessionKey und das TGS-Ticket herauslesen)

{TGS, Zeitstempel, SessionKeyAnna/TGS, TicketAnna/TGS}KAnna/AS KerberosAS

5.3.3 Kerberos


Kerberos Login 3/3

4. Anna´s Workstationbesitzt nun {TGS, Zeitstempel, SessionKeyAnna/TGS, TicketAnna/TGS}KAnna/ASfordert Passwort von Anna an; Anna:

■ berechnet KAnna/AS aus Passwort mittels kryptografischer Hash-Funktion■ entschlüsselt damit die obige vom AS erhaltene Botschaft

Resultat: Anna´s Workstation besitzt■ Sitzungsschlüssel für TGS-Session: SessionKeyAnna/TGS

■ Ticket für TGS: TicketAnna/TGS■ die Mittel, einen authenticator zu erzeugen

Anna´s PasswortAnna

5.3.3 Kerberos


Server nutzen 1/3

Authentisierung (beidseitig)

2 Schritte1. Authentisierung des Klienten gegenüber dem Server 2. Authentisierung des Servers gegenüber dem Klienten (optional)

5.3.3 Kerberos


Server nutzen 2/3

1. Authentisierung des KlientenVoraussetzungen

Anna besitzt Session Key SessionKeyAnna/Server

Anna besitzt Serverticket TicketAnna/Server

1.a) Anna konstruiert authenticatorAAnna = {Anna, Anna´s Netzadresse, Zeitstempel}SessionKeyAnna/Server

Dies kann nur Anna, denn nur sie kennt SessionKeyAnna/Server

1.b)

1.c) Server entschlüsselt Ticket und erhält session key; damit kann er AAnna entschlüsselnund prüfen:◆ Frische◆ Übereinstimmung der Namen im Ticket und im authenticator◆ Herkunftsadresse im authenticator mit der von seiner Netzwerk-Hardware genannten

TicketAnna/Server, AAnnaAnna

5.3.3 Kerberos


Server nutzen 3/3

2. Authentisierung des Servers

kann nur jemand, der den mit Anna gemeinsamen Sitzungsschlüssel SessionKeyAnna/Server kennt

diesen besitzt nur der richtige Server, da nur dieser den Sitzungsschlüssel aus dem TicketAnna/Server={Anna,Server,...,SessionKeyAnna/Server}KTGS/Serverextrahieren kann

{Zeitstempel+1}SessionKeyAnna/ServerAnna

5.3.3 Kerberos


Ticket für einen Server besorgen

Ticketsgelten für Paar (Klient, Server)

werden (bis auf TGS-Ticket selbst) ausschließlich vom TGS ausgegeben

Ticketanforderung an TGS: (gewünschter Server, TGS-Ticket, Authenticator)

TGS:■ prüft TicketAnna/TGS und Authenticator

■ generiert Sitzungsschlüssel für Klient und Server: SessionKeyAnna/Server

■ generiert Ticket: TicketAnna/Server

■ verschlüsselt beides mit gemeinsamen Sitzungsschlüssel

Server, TicketAnna/TGS, AAnnaAnna

KerberosTGS

AnnaKerberos

TGS

5.3.3 Kerberos

{Server, SessionKeyAnna/Server, TicketAnna/Server}SessionKeyAnna/TGS


Kerberos Zusammenfassung

5.3.3 Kerberos

Leistungen?Unterschiede zu nicht verteilten Sicherheitsarchitekturen?PDPs und PEPs?Größe der TCB?RM-Prinzipien?

lokalesRechnernetz

AS

TGS


Verteilte Authentisierungs- und Autorisierungsarchitektur2 spezialisierte Security-Server◆ Authentisierung

◆ Autorisierung

Einsatz kryptografischer Mechanismen◆ Authentisierung◆ Vertraulichkeit + Integrität der Kommunikation

◆ Integrität + Authentizität der Tickets und Authenticators

Kerberos-TCB: BS +◆ Authentication Server

◆ Ticket Granting Server◆ Kerberos Datenbank

◆ sämtliche PDPs und PEPS auf den Servern◆ Zeitserver (NTP: signierte Zeitstempel!)

5.3.3 Kerberos


5.4 Zusammenfassung

(Fast) Alle heutigen TCBsgroßinhomogenverteiltpräzise Perimeterangabe schwierig

SicherheitsarchitekturproblemeEinhaltung der Referenzmonitorprinzipien

Fallbeispiele (PEPs, PDPs, SA, RM-Prinzipien)NizzaSELinuxCORBA, Web Services, Kerberos

→ gewaltige Herausforderungen!5.4 Zusam m enfassung

System sicherheit, Som m er 2018 © w k - 77 - System sicherheit

SystemsicherheitWinfried E. KühnhauserSommersemester 2018

F in ished


Was können wir jetzt?

System sicherheit

Schwachstellenund Risiken

Policy Engineering• Rolle der

Sicherheitspolitiken• Modellierung• Analyse• Spezifikation

Implementierung• TCBs• Referenzmonitore• Sicherheits-

architekturen

SicherheitspolitikenModellierung und Spezifikation

Sicherheitsarchitekturen

Sicherheitsanforderungen

Sicherheitsmechanismen


Was wir nicht gemacht haben, aber trotzdem wichtig istNetzsicherheit → Schäfer

Kryptographie → Dietzfelbinger

Managementaspekte → Stelzer (Master)

technische Aspekte: Firewalls, Virenscanner, IDSs, ...

System sicherheit


Hot Topics

„Things should be fun to use“

Policy EngineeringModel EngineeringMethoden und Werkzeuge◆ Modellanalyse, -spezifikation, -implementierung

Multipolitikensysteme◆ Politikkoordination

◆ Sicherheitsarchitekturen

Politikimplementierungkleine, präzise identifizierte TCBsReferenzmonitore, die ihren Namen verdienen

System sicherheit


Wie kann es weitergehen?

ProseminarModel Engineering, Methoden und Werkzeuge, Politikimplementierung

Bachelor-ArbeitenEntwicklung von Komponenten für die Security Policy Engineering Workbench◆ Sicherheitsmodelle für spezifische Einsatzszenarien; e.g.

◆ Analysealgorithmen; e.g. DEPSEARCHWS

◆ Spezifikationssprachen und ihre Compiler; e.g. CORPS

Master InformatikStudienschwerpunkt IT-Sicherheit

Security EngineeringSchutz von KommunikationsinfrastrukturenSicherheitsmanagement

System sicherheit

Documents

Systemsicherheit - tu-ilmenau.de · Systemsicherheit, Sommer 2018 © wk - 3 - Begriffe TCB (Trusted Computing Base) Die Menge aller Funktionen eines IT -Systems, die zur Herstellung