Lösung Übung 10?

:)
Erstie
Erstie
Beiträge: 15
Registriert: 21. Apr 2006 12:31

Lösung Übung 10?

Beitrag von :) »

Hat jemandem die Lösung von der 10. Übung? Wenn ja bitte mailen, danke :?:

Benutzeravatar
junin
Mausschubser
Mausschubser
Beiträge: 51
Registriert: 2. Mai 2006 22:44
Kontaktdaten:

Beitrag von junin »

Also, wenn jemand eine Lösung hat, dann sollte er oder sie diese Lösung hier veröffentlichen und nicht dir mailen. Dazu ist das Forum schließlich da!

Equinox
Windoof-User
Windoof-User
Beiträge: 26
Registriert: 27. Nov 2004 14:58

Beitrag von Equinox »

Ich habe die 10. Übung vorhin mal gelöst - besonders schwer fand ich die eigentlich nicht, aber ich habe jetzt nicht wirklich Lust, 2 Seiten abzutippen...aber wenn ihr irgendwelche konkreten Fragen habt, dann stellt sie ruhig. ;)

Benutzeravatar
plane
Computerversteher
Computerversteher
Beiträge: 337
Registriert: 21. Okt 2005 00:18

Beitrag von plane »

Also zur Aufgabe 2:

1. Ich würde mal sagen ab dem Client Key Exchange bis nach den beiden Finished Nachrichten, da hier der Client sich gegenüber dem Server authentifiziert.

2. Wird generiert aus dem privaten Key vom Server und den übertragenen Zufallszahlen

3. In welchem Teil jetzt? Am Anfag der Server gegenüber dem Client mit dem Zertifikat und dann der Client dem Server gegenüber

4. Diffie Hellman ist nicht Man-in-the-Middle sicher, man müsste zusätzlich noch elektronische Unterschrift, bzw. MAC's in diesem Fall benutzen

5. Nach dem Server Hello Done, falls der Client das Serverzertifikat akzeptiert hat

6. nach dem 2ten Finished, da beiden jetzt das gleiche Master Secret für die Session besitzen

7. ? Zertifikat?, weiss nicht genau was ich da antworten soll

So long, Flo

Benutzeravatar
junin
Mausschubser
Mausschubser
Beiträge: 51
Registriert: 2. Mai 2006 22:44
Kontaktdaten:

Beitrag von junin »

also meine Meinung dazu:

zu 3. Der Server gegenüber dem Client
zu 6. Gar nicht, Client hat sich nicht authentifiziert.
zu 7. auf das Vertrauen in das Zertifikat und den Austeller des Zertifikats.

Benutzeravatar
^Lara^
Mausschubser
Mausschubser
Beiträge: 68
Registriert: 17. Jan 2005 12:57

Beitrag von ^Lara^ »

kleine Frage dazu:

Was ist überhaupt ein Master Secret?

