Unterschied zwischen Session Key und digitaler Signatur in der Kryptographie?
Hi,
verschlüsselt man seinen Datensatz hybrid wird, soweit ich weiss, der symmetrische Schlüssel, der Session Key, asymmetrisch mit dem öffentlichen Schlüssel verschlüsselt.
Bei der digitalen Signatur wird ein Hashwert mit dem privaten Schlüssel signiert.
Wann benutzt man was und warum nicht einfach symmetrisch verschlüsseln, statt mit dem privaten Schlüssel zu hashen?
3 Antworten
Signieren mußt Du letztlich so, daß ein Außenstehender jederzeit die Signatur prüfen kann. Das geht allerding nur dann, wenn Du das mit dem privaten Schlüssel eines asymmetrischen Verfahrens tust.
Nur so kann dann der Empänger überhaupt die Signatur gegenprüfen.
Um das leichter zu versteheh:
Ich schicke Dir meinen Text in Klartext und in exakter Kopie nochmals verschlüsselt. Entschlüsselst Du mit meinem PubKey den verschlüsselten Text, dann kannst Du sehen ob die beiden Versionen identisch sind.
Signaturen sollen nur die Integrität schützen. Wenn ich nun aber nicht immer die doppelte Datenmenge übertragen möchte, nutze ich statt einer 2. signierten Kopie einfach einen Hashwert.
Es gibt generell zwei Anwendungen:
Die eigentliche Verschlüsselung, um zu verhindern, daß jemand mitlesen kann und die Signatur, um die Echtheit des Abesnder zu verifizieren.
---
Anwendung 2 ist dafür gedacht, die Echtheit des Dokumentes zuzusichern. Das eigentliche Dokument darf aber ungeschützt übertragen werden. Hierbei wird im Endeffekt für das Dokument ein Hash erzeugt und verschlüsselt angehangen.
Hat mir jemand vorher seinen PubKey gegeben, kann ich also das Hash entschlüsseln und wenn ich selbst zum gleichen Hashwert komme, dann wurde das Dokument nicht verändert.
Theoretisch könnte ich auch den verschlüsselten Hash manipulieren, aber dann kommt es auch zu unterschiedlichen Ergebnissen, sodaß ich dem Dokument nicht traue. Ich muß also als Angreifer ohne Kenntnis des privaten Schlüssels sowohl das Dokument als auch den Hash korrekt ändern, um damit durchzukommen.
Im Endeffekt haben wir also etwas, das einer klassischen Unterschrift entspricht und die Authetizität zusichern soll. Die Quelle des Dokumentes/Textes ist der Besitzer des Schlüssels.
---
Kommen wir zur eigentlich Verschlüsselung. Ich generiere einen Sitzungsschlüssel für die symmetrische Verschlüsselung. Diesen möchte ich Dir auf sicherem Wege mitteilen, hierzu muß ich Deinen öffentlichen Schlüssel nutzen, denn würde ich meinen privaten Schlüssel verwenden, könnte jeder, der Zugriff auf meinen öffentlichen Schlüssel hat, die Nachricht entschlüsseln. Die Rolle ist also umgekehrt.
Du machst das ganze genauso, nutzt meinen öffentlichen Schlüssel, um mir einen SessionKey zu schicken, den nur ich entschlüsseln kann. Der Grund einen Sessionkey zu tauschen ist der:
Kann ich den SessionKey brechen, kann ich diese Sitzung 'mitlesen' aber keine mit anderen Schlüsseln. Dazu kommt, daß die symmetrische Verschlüsselung sehr effizient und schnell ist.
So, wir haben nun die Schlüssel getauscht, keiner kann mehr mitlesen, aber merkst Du wo das Problem liegt? Jeder kann mit meinem öffentlichen Schlüssel Daten an mich senden, woher weiß ich also, daß ich beim Schlüsseltausch auch wirklich mit Dir gesprochen habe?
Ganz einfach, Du signierst die ganze Nachricht zum Schlüsseltausch mit Deinem privaten Schlüssel, sodaß ich mit Deinem öffentlichen prüfen kann, daß die Nachricht von Dir kam. (Umgekehrt genauso)
Für jedes weitere Paket gilt das gleiche, jemand könnte die Pakete manipulieren, nichtmal gezielt, wenn ich einfach nur dumpf mit meinem Sessionkey entschlüssele, kommt vielleicht Müll heraus, vielleicht aber auch etwas, was noch lesbar ist. Deswegen prüfe ich unabhängig jedes Paket auf die Signatur (Quelle) und wenn diese nicht stimmt, kann ich mir den Rest sparen.
---
Alle Verfahren basieren auf Vertaulichkeit des Schlüssels, d.h. konkret:
Bei symmetrischen Verfahren dürfen nur die beiden Kommunikationspartner den(die) Schlüssel kennen. Bei public/priv Verfahren muß der private Schlüssel stets geheim bleiben, der öffentliche wird veröffentlicht und ich brauche eine Zusicherung, daß der öffentliche Schlüssel vom (Kommunikations)Partner ist.
Für uns beide würde das also bedeuten, daß Du mir Deinen öffentlichen Schlüssel, oder aber einen Fingerabdruck von diesem, auf einem gesicherten Kanal übergibt, zum Beispiel bei einem persönlichen Treffen.
Zu aller erst vielen Dank für die ausführliche Erklärung und ich denke nun habe das Ding mit der Signatur verstanden zu haben. Nach symmetrischer und asymmetrischer Verschlüsselung für die Performance wird als Signatur noch mal asymmetrisch verschlüsselt. Nennen wir das Ergebnis dieses Vorganges Paket A.
Paket B ist der rohe Text, den wir nun hashen.
Wir verschicken also das mehrfach verschlüsselte Paket A und das gehashte Paket B an unseren Empfänger.
Der öffnet mit unserem öffentlichen Schlüssel Paket A zur Verifizierung, dass es von uns kommt. Benutzt dann seinen privaten Schlüssel, um an den symmetrischen Schlüssel zu kommen und nutzt diesen, um den rohen Text zu erlangen.
Diesen rohen Text aus Paket A vergleicht er mit dem Hash, Paket B, und falls es der selbe Text ist, wurde die Nachricht nicht manipuliert.
Sehe ich das richtig, dass das Hashen der Datei in der Praxis etwas sehr übervorsichtig ist? Der gesamte Vorgang der zweifachen Verschlüsselung + Signatur ist praktisch nicht knackbar (Man in the Middle u.ä. außen vor). Das Hashen wäre also erst dann nützlich, wenn Paket A geknackt wurde?
Vorneweg, bei Verschlüsselung gibt es kein übervorsichtig, also zumindest fast nicht.
Grundlegend hast Du es jetzt beieinander, wenn Du beides kombinierst, machst Du eigentlich folgendes (Schlüsseltausch sei bereits erledigt):
Klartextpaket A wird verschlüssel zu Cryptopaket B. Nun wird Cryptopaket B signiert, indem ein verschlüsseltes Hash des Cryptopakets B and B angeheftet wird. Somit Entsteht Crypto+Sig Paket C.
Den Hash auf den Klartext zu berechnen erschwert die Verifikation, weil ich Verifikation und Entschlüsselung nicht verteilen kann.
Schau Dir mal das als Beispiel an, wie man es bei IPsec macht:
https://de.wikipedia.org/wiki/IPsec#/media/File:Ipsec_esp.jpg
- Bei Signaturen wird signiert, nicht verschlüsselt.
- Dein Schlüsselaustausch ist etwas umständlich.
- "[...] prüfe ich unabhängig jedes Paket auf die Signatur" ist ineffizient.
- Der Schlüssel wird bestenfalls nicht festgelegt und verschlüsselt übertragen, sondern ein Schlüssel vereinbart. Ersteres geht auch, ist aber nicht so toll.
- Nachdem man einen symmetrischen Schlüssel ("session key") vereinbart hat (also alle Parteien haben einen gemeinsamen Schlüssel) werden ausschließlich schnelle symmetrische Verfahren benutzt, mit denen man das tut, was man eben möchte: Vertraulichkeit/Integrität/blabla sicherstellen.
Wo ist die Gemeinsamkeit? Eine Signatur ist eben eine Signatur, ein Schlüssel ist ein Schlüssel...
Man macht das so, weil bei deinem Vorschlag "einfach symmetrisch verschlüsseln, statt mit dem privaten Schlüssel zu hashen" jede der Miliarden Instanzen, die solche Verfahren benutzen möchte eben Milliarden Schlüssel für jeweils jede andere speichern müssste (bzw. O( |P(alle)| ) viele).
(Ok, wenn man sich blöd anstellt.)
Stattdessen speicherst du eben nur Schlüssel von einer Hand voll Unternehmen, die dir auf Nachfrage asymmetrische Schlüssel von zB [gutefrage.net] besorgen können. Für gutefrage macht das zB die thawte Inc. mit Sitz in Südafrika. Mit diesen besorgten Schlüsseln machst du Punkt 1 oben und vereinbarst schnelle symmetrische Schlüssel.
Nein, Thawte (und andere CAs) liefern keine asymmetrischen Schlüssel anderer aus.
Sie signieren andere Schlüssel mit Ihrem eigenen und stellen somit den Trustanchor dar.
Dadurch kann ich sicher gehen (oder auch nicht), daß der Schlüssel zur angegeben Person/Entität gehört, auch wenn man sich noch nie getroffen und z.B. die Key-FingerPrints getauscht hat.
Wenn die Schlüssel bloß signiert und dann behalten würden hätte keiner etwas davon.
Klar schicken sie das erstellte Zertifikat dem Besitzer des öffentlichen Schlüssels, aber dieser benutzt es ja ausschließlich, um es weiter verschicken zu können. Letztendlich gelangt das Zertifikat vom Aussteller zu Dritten (die den Schlüssel benutzen möchten), auch wenn der Datenfluss über den Besitzer des Schlüssels geht.
Habe ich vielleicht zu abstrahiert dargestellt, an der Krypto ändert das aber nichts. Der Besitzer des Schlüssels stellt für das Zertifikat nur die Transportschicht dar, wenn man so will; die Sicherheit spielt sich zwischen Aussteller und Dritten ab.
Wenn Thawte meinen Schlüssel signiert, dann bekomem ich den natürlich in Form des Zertifikats mit Signatur zurück und liefere ihn selbst an Clients aus.
Alles andere wäre unsinnig.
---
Der Punkt ist aber, daß Thawte und Co nicht selbst die Schlüssel ausliefern, sondern nur signieren und für den Schlüssel 'bürgen'. Genauer, für die Assoziation von Schlüssel und Entität.
Dein letzer Absatz stellt es so dar, als würde ich von Thawte die Schlüssel direkt ausgeliefert bekommen, wenn ich mit einem Dritten kommuniziere. (Lies den letzten Absatz nochmal, Thawte kann Dir gar nicht den Schlüssel von GF besorgen, weil sie ihn nicht besitzen, wenn sie richtig gearbeitet haben.)
Stattdessen bekomme ich natürlich den Schlüssel direkt vom Kommunikationspartner und prüfe die Signatur indem ich mir ggf. den öffentlichen Schlüssel des Unterzeichners besorge und das Spiel solange wiederhole, bis ich irgendwann bei einem Schlüssel ankomme, dem ich a priori vertraue. (Stammzertifikat).
D.h., verbinde ich mich mit gutefrage, dann ackere ich mich die Trustchain bis zum Anchor hoch, Thawte liefert nir dabei maximal die eigenen (Intermediate)-Zertifikate (Schlüssel) aus, bis ich eben auf ein lokales Stammzertifikat stoße.
Ok ich antworte doch lieber nicht mehr. Hat keinen Sinn.
Bei der unsymmetrischen Verschlüsselung muss der Empfänger einen privaten Schlüssel besitzen. Der Sender hat einen öffentlichen Key.
Sinn und Zweck:
jemand sendet dir eine Nachricht, andere dürfen aber nicht mitlesen können.
Du empfängst die Nachricht und kannst sie entschlüsseln. Allerdings weißt du nichts über den Sender, da jeder, der im Besitz des privaten Keys ist, verschlüsselte Nachrichten versenden kann.
Bei der Signatur authentifiziert sich der Sender, indem er seine Nachricht mit seinem privaten Key signiert. der Empfänger bekommt dann die Nachricht, und schaut nach, ob die Signatur zum öffentlichen Signaturschlüssel passt.
Zusammengefasst:
- Verschlüsselung ist für die Wahrung der Vertraulichkeit
- Signatur ist für die Wahrung der Authentizität des Absenders
Abs 1: Bei der asymmetrischen Verschlüsselung muss der Empfänger einen privaten und einen öffentlichen Schlüssel besitzen. (Der Sender kennt dessen öffentlichen Schlüssel natürlich ("öffentlich"), der Schlüssel gehört aber zum Schlüsselpaar des Empfängers.)
Abs 4: Allerdings weißt du nichts über den Sender, da jeder, der im Besitz des öffentlichen keys ist, verschlüsselte Nachrichten versenden kann
Dann sind Signaturen also eher zur Prüfung des Datensatzes gut und nicht zur Prüfung des Absenders?
Denn ich kenne die hybride Anwendung so, dass durch den Einsatz eines symmetrischen Verfahrens der Absender verifiziert wird, weil nur der Absender ja den Session Key besaß und nur der Empfänger mit dem privaten Schlüssel den Session Key erlangen konnte. Oder ist der einzige Grund für ein symmetrisches Verfahren am Anfang wie AES, dass das Datenpaket kleiner ist?
Deiner Beschreibung nach werden also auf diese Art zwei Datenpakete geschickt? Zum einen das symmetrisch verschlüsselte Datenpaket und zum Anderen der zugehörige Schlüssel, verschlüsselt mit dem öffentlichen Schlüssel.
Wenn ich deinen letzten Absatz richtig interpretiere, wird also einmal eine Version des Textes geschickt, die mit dem privaten Schlüssel verschlüsselt ist und eine, die gehasht ist. Und wenn ich den Text mit dem öffentlichen Schlüssel entschlüssele und mit dem Hashwert gegenprüfe, weiss ich letztendlich, ob es der selbe Text ist und kann sichergehen, dass der Text während der Übertragung nicht manipuliert wurde.
Die Verifizierung des Datensatzes besteht mit Signaturen also darin, falls eines der beiden Datenpakete ausgetauscht wird, dass dieser Betrug erkennbar ist?
Aber wie sollte der Text denn überhaupt bei der Übertragung manipuliert werden? Beide Datenpakete sind von Dritten nicht entschlüsselbar. Person A benutzt zur Kommunikation den öffentlichen Schlüssel von Person B und andersrum. Keiner außer den Inhabern des privaten Schlüssels kann also die Datensätze entschlüsseln, die verschickt werden, weil diese immer mit dem öffentlichen Schlüssel verschlüsselt sind. Abgesehen von den verschickten Hashwerten.
Ein Dritter könnte das Datenpaket abfangen und gegen einen verschlüsselten Trojaner austauschen und beim Empfänger den öffentlichen Schlüssel gegen seinen eigenen austauschen. Aber wenn das passiert, bringt der Hashwert ja auch nicht viel. Oder verstehe ich da was falsch?