Secure Auditing

4. K j = hash(“EncryptionKey , W j , A j ). Das ist die Logfileeintr¨ age ab diesem Zeitpunkt noch “echt” sind jener Schl¨ ussel, der zur Verschl¨ usselung des j- undnicht durch den Einbrecher verf¨ alscht wurden. Gibt es eine verl¨ aßliche, schnelle Verbindung zwischen U ten Eintrag verwendet wird. W j wird deshalb in und T , ist das Verfahren nicht notwendig, da dann U nur die Hash-Funktion mitaufgenommen, da sonst V s¨ amtliche Logfileeintr¨ age verschl¨ usselt und signiert an T m¨ oglicherweise auch Eintr¨ age lesen k¨ onnte, die es nicht sehen darf, indem es einfach K j+1 aus schicken muß. hash(“EncryptionKey , Auch gibt es keine kryptographische Methode, die verhin- hash(“IncrementHash, A j )) berechnet. dern kann, daß der Einbrecher das gesamte Logfile oder einzelne Eintr¨ age daraus l¨ oscht. Das k¨ onnte nur mit Hilfe

5. Y j = hash(Y j−1 , E Kj (D j ), W j ). Das ist die “Hash-

von WORMs oder ¨ ahnlichen Mitteln sichergestellt wer-Kette’, die es den V s erlaubt die Authenzit¨ at be-den. Sehr wohl ist es aber mit diesem Verfahren m¨ oglich,

stimmter Logfileteile zu ¨ uberpr¨ ufen. Damit jeder

L¨ oschungen festzustellen.

uberpr¨ ufen kann, wird Y j anhand von die Echtheit ¨

E Kj (D j ) anstatt von D j errechnet. Zu Beginn wird

2.3 Notation

Y 1 mit einem beliebigen Wert initialisiert. Die Notation in dieser Arbeit wurde aus [8] ¨ ubernommen: 6. Z j = M AC Aj (Y j ). Dieser Wert erlaubt es T Y j zu uberpr¨ ufen. V ist dazu nicht in der Lage, weil es A j ¨

1. ID x steht f¨ ur einen String, der einen bestimmten Teil nicht kennt. Ansich w¨ urde die “Hash-Kette”, die von

innerhalb einer Applikation eindeutig identifiziert.

den Y j Werten erzeugt wurden aus, ausreichen um die Authenzit¨ at der Eintr¨ age zu zeigen. Allerdings 2. P KE P Kx (K) ist die Verschl¨ usselung von K unter k¨ onnte dann der letzte Eintrag des Logfiles manipu-Verwendung des Public Key von x. liert werden (wenn auch nicht mit einem “sinnvol-3. SIGN SKx (Z) ist eine digitale Signatur von Z, die len” Wert, da ja K j nach dem Eintrag sofort gel¨ oscht

vom Private Key von x erstellt wurde. werden sollte), w¨ urde es Z j nicht geben, da ja die Y ^j Werte immer nur an Hand von Y j−1 , E Kj (D j ) und 4. E K0 (X) ist die symmetrische Verschl¨ usselung von W j errechnet werden. X mit dem Schl¨ ussel K 0 .

7. L j = W j , E Kj (D j ), Y j , Z j , wobei L j der j-te Ein-5. M AC K0 (X) ist der symmetrische MAC (message trag ist. authentication code) von X mit dem Key K 0 .

8. A j+1 = hash(“IncrementHash , A j ).

6. hash(X) ist die Hash-Summe von X.

7. X, Y stellt die Verkettung von X mit Y dar.

2.4 Ablauf

2.4.1 Erzeugen eines Logfile-Eintrages

Alle Eintr¨ age im Logfile haben dasselbe Format und werden wie folgt erzeugt: k¨ onnte ein Angreifer den letzten Eintrag lesen, da K ^j noch immer gespeichert w¨ are. Ein nachtr¨ agliches Ma- 1. D j sind jene Daten, die an der Stelle j in ID ^log eingetragen werden sollen. Dabei ist es grunds¨ atzlich unwichtig wie die Daten formatiert werden, allerdings sollte f¨ ur den Leser eines Logfiles unmißverst¨ andlich klar sein, was mit welchem Eintrag gemeint ist.

2. W j zeigt um welchen Typ von Eintrag es sich handelt. Es bestimmt wer diesen Eintrag lesen darf, da nicht unbedingt jedes V alles pr¨ ufen darf.

3. A j ist der Authentifizierungsschl¨ ussel im System. Kette” unterbrochen ist.

Mit ihm steht und f¨ allt die Sicherheit des ganzen Systems. A 0 muß vor der Erzeugung des Logfiles gene-

2.4.2Erstellen des Logfiles

