/** \if singledocument @latexonly \documentclass[a4paper,german]{article} \usepackage{babel} \usepackage{amsmath} \usepackage[pdftitle={Schl"usselaustausch f"ur symmetrische Verschl"usselung im ersten Mix},pdfauthor={Stefan K"opsell}, pdfsubject={Effiziente und skalierbare Realisierung von unbeobachtbarer und anonymer Kommunikation im Internet} ]{hyperref} \usepackage{array} \def\sig{\mathop{\rm Sig}\nolimits} \def\hash{\mathop{\rm H}\nolimits} \def\enc{\mathop{\rm E}\nolimits} \def\dec{\mathop{\rm D}\nolimits} \def\xor{\oplus} \begin{document} \title{Schl"usselaustausch f"ur symmetrische Verschl"usselung im ersten Mix\\V 0.5} \author{Stefan K"opsell} \maketitle @endlatexonly \endif \page pageSymKeyExchange Schlüsselaustausch für symmetrische Verschlüsselung im ersten Mix --- V 0.5 \section secGoals Ziel und Annahmen Das bisherige Mix-Protokoll unterscheidet bzgl. der Verschlüsselung nicht zwischen ersten, mittleren und letzten Mixen. Die Aufbaunachricht für einen Kanal ist in jedem Fall asymmetrisch verschlüsselt. Aus Performance-Sicht ist es natürlich sinnvoll, die Kanalaufbaunachrichten für den ersten Mix symmetrisch zu verschlüsseln. Der dafür notwendige Schlüsselaustausch (oder genauer: Geheimnistransport) soll beim Anmelden des Nutzers an der Mix-Kaskade erfolgen. Folgende Anforderungen soll das Schlüsselaustauschprotokoll erfüllen: -# Zwischen einem Nutzer U und dem ersten Mix soll ein Geheimnis ausgetauscht werden, das nur der Nutzer und der erste Mix kennen. -# Das Protokoll soll aus möglichst wenigen Nachrichten bestehen. -# Der Rechenaufwand für den Mix soll möglichst gering sein. -# Synchronität von Uhren oder Zählern etc. zwischen Nutzer und Mix soll keine Voraussetzung sein. -# Die erste Nachricht soll vom Mix zum Nutzer gesendet werden. Dem Nutzer können so zusätzliche Informationen übermittelt werden, die den weiteren Protokollablauf beeinflussen (Berücksichtigung von Unterschieden verschiedener Protokollversionen etc.) -# \anchor z1 Um "Denial Of Service"-Angriffe nicht zu erleichtern, sollte diese erste Nachricht keinen signifikanten Ressourcenverbrauch (Rechenzeit, Speicher etc.) beim ersten Mix verursachen . Dem Schlüsselaustauschprotokoll liegen dabei folgende Annahmen (auch bzgl. Angreifermodell) zugrunde: -# Der Nutzer kennt den öffentlichen Signatur-Testschlüssel tMix des ersten Mixes. -# Der Angreifer kann wie üblich alle Nachrichten abhören und verändern. -# Der Angreifer kennt nicht den geheimen Signatur-Schlüssel sMix des ersten Mixes. -# Der Angreifer kennt alle bisher ausgetauschten Geheimnisse. -# \anchor a1 Der Angreifer kennt außer dem aktuell gültigen alle geheimen Entschlüsselungschlüssel des ersten Mixes. \section secProto Protokoll Das Protokoll zum Transport eines Geheimnisses SEC vom Nutzer U zum ersten Mix besteht aus sechs Schritten, wobei bei drei Schritten Nachrichten übertragen werden. Der Ablauf ist wie folgt (alternative Darstellung siehe Abschnitt \ref figKeyTransport):
1.U: erzeugt Geheimnis SEC
2.Mix ---> U: m1=cMix,SigMix(cMix)
3.U ---> Mix: m2=EcMix(SEC)
\anchor checkDec 4.Mix: überprüft ob DdMix(m)?=(.,true)
5.Mix ---> U: m3=SigMix(m2)
\anchor checkSig 6.U: überprüft ob m3?=SigMix(m2)
\remark Der Nutzer überprüft nach Erhalt von m3 die Signatur (gemäß der Nachricht m2, die der Nutzer gesendet hat). Die erste Nachricht dient zur Übermittlung des aktuell gültigen öffentlichen Verschlüsselungsschlüssels des ersten Mixes. Da diese Nachricht unabhängig vom Nutzer U ist, kann sie voraus berechnet werden (Erfüllung von Anforderung \ref z1 "6"). Allerdings könnte es sich um einen Replay einer älteren Nachricht m'1 durch den Angreifer handeln. Gemäß Annahme \ref a1 "5" kennt der Angreifer in diesem Fall den zugehörigen Entschlüsselungsschlüssel. Mit der zweiten Nachricht wird das Geheimnis an den Mix übermittelt. Die dritte Nachricht dient dazu, die Aktualität des ausgetauschten Geheimnisses zu garantieren. Hat der Angreifer im ersten Schritt die Nachricht m1 durch eine ältere Nachricht m'1 ersetzt, so kann er die Nachricht m2 entschlüsseln und erfährt somit das Geheimnis. Allerdings muß er eine neue Nachricht m'2 mit dem aktuellen cMix erzeugen, damit der Mix sie akzeptiert (Schritt \ref checkDec). Dies wird dann durch den Nutzer in Schritt \ref checkSig "6" bemerkt, da der signierte Wert nicht dem berechneten entspricht. \section appendix Anhang \section secAlg Algorithmen und Notation
Ec(m)Verschlüsselung von m mittels OAEP-RSA mit dem öffentlichen Schlüssel c
Dd(m)Entschlüsselung von m mit dem geheimen Schlüssel d; wobei entweder Dd(m)=(m,true) oder Dd(m)=(.,false)
SigMix(m)Signatur geleistet vom ersten Mix unter die Nachricht m
\section figKeyTransport Protokoll für den Transport eines Geheimnisses vom Nutzer zum ersten Mix
MixNutzer

1.erzeugt Geheimnis SEC
2.\f$ m_1=c_\text{Mix},\mathop{\rm Sig}\nolimits_\text{Mix}(c_\text{Mix})\f$
\f$\overrightarrow{\hspace{5cm}}\f$
3.\f$ m_2=\mathop{\rm E}\nolimits_{c_\text{Mix}}(\text{SEC})\f$
\f$\overleftarrow{\hspace{5cm}}\f$
4.überprüft ob
\f$\mathop{\rm D}\nolimits_{d_\text{Mix}}(m)\overset{?}{=}\left(\cdot,\text{true}\right)\f$
5.\f$ m_3=\mathop{\rm Sig}\nolimits_\text{Mix}(m_2)\f$
\f$\overrightarrow{\hspace{5cm}}\f$
6.überprüft ob
\f$ m_3\overset{?}{=}\mathop{\rm Sig}\nolimits_\text{Mix}(m_2)\f$
*/