(hab auf den folien nichts genaues gefunden :( )

und noch eine frage zum Protokoll:

Welche Sicherheitsziele werden mit den finished-Nachrichten erreicht? (Frage auf den Folien)
Also wozu braucht man die finished-Nachrichten?

Vielen Dank!

Equinox
Windoof-User
Windoof-User
Beiträge: 26
Registriert: 27. Nov 2004 14:58

Beitrag von Equinox »

1. Auf Folie 15 in Kapitel 7 steht eigentlich alles zum Master-Secret. - Durch Anwendung von MD5 und SHA^-1 werden aus dem Master-Secret die für die Verbindung benötigten Schlüssel abgeleitet...

2. Erst mit den Finished-Nachrichten können Client und Server sicher sein, dass beim SSL-Handshake kein Man-in-the-Middle dazwischen war. Die Finished Nachricht des Servers ist ein MAC über alle Nachrichten, die der Server vom Client erhalten hat. Der Client berechnet nun seinerseits den MAC über alle Nachrichten, die er dem Server gesendet hat. Wenn beide MACs identisch sind, kann der Client sicher sein, dass kein Man-in-the-Middle in die Kommunikation eingegriffen hat. Auf dem Server läuft das Verfahren analog mit der Finished Nachricht des Clients ab.
f_noell hat geschrieben:Also zur Aufgabe 2:

1. Ich würde mal sagen ab dem Client Key Exchange bis nach den beiden Finished Nachrichten, da hier der Client sich gegenüber dem Server authentifiziert.

2. Wird generiert aus dem privaten Key vom Server und den übertragenen Zufallszahlen

3. In welchem Teil jetzt? Am Anfag der Server gegenüber dem Client mit dem Zertifikat und dann der Client dem Server gegenüber

4. Diffie Hellman ist nicht Man-in-the-Middle sicher, man müsste zusätzlich noch elektronische Unterschrift, bzw. MAC's in diesem Fall benutzen

5. Nach dem Server Hello Done, falls der Client das Serverzertifikat akzeptiert hat

6. nach dem 2ten Finished, da beiden jetzt das gleiche Master Secret für die Session besitzen

7. ? Zertifikat?, weiss nicht genau was ich da antworten soll

So long, Flo
zu 1: Die Challenge ist der Client Key Exchange - PRE ist mit dem Public-Server-Key verschlüsselt. Der Server kommt also nur an PRE heran, wenn er den Private-Server-key hat. Die Response sind dementsprechend einfach die verschlüsselten Nachrichten, die der Client vom Server erhält (PRE wird ja bei der Berechnung der Schlüssel verwendet).
Der Client authentifiziert sich in dem konkreten SSL-Handshake Protokoll gar nicht.

zu 2: Der Master-Key wird aus PRE und den beiden Zufallszahlen berechnet, siehe Folie 15, Kapitel 7.

zu 3: Der Server authentifiziert sich gegenüber dem Client (Zertifikat und Challenge (siehe 1.)). Der Client authentifiziert sich nicht.

zu 5: Ab der Finished-Nachricht des Servers (siehe oben)

zu 6: Ab der Finished-Nachricht des Clients (analog zu 5)

zu 7: Auf das Zertifikat des Servers, d.h. der User des Clients muss das Zertifikat vor dessen Annahme genau prüfen.

Benutzeravatar
plane
Computerversteher
Computerversteher
Beiträge: 337
Registriert: 21. Okt 2005 00:18

Beitrag von plane »

danke, jetzt ist mir auch alles klar, dass sich der client gegenüber dem server nicht authenfiziert sieht man ja, danke gruß flo :o

Richie
Mausschubser
Mausschubser
Beiträge: 92
Registriert: 25. Okt 2005 13:03
Wohnort: Darmstadt
Kontaktdaten:

Beitrag von Richie »

/me stimmt Equinox vollkommen zu

Bleibt nur noch die Aufgabe 1 zu klären, ich fasse mal zusammen, was ich meine:
1. a)
ACL(bla) = {(Alice, {r}), (Bob, {r,w})}
ACL(blub) = {(Alice, {r,w,x})}
ACL(fasel) = {(Bob, {r,x})}

CAP(Alice) = {(bla, {r}), (blub, {r,w,x})}
CAP(Bob) = {(bla, {r,w}), (fasel, {r,x})}

b)
Die Zugriffsberechtigungen sind als ACL gespeichert. Will nun ein Client auf eine Datei zugreifen, so wird zunächst geprüft, ob dieser die entsprechenden Rechte hat. Wenn ja, bekommt der Client (bzw. der Prozess des Clients) eine Cap auf die Datei, dann dann zum Zugreifen ausreicht (das Betriebssystem traut sich in diesem Falle selber, was eine vernünftige Annahme ist).

2. Da bin ich mir überhaupt nicht sicher, ich würde einfach mal darauf tippen, dass die ACL entweder verschlüsselt wird, oder nur vom BS vor Zugriffen geschützt wird (das hieße anderes BS --> ACLs ändern kein Problem)

3. Da Capabilities nur zur Laufzeit des BS bestehen, schützt hier einfach das Betriebssystem vor Manipulation (z.B.: nur Systemprozesse dürfen Caps ändern)

4.
fd = open("/tmp/test", O_RDONLY); --> Berechtigungen werden mittels ACL überprüft, im Erfolgsfall wird eine Cap erzeugt, die an fd gebunden ist
read(fd, buffer, 255); --> Prozess weist seine Cap vor, um auf fd zuzugreifen
close (fd); --> Cap für fd und Prozess wird wieder gelöscht
There are only 10 types of people in the world:
Those who understand binary and those who don't

Benutzeravatar
dEeP-fRiEd
Kernelcompilierer
Kernelcompilierer
Beiträge: 432
Registriert: 19. Okt 2005 00:58
Wohnort: Darmstadt
Kontaktdaten:

Beitrag von dEeP-fRiEd »

Equinox hat geschrieben: zu 1: Die Challenge ist der Client Key Exchange - PRE ist mit dem Public-Server-Key verschlüsselt. Der Server kommt also nur an PRE heran, wenn er den Private-Server-key hat. Die Response sind dementsprechend einfach die verschlüsselten Nachrichten, die der Client vom Server erhält (PRE wird ja bei der Berechnung der Schlüssel verwendet).
Der Client authentifiziert sich in dem konkreten SSL-Handshake Protokoll gar nicht.
Also die Challenge hab ich, denke ich verstanden (Client generiert PRE und Server wird zur Anwendung seines private Keys gezwungen um PRE zu erhalten).
Aber welche verschlüsselten Nachrichten sind denn nun die Response?
(Oder eben einfach nur die Tatsache dass der verschlüsselte Datenverkehr nun funktioniert!?) Also weil eigentlich müsste der Client doch noch irgendwie überprüfen, ob der Server den PRE auch wirklich entschlüsseln konnte...

(Liegt vielleicht drann, dass es schon wieder fast 1 Uhr ist, dass ichs grad net peil ^^)
NOSCE TE IPSUM
visit: http://www.flicknetwork.net.tc

Benutzeravatar
junin
Mausschubser
Mausschubser
Beiträge: 51
Registriert: 2. Mai 2006 22:44
Kontaktdaten:

Beitrag von junin »

also challenge: Private key benutzen um PRE zu entschlüsseln.
Response: korrekte Finished Nachricht senden, da diese ja nur korrekt ist, wenn das entschlüsselte PRE drin ist oder?

Richie
Mausschubser
Mausschubser
Beiträge: 92
Registriert: 25. Okt 2005 13:03
Wohnort: Darmstadt
Kontaktdaten:

Beitrag von Richie »

im prinzip ja
der Trick ist, dass PRE dazu benötigt wird, das Master Secret auszurechnen (wird noch paar mal 'ne hashfunktion drauf angewendet, steht genauer auf den folien, ist aber nicht sooooo wichtig hier). Wichtig ist: ohne PRE kein Schlüssel. der Client erwartet dann vom Server verschlüsselte Kommunikation unter Benutzung des Schlüssels PRE. Der Server verschickt also seine Finished-Nachricht verschlüsselt an den Client, der Client packt die mit hilfe des gemeinsamen Schlüssels aus. Hat der Server jetzt irgendwie (oder garnicht) verschlüsselt, weil er PRE nicht kennt, kommt für den Client nur Müll raus und die Prüfsumme ist eine ganz andere
There are only 10 types of people in the world:
Those who understand binary and those who don't

Benutzeravatar
junin
Mausschubser
Mausschubser
Beiträge: 51
Registriert: 2. Mai 2006 22:44
Kontaktdaten:

Beitrag von junin »

stimmt hab ich nicht bedacht, dass die Finished Nachrichten ja schon verschlüsselt übertragen werden.

Benutzeravatar
^Lara^
Mausschubser
Mausschubser
Beiträge: 68
Registriert: 17. Jan 2005 12:57

Beitrag von ^Lara^ »

kann nochmal einer ganz schnell erklären, warum mit diffie-hellmann eine man-in-the-middle-attack vollzogen werden kann?!

Danke!!!

Gestern wars mir noch ganz klar, aber jetzt versteh ich grad nix mehr =/

Benutzeravatar
SM
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 167
Registriert: 10. Okt 2005 18:11
Wohnort: Darmstadt
Kontaktdaten:

Beitrag von SM »

Bei Diffie Hellman geht das, weil der MITM sich unbemerkt in den Schlüsselaustausch einklinken kann. Es gibt keine Instanz, die dies von außen unterbindet, wie es zB bei einem Zertifikat der Fall wäre.

Sitzt der Angreifer zwischen Alice und Bob, so kann er quasi unbehelligt zu beiden eine verschlüsselte Sitzung aufbauen und die empfangenen Daten von Alice mit dem gemeinsamen Schlüssel mit Alice entschlüsseln, auslesen, mit dem gemeinsamen Schlüssel mit Bob wieder verschlüsseln und die Daten an ihn weitersenden (und umgekehrt).
~ Per aspera ad astra. ~

Antworten

Zurück zu „Archiv“