Kryptographie und Zugriffskontrolle - Zugriffskontrolle

Zugriffskontrolle

Mit Hilfe von Zugriffskontrolle (engl. Access Control) kann der Zugriff von Usern (Subject) auf Ressourcen (Object) kontrolliert und somit gesteuert und geschützt werden. Access Control lässt sich in zwei Kategorien unterteilen, nämlich einerseits den physikalischen Schutz und andererseits den logischen Schutz. Mit physikalischen Schutz ist vor allem der Zutritt zu Ressourcen oder Systemen gemeint, zum Beispiel der Zutritt zu einem Rechenzentrum. Der logische Schutz bezieht sich auf Betriebssystem- beziehungsweise Applikations-Ebene. Die folgenden Kapitel beziehen sich auf den logischen Schutz von Ressourcen.

Autorisierung und Modelle

Access Control kann über verschiedene Modelle abgebildet werden. Das Modell bestimmt wann und wie ein Subject auf ein Objekt zugreifen kann. Die klassischen Zugriffsmodelle werden in den Kapiteln 1.1.1, 1.1.2 und 1.1.3 beschrieben.

Discretionary Access Control

Das Discretionary Access Control (DAC) Modell ist auf den Benutzer fokussiert . Der Benutzer ist der Eigentümer seiner Ressourcen und verfügt damit über vollen Zugriff auf diese. Somit kann er auch den Zugriff auf seine Ressourcen für andere erlauben. Es ergibt sich damit ein dezentrales System bezüglich der Rechtevergabe. Dieses Prinzip ist zum Beispiel im Unix Filesystem zu finden. Darstellbar ist DAC am besten durch eine Access Control Matrix, wie in Tabelle 1.1 ersichtlich.

Beispiel einer Access Control Matrix

	file 1	file 2	file 3
Alice	r	rwx	rw
Bob	rwx		r
Eve	rw	r	r

DAC ist auf der einen Seite sehr flexibel, hat aber zwei große Nachteile. Zum einen ist ein zugewiesener Lesezugriff transitiv. Das heißt, hat ein Subjekt Lesezugriff auf eine Datei hindert ihn nichts daran den Inhalt der Datei in eine neue Datei, welche unter seiner eigenen Kontrolle steht, zu kopieren und anschließend Rechte an andere subjekte zu verteilen. Zweitens, ist es durch die dezentrale Rechtevergabe kaum möglich eine systemweite Richtlinie zu definieren.

Mandatory Access Control

Mandatory Access Control (MAC) stammt ursprünglich aus dem militärischen Bereich und ist wesentlich restriktiver und strukturierter . MAC kann somit als Gegenteil von DAC betrachtet werden. Bei MAC werden Rechte von einer zentralen Verwaltungsinstanz vergeben. Eine Veränderung der Rechte durch ein Subjekt ist damit ausgeschlossen. Abgebildet wird dieses Modell meist durch Zuweisung von Klassifizierungen beziehungsweise Schutzstufen. Zum Beispiel darf ein Benutzer aus der Schutzstufe secret keine Dokumente aus der Schutzstufe top secret lesen. Es gibt zwei Ausprägungen von MAC Konzepten :

• Multi-Level Sicherheitssysteme: Wie oben beschrieben, werden Ressourcen Schutzstufen zugeteilt. Die bekanntesten Modelle sind Bell-LaPadula und Biba.
• multilaterale Sicherheitssysteme: Zusätzlich zu den Schutzstufen werden zudem noch Label vergeben. Diese ermöglichen neben der vertikalen auch eine horizontale Betrachtung. Die bekanntesten Vertreter sind das Lattrice Modell und das Chinese Wall Modell.

Role-based Access Control