riert werden. Es kann sowohl von T als auch von U U kennt den Public Key von T und besitzt selbst einen von erzeugt werden und muß anschließend dem anderen T zertifizierten Public Key. Der Datenaustausch zwischen Rechner sicher ¨ ubermittelt werden.

2

U und T l¨ auft dann folgendermaßen ab: 2.4.3 Schließen des Logfiles

Das Schließen des Logfiles besteht aus drei Schritten:

1. U generiert:

1. Abspeichern der letzten Nachricht, wobei W j = K 0 , ein zuf¨ alliger Session-Key. NormalCloseMessage ist und D j die aktuelle Zeit enth¨ alt. d, aktuelle Zeit.

2. K f und A f m¨ ussen permanent gel¨ oscht werden. d+, Zeitpunkt, bis wann die Antwort sp¨ atestens erwartet wird (Timeout).

3. Das File tats¨ achlich schließen (von der Applikation ID log , ein eindeutiger Bezeichner f¨ ur das Logabh¨ angig). file.

C U , U s Zertifikat von T .

A 0 , ein zuf¨ alliger Anfangswert.

X 0 = p, d, C U , A 0 .

formiert wurde.

Anschließend wird an T gesendet:

2.4.4 ¨ Uberpr ¨ ufen des Logfiles M 0 = p, ID U , P KE ^{P K} T (K 0 ), E K0 (X 0 , SIGN ^SK U (X 0 ))

Sobald T das komplette, geschlossene Logfile erhalten

wobei p den Protokollschritt anzeigt.

weil es A 0 kennt und damit auf s¨ amtliche Logfileeintrr-2. U erzeugt dann den ersten Logfileeintrag L 0

mit W 0 = LogfileInitializationType und D 0 = d, d+, ID log , M 0 . U speichert A 0 nicht im Klartext

ab, da das sonst eine replay-Attacke erm¨ oglichen w¨ urde, bei der ein Angreifer, der in U eingebrochen ist, ein neues Logfile mit dem gleichen A 0 anlegen k¨ onnte. U speichert hash(X 0 ) ab, w¨ ahrend es auf die Antwort von T wartet.

1. V erh¨ alt von U eine Kopie der Logfileeintr¨ age L 0 ,

3. Nachdem T den ersten Logfileeintrag empfangen ..., L f , wobei f den letzten Eintrag repr¨ asentiert. U

hat, wird gepr¨ uft ob die Signatur von U korrekt und

muß nicht alle Eintr¨ age an V schicken, aber es muß

auch das Zertifikat in Ordnung ist. Anschließend er-

s¨ amtliche Eintr¨ age zwischen L 0 und einem beliebi-

zeugt T :

gem L f schicken, das den Eintrag M 1 enth¨ alt. Sonst ist keine ¨ Uberpr¨ ufung durch V m¨ oglich, weil die X 1 = p, ID log , hash(X 0 )

“Hash-Kette” unterbrochen w¨ are.

2. V pr¨ uft nun s¨ amtliche Y i Eintr¨ age der “Hash-Kette”. T generiert danach einen zuf¨ alligen Sessionkey K ¹ und schickt Folgendes ab:

3. V ¨ offnet eine sichere Verbindung zu T .

4. V erzeugt eine Liste s¨ amtlicher Eintr¨ age von 0 bis M 1 = p, ID T , P KE ^{P K} U (K 1 ), n, die es gerne lesen w¨ urde. Diese Liste enth¨ alt den E K1 (X 1 , SIGN ^SK T (X 1 )). Eintragstyp W und einen Index Q[0..n], wobei Q i = j, W j . 4. U empf¨ angt und ¨ uberpr¨ uft nun M 1 . Wenn alles in Ordnung ist schreibt U einen neuen Ein-

5. V erzeugt und sendet an T :

trag L j , wobei W j = ResponseMessageType ist und D j = M 1 . Ebenfalls errechnet U A 1 = M 2 = p, ID log , f, Y f , Z f , Q[0..n]. hash(“IncrementHash , A 0 ).

6. T ¨ uberpr¨ uft nun, ob das Logfile korrekt auf U er-Empf¨ angt U M 1 nicht bis zum Timeout d+ oder zeugt wurde und daß V berechtigt ist die gew¨ unschist M 1 ung¨ ultig, schreibt U als neuen Eintrag W j = ten Eintr¨ age zu lesen. Da T A 0 kennt, kann es AbnormalCloseType und D j = der aktuellen Zeit A f erzeugen und somit ¨ uberpr¨ ufen, daß Z f = mit einer entsprechenden Begr¨ undung. Anschlie- MAC ^A f (Y f )) ist. Sollte etwas nicht stimmen, ßend wird das Logfile geschlossen. schickt T eine entsprechende Meldung an V .

3