Wie der Name schon sagt, werden bei Role-based Access Control (RBAC) den Subjekten unterschiedliche Rollen zugeteilt, welche eine bestimmte Funktion erfüllt . Durch diese Zuteilung erhält das Subjekt auch die entsprechenden Rechte auf die dafür notwendigen Objekte. Die Zugriffsberechtigungen erfolgen wie bei DAC mittels einer Access Control Matrix. Die Zuweisung der Rollen erfolgt allerdings durch eine zentrale Verwaltungsstelle, wie bei MAC. RBAC wird in verschiedenen Systemen, wie Microsoft Active Directory, SELinux, Solaris und diversen Datenbanksystemen umgesetzt.

Authentisierung auf Unix Systemen

Bei Unix beziehungsweise Linux Systemen werden die Credentials der Benutzer in der Datei /etc/passwd oder in die Datei /etc/shadow geschrieben . Diese Dateien sind in der Regel nur für Benutzer mit root Rechten beschreibbar beziehungsweise lesbar. In der Datei /etc/passwd erfolgt pro Zeile ein User Eintrag. Der User Eintrag umfasst mehrere Parameter welche durch Doppelpunkte getrennt sind.

myuser:x:1001:1001:User,,,:/home/myuser:/bin/bash

Folgende Attribute sind in der passwd Datei enthalten:

• username: Der Loginname (myuser)
• passwd: An dieser Stelle befindet sich das gehashte Passwort. Werden shadow Passwörter verwendet ist hier nur ein x angegeben. Das eigentliche Passwort ist dann in /etc/shadow zu finden.
• UID: Die nummerische User ID (1001)
• GID: Die nummerische Group ID des Users (1001)
• full_name: Der vollständige Name des Users (User)
• directory: Der Pfad zum Home Directory des Users (/home/myuser)
• shell: Die eingestellte User Login Shell (/bin/bash)

Werden shadow Passwörter verwendet, bringt dies eine Sicherheitsvorteile. So ist die Datei für herkömmliche Benutzer nicht lesbar.

myuser:$6$0Hm6YF2C$6VxZAipdU8Qn8YZR5NqX1uH.P9J7DDz2gEXIvF0y/PpQy6lemTvWgBzYWFrFDcAQhajIYpjNJ8Q8e5trWq8Sd/:17291:0:99999:7:::

Die shadow Datei ist wiederum zeilenweise zu lesen und deren Attribute sind ebenfalls durch Doppelpunkte getrennt. Die angegebenen Attribute sind laut manual page von shadow folgende:

• Login Name: Ein gültiger Benutzer am System
• encrypted password: Hier findet sich das "gesalzene" und gehashte Passwort des Users, mehr dazu später.
• Datum des letzten Password Wechsels
• minimum password age
• maximum password age
• password warning period: Die Anzahl der Tage befor ein Passwort ausläuft und der Benutzer gewarnt werden soll.
• password inactivity period: Anzahl der Tage in denen ein bereits abgelaufenes Passwort noch akzeptiert wird.
• account expiration date
• reserved for future use

Das Encrypted Password Feld in der /etc/shadow Datei wird dabei im Format $id$salt$hash angegeben. $id bezieht sich dabei auf den Algorithmus der zum Hashen des Passwortes verwendet wird. So steht $1 für MD5, $2 für den Blowfish Algorithmus, $5 für SHA-256 und $5 für SHA-512 . Der Wert $salt generiert sich aus der aktuellen Uhrzeit und der Prozessidentifikation. Der Salt beeinflusst die Verschlüsselung des unter $hash abgelegten Passwortes des Benutzers. Ein und dasselbe gehashte Passwort kann somit aufgrund des Salts unterschiedliche Repräsentationen annehmen. Somit können Angriffe nochmals erschwert werden.

Multi-Factor Authentication

Unter Multi-Factor Authentication wird die Authentisierung mit mehreren, dem Benutzer zugeordneten, Maßnahmen verstanden . Die hauptsächlichen Gründe für eine Verwendung von zwei oder mehreren Faktoren sind vor allem die Nachteile bei der alleinigen Verwendung von Passwörtern. So können Passwörter leicht vergessen oder weitergegeben und kompromittiert werden. Passwörter können erraten oder auch geknackt werden. In manchen Bereichen ist der Zugriff auf Ressourcen auch besonders schützenswert oder die Verwendung von MFA wird von einer Richtlinie vorgegeben, wie zum Beispiel PCI-DSS . Die Maßnahmen oder Möglichkeiten eine Authentisierung mit mehreren Faktoren sind vielfältig, lassen sich aber in drei Kategorien einteilen:

• spezifisches Wissen: Passwort, PIN, Antworten auf bestimmte Fragen (Questions and Answers oder Sicherheitsabfrage), Zero-Knowledge Beweise, etc. Kurz gesagt: etwas, was man weiß.
• persönlicher Besitz: Hardware-Token, Smartcard, physikalischer Schlüssel, Zertifikate, SmartPhone, RFID basierte Tokens, TAN-Liste, USB Stick oder andere USB Geräte, etc. Kurz gesagt: etwas, was man hat.
• biometrische Merkmale: Fingerabdruck, Gesichtserkennung, Retina, Handschrifterkennung, etc. Kurz gesagt: etwas, das man ist.

Eine der bekanntesten Einsatzbereiche von Multi-Faktor Authentication (MFA) ist zum Beispiel der Überweisungsvorgang beim Online-Banking. Hier wird neben den Zugangsdaten mit Username und Passwort auch entweder ein One-Time-Password via SMS oder ein TAN aus einer TAN-Liste abgefragt. Dies stellt eine Authentisierung mit zwei Faktoren dar und wird auch 2 Factor Authentication (2FA) genannt. 2FA ist somit eine Form der Multi-Factor Authentication.

Bei der technischen Umsetzung werden Multi-Factor Mechanismen zum Beispiel über das RADIUS Protokoll (mittels Access-Challenge, siehe 1.5.2) oder über Kerberos Authentifizierungsmechanismen gelöst, sieh Kapitel 1.5.1.

One-Time Passwords

One-Time Passwords (OTP) sind Passwörter welche für den einmaligen Gebrauch (zum Beispiel einer Session oder Transaktion) von einem Generator generiert werden . Dies kann zum Beispiel ein Hardware Token sein. Der Validator ist die Serverseitige Software, welche den generierten Code auf seine Gültigkeit überprüft. Nach dem einmaligen Gebrauch ist der OTP nicht mehr gültig. OTPs haben den großen Vorteil, dass Replay Attacken nicht möglich sind. Aufgrund dessen werden OTPs gerne als Faktor für eine Multi-Faktor Authentifizierung, siehe Kapitel 1.3, verwendet. Für die Generierung von OTPs werden im allgemeinen drei mögliche Zugänge verwendet:

• basierend auf Zeit: Der OTP wird unter Einbeziehung es aktuellen Timestamps berechnet. Dies setzt eine Zeit Synchronisation zwischen Server und Client voraus.
• basierend auf dem letzten OTP: Der Algorithmus berechnet den nächsten OTP aufgrund des vorherigen. Dies heißt natürlich, dass alle OTPs in einer Kette berechenbar sind.
• basierend auf einer Challenge: Der Algorithmus berechnet aufgrund einer Challenge (zum Beispiel einer Zufallszahl) den nächsten OTP.

Lange Zeit waren OTP-Algorithmen nicht standardisiert. Einige Unternehmen wie RSA Security und VASCO versuchten ihre eigenen Implementierungen als Standard zu etablieren und voranzutreiben. Im Jahre 2004 wurde dann die Initiative for Open AuTHentication (OATH) gegründet . Diese stellt einen Zusammenschluss von Unternehmen, wie ActiveIdentity, Gemalto und Symantec dar. Ziel der Initiative ist die Entwicklung von einheitlichen Standards für die Authentisierung, darunter auch Standards für die Generierung von One-Time Passwords. So wurde eine Referenz Architektur geschaffen, welche ein Framework für Open Authentication darstellt . Außerdem wurden einige Standards für die Generierung von OTPs entwickelt, welche als RFC verfügbar sind:

• RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm : Der RFC spezifiziert einen OTP Algorithmus welcher einen HMAC-SHA-1 verwendet, siehe dazu Kapitel [MAC]. Generator und Validator einigen sich zuerst auf ein gemeinsames secret ${\textstyle K}$, sowie einen Counter ${\textstyle C}$. Mit diesen Informationen können auf beiden Seiten gleiche OTPs generiert werden. ${\textstyle C}$ wird nach jeder OTP Generierung inkrementiert:
  $$HOTP(K,C)=Truncate(HMACSHA1(K,C))$$
  Die Funktion ${\textstyle Truncate}$ konvertiert dabei die Ausgabe des HMAC-SHA-1 von 160-Bit in den endgültigen zumindest 6-stelligen HOTP.
• RFC 6238: TOTP: Time-Based One-Time Password Algorithm : TOTP basiert auf den Grundprinzipien von HOTP. Der wesentliche Unterschied ist die Verwendung des Counters ${\textstyle C}$. Bei TOTP wird anstelle von ${\textstyle C}$, der Integer ${\textstyle T}$ verwendet. ${\textstyle T}$ gibt die Anzahl der Zeitschritte zwischen der Ausgangszeit ${\textstyle T0}$ und der aktuellen UnixTime an. Die Funktion ist ansonsten analog wie bei HOTP, daher:
  $$TOTP=HOTP(K,T)$$
• RFC 6287: OCRA: OATH Challenge-Response Algorithm : Auch OCRA übernimmt die Funktionsweise von HOTP mit den folgenden Anpassungen. OCRA besteht aus einer kryptographische Funktion, dem gemeinsamen secret ${\textstyle K}$ und einer Menge an Eingabedaten ${\textstyle DataInput}$. Eine OCRA Response berechnet sich durch
  $$OCRA=CryptoFunction(K,DataInput)$$
  Als Standard für die ${\textstyle CryptoFunction}$ verwendet ORCA den SHA-1 Algorithmus. Mittels der Eingabedaten kann das Verhalten von OCRA angepasst werden. So unterstützt OCRA ein einseitiges und eine beidseitiges Challenge-Response Verfahren so wie die Möglichkeit einer Signatur von Daten.

AAA Systeme und Protokolle

AAA oder Triple A steht für Authentication, Autorisation und Accounting, also Authentisierung, Autorisierung und Abrechnung. AAA ist ein Framework welches diese 3 Verfahren beschreibt . Dabei werden keine spezifischen Methoden zur Verschlüsselung oder Authentication beschrieben, sondern ein generischer Ansatz zur Verfügung gestellt.

Kerberos

Kerberos ist ein Authentifizierungssystem welches vom MIT entwickelt wurde . Es ist ein Client - Server Modell welches symmetrische Verfahren einsetzt. Kerberos hat 2 primäre Aufgaben. Erstens die Subjekte, welche im Kerberos Kontext als Principals bezeichnet werden, zu authentifizieren. Zweitens werden über Kerberos Sitzungsschlüssel ausgetauscht. Zudem ist es möglich mit Kerberos Single-Sign On zu implementieren. Kerberos hat allerdings keine Funktion zur Autorisierung (daher Vergabe von Rechten) ihrer Principals. Kerberos schreibt auch nicht vor, wie die Authentifizierung zu erfolgen hat, daher kann ein Passwort als auch beispielsweise ein Token oder eine SmartCard verwendet werden. Kerberos verwendet zur Authentisierung sogenannte Tickets . Garman schreibt zur Aufgabe von Tickets:

"Tickets serve two purposes: to confirm identity of the end participants and to establish a short-lived encryption key that both parties can share for secure communication (called the session key)."

Tickets sind verschlüsselte Datenkonstrukte welche folgende Felder beinhalten:

• Der Principal Name des User, welcher die Anfrage stellt.
• Der Service Principal Name der Applikation, an welchem sich dieser authentisieren möchte.
• Gültigkeitszeitraum des Tickets
• Eine Liste von IP Adressen, von welchen das Ticket benutzt werden kann.
• ein geteilter aber geheimer Schlüssel für die Kommunikation zwischen User und Service (Session Key)

Bei Kerberos ist es essentiell wichtig, dass eine Zeitsynchronisation zwischen Client und Server erfolgt. Tickets werden mit einem Zeitstempel versehen und es werden nur geringe Abweichungen akzeptiert.

Kerberos besteht im wesentlichen aus 3 logischen Komponenten, welche als Key Distribution Center (KDC) zusammengefasst werden:

• Einer Datenbank mit allen Principals und deren verschlüsselten Keys
• Einem Authentication Server (AS): Der AS stellt sogenannte Ticket Granting Tickets (TGT) an Clients aus.
• Dem Ticket Granting Server (TGS): Der TGS überprüft TGTs und stellt Service Tickets für einzelne Applikationen bereit.

Ablauf einer Kerberos Authentifizierung

Funktionsweise:

1. Bei der Anmeldung des Users am Client stellt dieser einen Authentication Service Request für ein Ticket Granting Ticket (TGT) beim Authentication Server (AS).
2. Das Key Distribution Center überprüft die Credentials des Clients in seiner Datenbank. Der Authentication Server stellt dem Client ein Ticket Granting Ticket (TGT) aus und schickt dieses zusammen mit dem Logon Session Key, verschlüsselt mit dem Key des Clients, an den Client zurück.
3. Der Client entschlüsselt das TGT und den Logon Session Key und speichert diese in seinem Cache. Will der Client nun auf eine Applikation zugreifen, stellt er mittels dem TGT eine Anfrage für ein Service Ticket für das entsprechende Service an den Ticket Granting Server (TGS).
4. Der TGS validiert das TGS und retourniert ein verschlüsseltes Service Ticket zusammen mit dem Service Session Key.
5. Der Client kann sich nun mit dem ausgestellten Service Ticket und dem Session Key beim gewünschten Service anmelden und sendet diese Informationen an den Applikationsserver.
6. Das Applikationsserver sendet dem Client einen verschlüsselten Zeitstempel retour. Der Client kann diesen entschlüsseln und auf diese Weise feststellen, dass es sich um ein vertrauenswürdiges Service handelt.

Das RADIUS Protokoll

Die Abkürzung RADIUS steht für Remote Authentication Dial In User Service . Es handelt sich dabei um ein Client-Server Protokoll welches auf dem UDP Protokoll basiert. Es wird eingesetzt bei Service Providern für den Einwahldienst, aber auch im Unternehmensbereich zur Absicherung von Remote Access oder WLAN Lösungen. Ein Benutzer sendet über seinen Client Rechner seine Credentials an den sogenannten Network Access Server (NAS). Dieser agiert als RADIUS Client und erzeugt einen Access-Request, (welcher die Credentials des Users enthält) an den RADIUS Server. Das RADIUS Protokoll basiert auf einem Shared Secret ${\textstyle S}$, welches zuvor zwischen dem RADIUS Client (NAS) und dem RADIUS Server vereinbart wurde. Nach Überprüfung der Anfrage erfolgt eine Rückmeldung an den RADIUS Clients entweder in Form einer Access-Denied oder Access-Accept (oder einer Access-Challenge) Nachricht. Das RADIUS Protokoll unterstützt mehrere Protokolle zur Authentifierung wie CHAP oder PAP .

Radius Authentifizierung

Funktionsweise:

1. Eine Client Rechner sendet eine Authentifizierung an den Network Access Server.
2. Der NAS agiert als RADIUS Client und erzeugt einen Access Request an den RADIUS Server. Erhält der RADIUS Client in einem definierten Zeitabstand keine Antwort wiederholt dieser seine Anfrage. Der Access Request enthält folgende Attribute:
   • Die IP Adresse des RADIUS Clients.
   • eine 8-Bit lange ID, über welchen der Request identifiziert wird.
   • der sogenannte Request Authenticator (RA), welcher eine zufällig gewählte 128-Bit Zahl darstellt.
   • Der Benutzername und Password. Das Passwort wird unter Berechnung des Request Authenticators und des Shared Secret als Hashwert übertragen. Dabei werden schrittweise die Werte ${\textstyle c_{1}=p_{1}\oplus MD5(S|RA)}$ bis ${\textstyle c_{n}=p_{n}\oplus MD5(S|c_{n}-1)}$ berechnet. ${\textstyle p_{i}}$ stellt dabei das ursprüngliche Passwort der Stelle ${\textstyle i}$ dar. Ist das ursprüngliche Passwort keine 128-Bit lang wird es mittels Padding aufgefüllt.
   • zusätzlich sind noch weitere Attribute laut RFC 2865 möglich.
3. Der RADIUS Server empfängt den Access Request und berechnet aufgrund des shared secrets und des mitgelieferten Request Authenticators das ursprüngliche Passwort. Das Passwort kann dann zum Beispiel in einem externen User Directory auf Richtigkeit überprüft werden.
4. Anschließend wird eine Antwort vom RADIUS Server generiert. Hier bestehen drei Möglichkeiten:
   • Access-Accept: Das Passwort ist korrekt und die Authentifizierung war erfolgreich. In diesem Fall wird eine Access Accept Meldung erzeugt, welche die ID des Requests und einen Response Authenticator enthält. Der Response Authenticator ist ein MAC des Access Requests. Mittels der MAC Berechnung wird die Authentiziät des Radius Servers bestätigt, da dieser in Kenntnis des Shared Secrets ${\textstyle s}$ ist.
   • Access-Reject: Das Passwort ist nicht korrekt und ein Reject der Anfrage wird erteilt. Die Access Reject Meldung setzt sich wiederrum aus der ID und des Response Authenticators zusammen.
   • Access-Challenge: Der RADIUS Server kann dem Client eine Challenge zusenden. Dies stellt eine erneute Aufforderung zur Generierung einer Access-Request Nachricht dar. Die Challenge kann einen frei definierbaren Text String enthalten, der vom RADIUS Client dem Benutzer anzuzeigen ist. Dies wird zum Beispiel bei Multi-Faktor beziehungsweise Strong Authentication verwendet (siehe Kapitel 1.3) um einen zweiten Faktor an den RADIUS Server zu senden.
5. Der RADIUS Client erhält die jeweilige Antwort und überprüft ob die ID zu seinem gesendeten Access-Request passt. Wenn ja, wird auch der Response Authenticator auf seine Richtigkeit überprüft. Anschließend wird das Ergebnis des Connection Requests dem ursprünglichen Client mitgeteilt.

Ein RADIUS Server kann auch als sogenannter Proxy fungieren und die erhaltenen Access-Request an einen oder mehrere RADIUS Server weiterleiten. Die Zuteilung des Access-Requests zu einem zuständigen RADIUS Server kann, zum Beispiel, durch die NAS IP-Adresse, den Benutzernamen oder durch Verwendung der zusätzlich definierbaren RADIUS Attribute abgebildet werden.

Zusätzlich bietet RADIUS auch ein optionales Accounting an, welches in RFC 2866 beschrieben ist. Wird RADIUS Accounting verwendet, wird nach einer erfolgreichen Access-Accept, vom NAS ein zusätzlicher Accounting-Request vom Typ Start zum RADIUS Server gesendet. In regelmäßigen Intervallen erfolgen dann Accounting Updates vom Client zum Server. Diese Updates enthalten die Session Dauer sowie die Informationen zum Datenverbrauch. Nach Beendigung der Verbindung wird ein Accounting Request vom Typ Stop, sowie Verbindungseigenschaften, wie zum Beispiel, die Gesamtdauer, Datenverbrauch oder Anzahl der übertragenen Pakete, an den RADIUS Server gesendet.