D i = “CrossAuthenticationReceive , 7. Sind keine Probleme aufgetreten, generiert T eine Liste R[0..n]. ⁴ Jeder Eintrag in Q erh¨ alt einen ent- ID U0 ,d 0 , Y j .

sprechenden Eintrag in R, der entweder den ent- U 1 generiertnun:

sprechenden Schl¨ ussel K j enth¨ alt oder eine entspre-

chende Fehlermeldung, warum der Zugriff auf die- M 5 = p,Y i

sen Eintrag verweigert wurde. Theoretisch k¨ onnte V

und schickt es an U 0 . ⁶ falsche W j Werte mitschicken und so versuchen, auf

D j Werte Zugriff zu erhalten, die es eigentlich nicht Ist U 1 mit dem Zeitstempel nicht einverstanden,

lesen darf. T w¨ urde dann sogar einen K j Wert erschreibt es ins Logfile an der Stelle i:

rechnen, allerdings w¨ are dieser dann falsch und V

W i = “Cross Authentication Receive Error”, k¨ onnte D j nicht entschl¨ usseln.

D i = “CrossAuthenticationReceiveError ,

8. T geniert und schickt an V: M 3 = p, R[0..n]. wobei d 1 der Zeitstempel von U 1 ist. Interessant in diesem Zusammenhang ist, daß der Timeout hier von

9. V kann nun die entsprechenden Eintr¨ age ent- U 1 entschiedenwird und nicht wie unter 2.4.2 von

schl¨ usseln und lesen, die mit M 3 geschickt wurden.

U 0 bestimmt wird. Der Grund daf¨ ur ist mir eigent-

5

lich nicht klar. In [8] steht lediglich etwas sp¨ ater, daß U 0 sehr wohl auf einen Timeout wartet. Wo der Zeit-10. V l¨ oscht nun den Schl¨ ussel, der in Schritt 3 erzeugt punkt aber gespeichert wird, wird nicht erw¨ ahnt. wurde um zu verhindern, daß jemand, der in V einbricht, das Logfile sp¨ ater lesen kann. Anschließend generiert U 1 Folgendes und schickt es an U 0 : 2.5 Erweiterungen M 6 = p, Y i , ErrorCode. 2.5.1 Hash-Lattice Das Protokoll wird danach abgebrochen. Um die Sicherheit des Systems noch zu verbessern, 5. Empf¨ angt U 0 M 6 rechtzeitig und ohne Fehlermelk¨ onnen mehrere T s untereinander die Logfiles gegenseidung, dann schreibt es an der Position j + 1: tig authentifizieren. W j+1 = “Cross Authentication Reply”, D j+1 = “CrossAuthenticationReply , ID U1 , 1. U 0 und U 1 tauschen ihre Identit¨ aten untereinander aus und stellen eine sichere Verbindung her. Y i .

2. U 0 generiert anschließend folgenden Logfileeintrag Falls ein Fehler aufgetreten ist, schreibt U 0 an der an der Stelle j: Stelle j + 1:

W j+1 = “Cross Authentication Reply Er- W j =“Cross Authentication Send”,

D j = “CrossAuthenticationSend , ID U1 , d 0 , ID U1 , ErrorCode. wobei d 0 ein Zeitstempel von U 0 ist. Da das Protokoll vorschreibt, daß die Erfolgs- oder

3. Danach erzeugt U 0 Folgendes und schickt es an U 1 : Fehlermeldung bereits in j + 1 erfolgen muß und nicht m¨ oglicherweise sp¨ ater, muß der Timeout mei- M 4 = p,Y j , d 0 ,

ner Ansicht nach extrem kurz gesetzt sein, da anson-wobei Y j bekanntlich der aktuelle Wert der “Hashsten U 0 f¨ ur l¨ angere Zeit kein Auditing durchf¨ uhren

Kette” von U 0 ist. kann.

Ein weiteres Problem ist, daß U 0 und U 1 offenbar 4. U 1 erh¨ alt daraufhin M 4 und ¨ uberpr¨ uft, ob der Zeitunterschiedliche Timeouts haben k¨ onnen. Es ist also stempel korrekt ist. Ist dem so, schreibt U 1 in sein

m¨ oglich, daß U 0 zuerst eigenst¨ andig eine Fehlermel-Logfile an der Stelle i:

dung schreibt, da es von U 1 keine Antwort bekom-

men hat, etwas sp¨ ater aber von U 1 eine Erfolgsmel- W i = “Cross AuthenticationReceive”,

dung geschickt bekommt.

⁴ In [8] steht von R[1..n], was aber nicht richtig sein d¨ urfte, da unter

Punkt 8 wieder von R[0..n] gesprochen wird.

⁵ In [8] ist hier von M 4 die Rede, allerdings kommt M 4 sonst in diesem Zusammenhang nie vor. schinen stattfindet und nicht zwischen den Logfiles.

4