https://sarwiki.informatik.hu-berlin.de/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=50&offset=&namespace=0&username=&tagfilter= - New pages [en]2024-03-28T17:46:39ZFrom MediaWiki 1.39.5https://sarwiki.informatik.hu-berlin.de/SIKE:_Los,_Stop,_SchadeSIKE: Los, Stop, Schade2023-10-18T19:44:48Z<p>Wolfm: /* Quellen: */</p>
<hr />
<div>== SIKE und NIST ==<br />
<br />
SIKE steht für "Supersinguläre Isogeny Key Exchange". Es handelt sich um ein asymmetrisches Kryptosystem, das auf isogenen elliptischen Kurven basiert. SIKE ist ein Verschlüsselungsverfahren, das die Sicherheit von Datenübertragungen gewährleistet.<br />
Es verwendet isogene elliptische Kurven und die Berechnung von Isogenien, um Schlüssel auszutauschen und Daten zu verschlüsseln. SIKE basiert auf supersingulären isogenen elliptischen Kurven und Isogenien, wodurch es eine post-quantum Kryptografie bietet, die vor Angriffen von Quantencomputern sicher ist.<br />
Isogenien sind mathematische Transformationen zwischen elliptischen Kurven, die SIKE zur Schlüsselaustausch und Datenverschlüsselung verwendet.<br />
NIST (National Institute of Standards and Technology):<br />
Das National Institute of Standards and Technology (NIST) ist eine Amerikanische Behörde, die Standards und Richtlinien für verschiedene Bereiche, einschließlich Kryptografie, entwickelt und pflegt.<br />
NIST spielt eine wichtige Rolle bei der Festlegung von Standards für kryptografische Algorithmen und Protokolle, um die Sicherheit von Informationen und Kommunikation zu gewährleisten.<br />
NIST hat einen Wettbewerb zur Identifizierung von post-quantum-kryptografischen Algorithmen ins Leben gerufen, bei dem SIKE eine bedeutende Rolle spielt.<br />
NIST wird voraussichtlich Standards für post-quantum-Kryptografie festlegen, die von Organisationen und Regierungen weltweit übernommen werden.<br />
<br />
Sike würde es bis in die 4. Runde des NIST-Wettbewerbs für quantensichere Verschlüsselungsprotokolle schaffen. Leider wurde zu der Zeit, als SIKE an Popularität gewann, ein neues Papier veröffentlicht, das sicherstellte, dass SIKE nicht sicher ist und mit einem Single-core Laptop entschlüsselt werden kann. Der Angriff erforderte weder zu viel Rechenleistung noch dauerte er zu lange, um die vom NIST-Wettbewerb vorgegebenen Parameter zu entschlüsseln.<br />
<br />
==SIKE Schlüsselaustausch ==<br />
<br />
Im Folgenden geben wir einen zugegeben sehr groben Überblick, wie ein<br />
Diffie-Hellman Schlüsselaustausch im SIKE Protokoll funktioniert und<br />
anschließend, warum der private Schlüssel von Bob effizient berechnet<br />
werden kann.<br />
<br />
Wie bei einem klassischen Diffie-Hellman Verfahren stehen auch bei SIKE<br />
öffentliche Systemparameter fest. Dazu gehören zwei natürliche Zahlen e<br />
und f, eine Primzahl <math>p = 2^e\cdot3^f-1</math> und eine Elliptische Kurve E auf<br />
<math>\mathbb{F}_{p^2}</math> der Form <math>y^2 = x^3+6x^2+x</math>, d.h. allen Punkten <math>(x,y)</math> in <math>\mathbb{F}_{p^2}</math>, die<br />
die Gleichung erfüllen. Der zugrundeliegende Körper <math>\mathbb{F}_{p^2}</math> hat als<br />
Grundmenge genau die komplexen Zahlen, deren Real- als auch<br />
Imaginärteil in der Restklasse <math>\mathbb{F}_p \mbox{ }(={0,1,2,\dots,p-1})</math> enthalten sind.<br />
Desweiteren gibt es noch vier sogenannte Hilfspunkte <math>\mathrm{P}_A,\mathrm{Q}_A,\mathrm{P}_B,\mathrm{Q}_B</math> auf<br />
E, dessen Bedeutung wir gleich beleuchten werden.<br />
Wichtig für uns ist, dass die Punkte auf einer Elliptischen Kurve<br />
zusammen mit der Punktaddition eine Gruppe bilden. Können mit<br />
Homomorphismen, also strukturerhaltenden Abbildungen, auf Untergruppen<br />
abgebildet werden. Einen nicht-konstanten Gruppen Homomorphismus von<br />
einer elliptischen Kurve auf sich selbst nennen wir hier auch Isogenie.<br />
Der Kern einer Isogenie ist die Menge aller Punkte, die auf das neutrale<br />
Element abgebildet werden. Der Grad einer Isogenie ist die Größe ihres<br />
Kerns.<br />
Der Gedanke des SIKE Schlüsselaustauschs ist, dass sich Alice und Bob<br />
jeweils geheime Isogenien ausdenken, die sich zu einer dritten Isogenie verknüpfen lassen.<br />
Allerdings können sie nicht einfach die Isogenien bzw. ihre Kerne über den ungesicherten Kanal verschicken. Darum legen sie zwei (öffentliche) jeweils öffentliche Hilfspunktpaare fest, die Punkte <math>\mathrm{P}_A,\mathrm{Q}_A</math> der Ordnung <math>2^e</math> für Alice und die Punkte <math>\mathrm{P}_B,\mathrm{Q}_B</math> der Ordnung <math>3^f</math> für Bob. Alice denkt sich nun eine geheime ganze Zahl <math>a</math> aus, und erhält mit <math>A=\langle\mathrm{P}_A+a\cdot\mathrm{Q}_A\rangle</math> den Kern ihrer Isogenie <math>\varphi_A</math> der Ordnung <math>2^e</math>. Bob erhält analog eine Isogenie <math>\varphi_B</math> der Ordnung <math>3^b</math>. Nun tauschen sie über den unsicheren Kanal die Bildwerte der Hilfspunkte des jeweils anderen unter der eigenen Isogenie aus, also <math>\varphi_A(\mathrm{P}_B)</math>, <math>\varphi_A(\mathrm{Q}_B)</math> und <math>\varphi_B(\mathrm{P}_A)</math>, <math>\varphi_B(\mathrm{Q}_A)</math> aus. Somit kann der jeweils können sie mit dem eigenen Geheimnis und den Bildwerten der Isogenie des anderen auf einen gemeinsamen Kern und somit auch eine gemeinsame Isogenie kommen, die ein Angreifer ohne eines der privaten Geheimnisse <math>a</math> oder <math>b</math> nicht effizient ermitteln kann.<br />
<br />
== Mathematischer Angriff ==<br />
<br />
Der Angriff von Castryck und Decru zeigt, wie eine bösartige Alice Bobs geheime Isogenie rekonstruieren kann. Der Grundgedanke dabei ist, dass die gemeinsame Isogenie von Alice und Bob eine besondere Isogenie ist, die wir hier, um mathematische Definitionen und Genauigkeiten zu ersparen, einfach nur reduzierbar nennen. Man kann sich das so vorstellen, dass ihr Bild das Produkt zweier elliptischer Kurven ist.<br />
Das Ereignis, dass man von einer belibigen elliptischen Kurve durch eine (2,2)-Isogenie auf einem Produkt<br />
zweier Kurven landet, beträgt ungefähr <math>10/p</math>, also unfassbar klein.<br />
Castryck und Decru ziehen sich Kanis Theorem zur Hilfe, was grob besagt, dass wenn wir eine Isogenie haben und zwei Kerne, die bis (bis auf das neutrale Element) disjunkt den Kern der Isogenie aufspannen, die Isogenie reduzierbar ist bzw. wir auf einem Produkt zweier Kurven landen.<br />
Die in SIKE von Alice und Bob errechnete Isogenie zusammen mit den Kernen A und B entspricht genau den Bedingungen von Kanis Theorem und bildet somit auf eine Produktkurve ab. Im Angriff betrachten wir Bobs <math>3^f</math>-Isogenie als Verkettung von f vielen 3-Isogenien, die von Alice Bildkurve auf eine Produktkurve abbilden.<br />
Für die erste 3-Isogenie haben wir drei Möglichkeiten zu raten. Wir probieren eine und wissen nun, dass wenn wir richtig liegen, wir von der entstehenden Kurve mit einer <math>3^{f-1}</math>-Isogenie auf unsere Produktkurve gelangen. Wir konstruieren nun eine <math>2^e-3^{f-1}</math>-Isogenie, deren Pseudoinverse zusammen mit Bobs übriger <math>3^{f-1}</math>-Isogenie eine <math>2^e</math>-Isogenie ergibt, die laut Kanis Theorem wieder reduzierbar ist. Wir erinnern uns, dass es extrem unwahrscheinlich ist, mit solch einer Isogenie, die auch nur die e-fache Verknüpfung von 2-Isogenien ist, auf einer Produktkurve zu landen. Ob wir dies tun lässt sich sehr effizient überprüfen. Wenn die nicht der Fall ist, haben wir die 3-Isogenie auf jeden Fall falsch geraten, wenn doch können wir jedoch mit hoher Sicherheit ausschließen, dass wir falsch geraten haben, da es so unwahrscheinlich ist aus Zufall auf einer Produktkurve gelandet zu sein.<br />
So erraten wir schritt für Schritt Bobs 3^f Isogenie, indem wir immer wieder eine <math>2^e-3^{f-j}</math>-Isogenie (<math>j \in \{1,\dots,e-1\}</math>) bauen und überprüfen, ob wir mit der entstehenden <math>2^f</math> Isogenie auf einer Produktkurve landen. Kanis Theorem liefert uns hier sozusagen ein Entscheidungskriterium.<br />
<br />
== Angewandter Angriff ==<br />
<br />
Der Angriff wurde ursprünglich von dem Duo Wouter Castryck und Thomas Decru durchgeführt. In ihrem Beitrag erklärten sie, dass der Angriff mithilfe des Computer-Algebra-Software-Systems namens Magma möglich war. Da Magma nicht quelloffen ist, stand es nicht vielen Menschen zur Verfügung, so dass nicht viele den Angriff selbst testen konnten. Um die Implementierung für die Öffentlichkeit zugänglicher zu machen, implementierten Giacomo Pope und Rémy Oudompheng den ursprünglichen Angriff erneut in einem Softwaresystem namens SageMath. SageMath ist quelloffen, und jeder kann den Angriff herunterladen und auf seinen eigenen Geräten neu implementieren, solange SageMath auf dem jeweiligen Gerät installiert ist.<br />
<br />
SageMath kann hier installiert werden: https://www.sagemath.org/<br />
<br />
Die Parameter für den Angriff werden bereits im Vorfeld vom NIST-Wettbewerb vorgegeben. Die Parameter stellen sicher, dass der Schlüssel lang genug ist, damit der Angriff in einer realen Anwendung sinnvoll ist, und auch um sicherzustellen, dass die Verschlüsselung robust genug ist und ein gewisses Maß an Sicherheit bietet. Das bedeutet, dass die Parameter eine Richtlinie für die Entwickler darstellen und ihnen helfen, die richtigen Entscheidungen zu treffen, wenn SIKE implementiert wird.<br />
<br />
<syntaxhighlight lang="python"><br />
SIKE_parameters = {<br />
"SIKEp434" : (216, 137),<br />
"SIKEp503" : (250, 159),<br />
"SIKEp610" : (305, 192),<br />
"SIKEp751" : (372, 239)<br />
}<br />
</syntaxhighlight><br />
Code Beispiel 1: SIKE Parametern in den Code<br />
<br />
Wie es auf Beispiel 1 zu sehen ist, sind die SIKE Parametern für die Werten <math>a</math> und <math>b</math> gegeben. Mithilfe dieser Parameter kann die Primzahl <math>p</math> definiert werden. <math>p = 2^a \cdot 3^b -1</math>. <math>p</math> ist wichtig, um die Elliptische Kurven und Isogenien zu generieren. <br />
Die elliptische Kurve E<math>_\mathrm{start}</math> über einem endlichen Feld <math>\mathbb{F}_{p^2}</math> wird als Startpunkt für die Challenge definiert.<br />
Eine zufällige ganze Zahl Bobskey wird generiert und auf ternäre Ziffern eingestellt.<br />
Zum Abschluss der Challenge wird eine neue elliptische Kurve E<math>_B</math> erstellt und von E<math>_B</math> zu E<math>_{B_\mathrm{start}}</math> eine Isogeniekette erzeugt. Die Isogeniekette wird auf der Grundlage der Punkte <syntaxhighlight inline lang="python">P3 + Bobskey *Q3</syntaxhighlight> erstellt, wobei <syntaxhighlight inline lang="python">P3</syntaxhighlight> und <syntaxhighlight inline lang="python">Q3</syntaxhighlight> Torsionspunkte auf E<math>_\mathrm{start}</math> sind. Die Länge der Isogeniekette ist gleich dem Parameter b.<br />
Der Aufbau der Challenge besteht im Wesentlichen aus der Wahl der Parameter, der Generierung des privaten Schlüssels <syntaxhighlight inline lang="python">Bobskey</syntaxhighlight> und der Erstellung der Isogenese von der elliptischen Kurve E<math>_\textrm{start}</math> zur elliptischen Kurve E<math>_B</math> auf der Basis von <syntaxhighlight inline lang="python">Bobskey</syntaxhighlight> und den angegebenen Parametern.<br />
<br />
Die Codezeile <syntaxhighlight inline lang="python">EB, chain = Pushing3Chain(E_start, P3 + Bobskey * Q3, b)</syntaxhighlight> beinhaltet elliptische Kurvenoperationen und ist Teil des Challenge-Setups im Code.<br />
<syntaxhighlight inline lang="python">P3</syntaxhighlight> und <syntaxhighlight inline lang="python">Q3</syntaxhighlight> sind Punkte auf einer elliptischen Kurve E<math>_\mathrm{start}</math>. Diese Punkte sind Teil des Challenge-Setups.<br />
<syntaxhighlight inline lang="python">Bobskey</syntaxhighlight> ist eine zufällige ganze Zahl aus dem Bereich <math>[0, 3^b)</math>. Diese ganze Zahl ist Bobs privater Schlüssel in ternärer Darstellung.<br />
<syntaxhighlight inline lang="python">Bobskey * Q3</syntaxhighlight> bedeutet eine skalare Multiplikation des Punktes <syntaxhighlight inline lang="python">Q3</syntaxhighlight> mit der ganzen Zahl <syntaxhighlight inline lang="python">Bobskey</syntaxhighlight>. Diese Operation berechnet <syntaxhighlight inline lang="python">Bobskey</syntaxhighlight> mal den Punkt <syntaxhighlight inline lang="python">Q3</syntaxhighlight> auf der elliptischen Kurve.<br />
<syntaxhighlight inline lang="python">P3 + Bobskey * Q3</syntaxhighlight> addiert das Ergebnis der skalaren Multiplikation <syntaxhighlight inline lang="python">(Bobskey * Q3)</syntaxhighlight> zu dem Punkt <syntaxhighlight inline lang="python">P3</syntaxhighlight>. Dies ist eine Punktaddition auf der elliptischen Kurve. Das Ergebnis ist ein neuer Punkt auf der Kurve.<br />
<syntaxhighlight inline lang="python">Pushing3Chain(E_start, P3 + Bobskey * Q3, b)</syntaxhighlight> erzeugt eine Isogeniekette (Kette) von der elliptischen Kurve E<math>_\mathrm{start}</math> zu einer neuen elliptischen Kurve E<math>_B</math>, die auf den Punkten <syntaxhighlight inline lang="python">P3 + Bobskey * Q3</syntaxhighlight> basiert. Der Parameter <math>b</math> gibt die Länge der Kette an.<br />
<br />
Zusammenfassend lässt sich sagen, dass die Codezeile im Wesentlichen eine Herausforderung für den Angreifer darstellt, indem sie ein Problem der Isogenie elliptischer Kurven aufstellt. Das Ziel des Angreifers ist es, Bobs privaten Schlüssel (<syntaxhighlight inline lang="python">Bobskey</syntaxhighlight>) auf der Grundlage dieser Herausforderung wiederherzustellen, was die Arbeit mit den Operationen der elliptischen Kurve und den Isogenieberechnungen beinhaltet.<br />
<br />
<syntaxhighlight lang="python"><br />
# generate challenge key<br />
Bobskey = randint(0,3^b)<br />
<br />
EB, chain = Pushing3Chain(E_start, P3 + Bobskey*Q3, b)<br />
# Speeds things up in Sage<br />
EB.set_order((p+1)^2)<br />
PB = P2<br />
for c in chain:<br />
PB = c(PB)<br />
QB = Q2 <br />
for c in chain:<br />
QB = c(QB)<br />
<br />
print(f"If all goes well then the following digits should be found: {Integer(Bobskey).digits(base=3)}")<br />
</syntaxhighlight><br />
Code Beispiel 2: Pushing3Chain Funktion<br />
<br />
== Attack ==<br />
skB ist als leere Liste definiert, in die die Werte von Bobs geheimem Schlüssel während des Angriffs nacheinander eingefügt werden. <br />
<br />
Der Code durchläuft eine Schleife über <syntaxhighlight inline lang="python">i</syntaxhighlight> von <syntaxhighlight inline lang="python">1</syntaxhighlight> bis <syntaxhighlight inline lang="python">(b-2)</syntaxhighlight>. Für jedes <syntaxhighlight inline lang="python">i</syntaxhighlight> wird geprüft, ob <syntaxhighlight inline lang="python">b-i</syntaxhighlight> ungerade ist, indem die Bedingung <syntaxhighlight inline lang="python">(b-i) % 2 == 1</syntaxhighlight> verwendet wird. Ist dies der Fall, wird ein Index berechnet und Daten aus der uvtable auf der Grundlage dieses Index gesammelt.<br />
index wird berechnet als <syntaxhighlight inline lang="python">(b - i + 1) / 2</syntaxhighlight>.<br />
<syntaxhighlight inline lang="python">exp</syntaxhighlight> wird aus <syntaxhighlight inline lang="python">uvtable[index-1][1]</syntaxhighlight> extrahiert.<br />
Wenn <syntaxhighlight inline lang="python">exp</syntaxhighlight> kleiner oder gleich <syntaxhighlight inline lang="python">a</syntaxhighlight> ist, werden auch <syntaxhighlight inline lang="python">u</syntaxhighlight> und <syntaxhighlight inline lang="python">v</syntaxhighlight> aus <syntaxhighlight inline lang="python">uvtable[index-1][2]</syntaxhighlight> bzw. <syntaxhighlight inline lang="python">uvtable[index-1][3]</syntaxhighlight> abgerufen.<br />
Diese Daten werden in der Liste expdata an der <syntaxhighlight inline lang="python">i-1</syntaxhighlight>-ten Position als <syntaxhighlight inline lang="python">[exp, u, v]</syntaxhighlight> gespeichert.<br />
<br />
Nehmen wir die Parameter <syntaxhighlight inline lang="python">a=216</syntaxhighlight> und <syntaxhighlight inline lang="python">b=137</syntaxhighlight><br />
<br />
Da <syntaxhighlight inline lang="python">b</syntaxhighlight> <syntaxhighlight inline lang="python">137</syntaxhighlight> ist, wird <syntaxhighlight inline lang="python">expdata</syntaxhighlight> eine Liste mit <syntaxhighlight inline lang="python">134</syntaxhighlight> Unterlisten sein, die jeweils drei Nullen enthalten. Schleife von <syntaxhighlight inline lang="python">i</syntaxhighlight> im Bereich von <syntaxhighlight inline lang="python">1</syntaxhighlight> bis <syntaxhighlight inline lang="python">b-2</syntaxhighlight>, der von <syntaxhighlight inline lang="python">1</syntaxhighlight> bis <syntaxhighlight inline lang="python">135</syntaxhighlight> reicht. Prüfe, ob <syntaxhighlight inline lang="python">(b - i) % 2 == 1 </syntaxhighlight> für jedes <syntaxhighlight inline lang="python">i</syntaxhighlight>. Diese Bedingung prüft, ob <syntaxhighlight inline lang="python">b-i</syntaxhighlight> eine ungerade Zahl ist. Wenn <syntaxhighlight inline lang="python">b-i</syntaxhighlight> ungerade ist, wird der <syntaxhighlight inline lang="python">Index</syntaxhighlight> als <syntaxhighlight inline lang="python"> b-i/2 </syntaxhighlight> berechnet. Dieser Index wird für den Zugriff auf Elemente der <syntaxhighlight inline lang="python">uvtable</syntaxhighlight> verwendet.<br />
<br />
<syntaxhighlight inline lang="python">b=137</syntaxhighlight>, also ist <syntaxhighlight inline lang="python">expdata</syntaxhighlight> eine Liste mit <syntaxhighlight inline lang="python"> 134 </syntaxhighlight> Unterlisten, gefüllt mit <syntaxhighlight inline lang="python">[0, 0, 0]</syntaxhighlight>.<br />
Die Schleife läuft von <syntaxhighlight inline lang="python">i = 1</syntaxhighlight> bis <syntaxhighlight inline lang="python">i = 135</syntaxhighlight>.<br />
Wenn <syntaxhighlight inline lang="python"> i = 1 </syntaxhighlight> ist, ist <syntaxhighlight inline lang="python">(b - i) % 2 == 0</syntaxhighlight>, also passiert nichts.<br />
Wenn <syntaxhighlight inline lang="python"> i = 2 </syntaxhighlight> ist, ist <syntaxhighlight inline lang="python">(b - i) % 2 == 1</syntaxhighlight>, so dass der Index als <syntaxhighlight inline lang="python">(137 - 2 + 1) / 2 = 68 </syntaxhighlight>berechnet wird. Dann holt es <syntaxhighlight inline lang="python">exp = 135, u = 68402650496677101758628224525965</syntaxhighlight> und <syntaxhighlight inline lang="python">v = 491073477706829402358064079515557</syntaxhighlight> aus <syntaxhighlight inline lang="python">uvtable[68]</syntaxhighlight> und aktualisiert <syntaxhighlight inline lang="python">expdata[1]</syntaxhighlight> mit <syntaxhighlight inline lang="python">[135, 68402650496677101758628224525965, 491073477706829402358064079515557]</syntaxhighlight>.<br />
Dieser Vorgang wird für alle Werte von <syntaxhighlight inline lang="python">i</syntaxhighlight> fortgesetzt, bis die Schleife beendet ist.<br />
Nach der Schleife wird bet1 inkrementiert, bis es den Wert <syntaxhighlight inline lang="python">2</syntaxhighlight> erreicht (da <syntaxhighlight inline lang="python">expdata[2][0]</syntaxhighlight> der erste Nicht-Null-Wert ist).<br />
<br />
Für <syntaxhighlight inline lang="python">a = 216</syntaxhighlight> und <syntaxhighlight inline lang="python">b=137 </syntaxhighlight>ergeben sich mit der <syntaxhighlight inline lang="python">uv</syntaxhighlight>-Tabelle also folgende Ergebnisse:<br />
<br />
<syntaxhighlight inline lang="python">ai = expdata[2-1][0] = 135 </syntaxhighlight>,<br />
<syntaxhighlight inline lang="python">u = expdata[2-1][1] = 68402650496677101758628224525965</syntaxhighlight>,<br />
<syntaxhighlight inline lang="python">v = expdata[2-1][2] = 491073477706829402358064079515557</syntaxhighlight>.<br />
<br />
Diese Ergebnisse sind wichtig für die spätere Verwendung dieser Werte beim Orakel für die Split- und Glue-Operationen der Isogenien im Attack.<br />
<br />
Die ersten <syntaxhighlight inline lang="python">bet1</syntaxhighlight>-Ziffern werden für den Angriff berechnet, indem geprüft wird, ob einer der Werte korrekt ist und die Bedingung für das Glue- und Split-Orakel erfüllt. Dies geschieht, um einen bekannten Ausgangspunkt für den Angriff festzulegen und zu beweisen, dass der Angriff Schritte in die richtige Richtung unternimmt.<br />
<br />
Das Klebe- und Teilungsorakel wird verwendet, um zu prüfen, ob ein Schritt in die richtige Richtung gemacht wird, indem die gegebenen Kurven geklebt und geteilt werden: die erste Kurve C und die zweite Kurve E<math>_B</math>. Die Kurve C wird durch eine Reihe von Transformationen erzeugt, die auf die Ausgangskurve E<math>_\mathrm{start}</math> angewandt werden, geleitet von tauhatkernel_distort, und die Funktion Pushing3Chain spielt eine entscheidende Rolle bei diesem Kurvenerzeugungsprozess. Während E<math>_B</math> am Anfang des Codes initialisiert wird. Indem man auch die Punkte der Kurven der Ordnung <math>2^a</math> und <math>3^b</math> verwendet, kann die Funktion genutzt werden. Die Funktion nutzt die Eigenschaften von Richelot-Isogenien (kein Hinweis), wobei geprüft wird, ob die aus C und der Richelot-Isogenie abgeleitete Kurve in ein Produkt aus sipersingulären elliptischen Kurven zerlegt werden kann. <br />
Durch Kleben wird eine neue Isogenie erzeugt, und von dieser Klebekarte werden eine Kurve und ein Paar neuer Punkte durch eine Kette von Isogenien abgebildet.<br />
<br />
Der Angriff besteht darin, eine Kette von Isogenien zu konstruieren, ausgehend von einer bekannten Ausgangskurve und einem Punkt. Diese Kette stellt eine Folge von Transformationen dar, die auf die Kurve und den Punkt angewendet werden. Der Angriff besteht darin, eine Kette von Isogenien zu konstruieren, ausgehend von einer bekannten Ausgangskurve und einem Punkt. Diese Kette stellt eine Folge von Transformationen dar, die auf die Kurve und den Punkt angewendet werden.<br />
An einem bestimmten Punkt der Kette wird die Funktion <syntaxhighlight inline lang="python">Does22ChainSplit</syntaxhighlight> mit bestimmten Parametern aufgerufen. Diese Funktion prüft, ob der aktuelle Zustand der Isogenesekette in zwei separate Ketten aufgeteilt werden kann. Wenn sie <syntaxhighlight inline lang="python">True</syntaxhighlight> zurückgibt, deutet dies darauf hin, dass die aktuellen Berechnungen zu einer Situation geführt haben, in der die elliptische Kurve in zwei getrennte Kurven zerlegt werden kann.<br />
<br />
Wenn eine Kettenaufspaltung auftritt, zeichnet der Angreifer die Ziffern oder Parameter auf, die zum Erreichen dieser Aufspaltung verwendet wurden. Diese Ziffern sind potenzielle Kandidaten für Teile von Bobs geheimem Schlüssel, da sie mit der Transformation verbunden sind, die zur Aufspaltung der Kurve geführt hat. Das erste Teil des Angriffs kann in Abbildung 3 gesehen werden.<br />
<br />
<syntaxhighlight lang="python"><br />
# for j in CartesianPower([0,1,2], bet1) do<br />
for j in product([0,1,2], repeat=int(bet1)):<br />
print(f"Testing digits: {[j[k] for k in range(bet1)]}")<br />
<br />
# tauhatkernel = 3^bi*P3 + sum([3^(k-1)*j[k-1] for k in range(1,beta+1)])*3^bi*Q3<br />
tauhatkernel = 3^bi*P3 <br />
for k in range(1, bet1+1):<br />
tauhatkernel += (3^(k-1)*j[k-1])*3^bi*Q3<br />
<br />
tauhatkernel_distort = u*tauhatkernel + v*two_i(tauhatkernel)<br />
<br />
C, tau_tilde = Pushing3Chain(E_start, tauhatkernel_distort, bet1)<br />
<br />
P_c = u*P2 + v*two_i(P2) <br />
for taut in tau_tilde:<br />
P_c = taut(P_c)<br />
Q_c = u*Q2 + v*two_i(Q2)<br />
for taut in tau_tilde:<br />
Q_c = taut(Q_c)<br />
<br />
# if j eq <2 : k in [1..bet1]> or Does22ChainSplit(C, EB, 2^alp*P_c, 2^alp*Q_c, 2^alp*PB, 2^alp*QB, ai) then<br />
if j == (2,)*bet1 or Does22ChainSplit(C, EB, 2^alp*P_c, 2^alp*Q_c, 2^alp*PB, 2^alp*QB, ai):<br />
print("Glue-and-split! These are most likely the secret digits.")<br />
for k in j:<br />
skB.append(k)<br />
break<br />
<br />
print(skB)<br />
</syntaxhighlight><br />
<br />
Code Beispiel 3: Angriff mit den Glue and Split Oracle.<br />
<br />
Der Angriff wird fortgesetzt, in der Hoffnung, weitere Aufspaltungen zu finden und weitere Ziffern aufzuzeichnen. Mit der Zeit, wenn mehr Ziffern aufgezeichnet werden, kann der Angreifer genügend Informationen zusammensetzen, um Bobs gesamten geheimen Schlüssel wiederherzustellen. Das liegt daran, dass jede aufgezeichnete Ziffer einen Schritt in der Kette der Isogenese darstellt und dazu beiträgt, eine Folge von Transformationen zu bilden, die schließlich zum geheimen Schlüssel führt.<br />
<br />
Ein einziger Kettensplit verrät zwar nicht sofort Bobs geheimen Schlüssel, ist aber ein entscheidender Schritt im Angriffsprozess. Er bedeutet einen Fortschritt in der Fähigkeit des Angreifers, die Kurve in einfachere Komponenten zu zerlegen und potenzielle Kandidaten für Teile des geheimen Schlüssels aufzuzeichnen<br />
<br />
Der letzte Teil des Codes beinhaltet die Angriffsphase, um die letzten Ziffern von Bobs geheimem Schlüssel zu erzwingen. Es gibt eine Schleife, die die potenziellen Werte durchläuft und eine elliptische Kurve mit denselben Parametern und derselben Kette wie im Setup erzeugt. Die Schleife prüft, ob die j-Invariante der generierten elliptischen Kurve, mit der Bobs Schlüssel gefunden werden soll, mit der j-Invariante der zuvor generierten Kurve übereinstimmt. Wenn sie übereinstimmen, bedeutet dies, dass die richtigen Werte für die letzten Ziffern gefunden wurden. <br />
<br />
Am Ende wird Bobs Schlüssel ausgedruckt, der mit dem privaten Schlüssel übereinstimmt, der während des Einrichtungsteils des Codes erzeugt wurde.<br />
<br />
<br />
== Quellen ==<br />
<br />
* https://sike.org/files/SIDH-spec.pdf<br />
* https://eprint.iacr.org/2022/975.pdf<br />
* https://www.youtube.com/watch?v=rwri6Ai4H1I (sehr empfehlenswert!)<br />
* https://research.nccgroup.com/2022/08/08/implementing-the-castryck-decru-sidh-key-recovery-attack-in-sagemath/<br />
* https://doc.sagemath.org/html/en/tutorial/programming.html<br />
* https://eprint.iacr.org/2022/975.pdf#page=13<br />
* https://www.normalesup.org/~oudomphe/textes/202208-castryck-decru-shortcut.pdf</div>Marveyhttps://sarwiki.informatik.hu-berlin.de/Signal_Protocol_Post_Quantum_SecuritySignal Protocol Post Quantum Security2023-10-14T15:03:49Z<p>Wolfm: /* Intiate Handshake */</p>
<hr />
<div>In a world where smartphones are ubiquitous, it is important to have a way to securely and conveniently communicate with one another asynchronously without anybody else being able to spy on the messages. The Signal Protocol is an End-to-End Encrypted (E2EE) messaging protocol. At its core, it uses the Extended Triple Diffie-Hellman key exchange (X3DH) and the Double Ratchet algorithm to provide encrypted communication. It was initially developed by Trevor Perrin and Maxie Marlinspike of Open Whisper Systems in 2013 under the name TextSecure. Since then it has undergone multiple revisions with additions such as voice and video calling. It is used in a variety of apps such as Signal, WhatsApp, and more. In this article, I'll focus on X3DH. Unfortunately, the protocol is not post-quantum secure (PQ-secure), which can be attributed to its heavy reliance on Diffie-Hellman. This text gives a broad overview of the solutions presented so far on how to secure the handshake against a quantum adversary.<br />
<br />
=Properties of the Signal Protocol=<br />
The Signal Protocol has all the properties one would expect from an E2EE messaging protocol,<br />
but also some, which make it quite unique. As the source for the properties and their respective<br />
definitions, I will directly use Unger et al's definitions.<br />
<br />
* Confidentiality: Only the intended recipients are able to read a message. Specifically, the message must not be readable by a server operator that is not a conversation participant.<br />
* Integrity: No honest party will accept a message that has been modified in transit.<br />
* Authentication: Each participant in the conversation receives proof of possession of a known long-term secret from all other participants that they believe to be participating in the conversation. In addition, each participant is able to verify that a message was sent from the claimed source.<br />
* Forward Secrecy: Compromising all key material does not enable the decryption of previously encrypted data.<br />
* Backward / Future / Post-compromise Secrecy: Compromising all key material does not enable the decryption of succeeding encrypted data.<br />
* Plausible Deniability<br />
** Message Repudiation: Given a conversation transcript and all cryptographic keys, there is no evidence that a given message was authored by any particular user. [...]<br />
** Message Unlinkability: If a judge is convinced that a participant authored one message in the conversation, this does not provide evidence that they authored other messages.<br />
* Asynchronicity: Messages can be sent securely to disconnected recipients and received upon their next connection.<br />
There are some other properties of the Signal Protocol, however, these are less noteworthy compared to the ones mentioned above.<br />
<br />
=Extended Tripple Diffie-Hellman Handshake (X3DH)=<br />
The handshake protocol consists of three phases. First keys are created and then uploaded to the server. To perform a handshake, the interested party downloads the respective key bundle from the communication partner stored on the server and calculates their shared secret. They then send the first encrypted messages with the required key material attached. When the other user receives the message, they can perform the shared secret calculation and decrypt the first message.<br />
<br />
==Required Keys==<br />
For the protocol, each participant requires two and a set of key-pairs. The public keys are uploaded to the server.<br />
* Identity Key <math>^{\mathrm{pre}}\mathrm{IK}_{\mathrm{X}}</math><br />
** Used for authentication, can be checked before or after handshake<br />
* (Signed) Prekey <math>^{\mathrm{pre}}\mathrm{SPK}_{\mathrm{X}}</math><br />
** Used for forward secrecy<br />
* Set of one-time pre-keys <math>^{\mathrm{pre}}\mathrm{OPK}_{\mathrm{X}}</math><br />
** Used for (better) forward secrecy<br />
<br />
==Intiate Handshake==<br />
Assuming Alice wants to write Bob. She first downloads a key bundle including, if available, a one-time key as well. She verifies the signature of SPK and then generates an ephemeral key pair EK. With these keys, she performs three or <math>\big[</math>four<math>\big]</math> DH calculations:<br />
<br />
<math><br />
^{\mathrm{pre}}k_\mathrm{1} = \mathrm{DH}(^{\mathrm{pre}}\mathrm{IK}_{\mathrm{A;priv}}, ^{\mathrm{pre}}\mathrm{SPK}_{\mathrm{B;pub}}) <br />
</math><br />
<br />
<math><br />
^{\mathrm{pre}}k_\mathrm{2} = \mathrm{DH}(^{\mathrm{pre}}\mathrm{EK}_{\mathrm{A; priv}}, ^{\mathrm{pre}}\mathrm{IK}_{\mathrm{B; pub}})<br />
</math><br />
<br />
<math><br />
^{\mathrm{pre}}k_\mathrm{3} = \mathrm{DH}(^{\mathrm{pre}}\mathrm{EK}_{\mathrm{A; priv}}, ^{\mathrm{pre}}\mathrm{SPK}_{\mathrm{B; pub}})<br />
</math><br />
<br />
<math><br />
\big[^{\mathrm{pre}}k_\mathrm{4} = \mathrm{DH}(^{\mathrm{pre}}\mathrm{EK}_{\mathrm{A; priv}}, ^{\mathrm{pre}}\mathrm{OPK}_{\mathrm{B; pub}})\big]<br />
</math><br />
<br />
Alice then concatenates the keys and inputs them into a Key Derivation Function (KDF) to get the Shared Key (SK) she can use for encrypting her message. Besides the ciphertext, she includes identifiers for the SPK and OPK she used as well as her identity and ephemeral public key.<br />
<br />
==Receive Handshake==<br />
When Bob comes online and receives the message, he extracts Alice's keys and loads his own. With these, he performs the DH calculations ending up with the same SK to decrypt the ciphertext.<br />
<br />
=Quantum Secure X3DH=<br />
Since the original implementation uses elliptic curve DH, which can be efficiently broken using Shor's quantum algorithm, it is important to upgrade the protocol to a PQ-secure version. In 2017 NIST started a Post-Quantum Cryptography Standardization program for KEMs and Signature Schemes. One very interesting candidate SIKE / SIDH had the possibility of being a great replacement for DH. Research into making Signal quantum secure was oftentimes built on top of SIDH. However, it was broken in 2022 on a classical computer. Now research focuses on using Key Encapsulation Mechanisms (KEMs).<br />
<br />
==Using SIDH==<br />
SIDH allows the creation of a shared secret similar to DH. It is based on Supersingular Isogeny. Even though SIDH is not secure, looking into possible implementations can give insight into quantum secure protocol design.<br />
Consider one of the last Signal SIDH publications “Post-Quantum Signal Key Agreement with SIDH” by Samuel Dobson and Steven D. Galbraith which was published in March 2022.<br />
<br />
===SI-X3DH===<br />
The proposed protocol is a slight modification of standard X3DH. Instead of Diffie-Hellman SIDH is employed. At the time of publishing it was known, that SIDH was susceptible to adaptive key attacks. Thus the protocol applies methods of ensuring honest key generation. The ephemeral key used is generated through the Fujisaki-Okamoto (FO) transformation. <math>\pi</math> can be used by the recipient for an FO-proof. For each identity the owner uploads a non-interactive zero-knowledge proof to the server, ensuring the owner is in possession of the private key. Since this proof is apparently resource intensive, this proof is omitted for <math>^{\mathrm{post}}\mathrm{SPK}_{\mathrm{X}}</math>. Thus the <math>k_1</math> calculation needs to be modified, replacing <math>^{\mathrm{post}}\mathrm{SPK}_{\mathrm{B;pub}}</math> with <math>^{\mathrm{post}}\mathrm{IPK}_{\mathrm{B;pub}}</math>. This change slightly weakens forward security, since now <math>k_1</math> is static between two users and a breach of an identity key would be more severe. The protocol relied solely on SIDH, without any classical security.<br />
<br />
<math>^{\mathrm{post}}k_\mathrm{1} = \mathrm{SIDH}(^{\mathrm{post}}\mathrm{IK}_{\mathrm{A;priv}}, ^{\mathrm{post}}\mathrm{IK}_{\mathrm{B;pub}})</math><br />
<br />
<math>^{\mathrm{post}}k_\mathrm{2} = \mathrm{SIDH}(^{\mathrm{post}}\mathrm{EK}_{\mathrm{A; priv}}, ^{\mathrm{post}}\mathrm{IK}_{\mathrm{B; pub}})</math><br />
<br />
<math>^{\mathrm{post}}k_\mathrm{3} = \mathrm{SIDH}(^{\mathrm{post}}\mathrm{EK}_{\mathrm{A; priv}}, ^{\mathrm{post}}\mathrm{SPK}_{\mathrm{B; pub}})</math><br />
<br />
<math>\big[^{\mathrm{post}}k_\mathrm{4} = \mathrm{SIDH}(^{\mathrm{post}}\mathrm{EK}_{\mathrm{A; priv}}, ^{\mathrm{post}}\mathrm{OPK}_{\mathrm{B; pub}})\big]</math><br />
<br />
<math>\mathrm{SK} = \mathrm{KDF}\left(^{\mathrm{post}}k_1 \mathbin{\Vert} ^{\mathrm{post}}k_2 \mathbin{\Vert} ^{\mathrm{post}}k_3 \big[\mathbin{\Vert} ^{\mathrm{post}}k_4\big]\right) </math><br />
<br />
<math>\pi = s \oplus H_2(^{\mathrm{post}}k_1) \oplus H_2(^{\mathrm{post}}k_2) \oplus H_2(^{\mathrm{post}}k_3) \big[\oplus H_2(^{\mathrm{post}}k_4)\big]</math><br />
<br />
==KEM-based approaches==<br />
KEMs seem to be the most promising path for creating a PQ-secure Signal protocol. NIST already announced a winning KEM from their competition: CRYSTALS-Kyber. The algorithm uses lattices as its security anchor. For a great explanation of Kyber see the following video: https://media.ccc.de/v/rc3-2021-cwtv-230-kyber-and-post-quantum<br />
<br />
===Tutanota's Proposal===<br />
Tutanota is a German open-source email service offering E2EE emails between customers. To be protected against future quantum adversaries, they proposed an updated hybrid Signal protocol. The handshake protocol is built on top of classical X3DH. The scheme uses Kyber-786 as KEM and Dilithium 1280x1024 as a quantum-secure signature scheme. Each classic key pair gets a PQ-secure pendant. After verification of the downloaded key bundle, Alice additionally performs the following encapsulations:<br />
<br />
<math>(c_\mathrm{2}, ^{\mathrm{post}}k_\mathrm{2}) = \mathrm{encaps}(^{\mathrm{post}}\mathrm{IK}_{\mathrm{B; pub}})</math><br />
<br />
<math>(c_\mathrm{3}, ^{\mathrm{post}}k_\mathrm{3}) = \mathrm{encaps}(^{\mathrm{post}}\mathrm{SPK}_{\mathrm{B; pub}})</math><br />
<br />
<math>\big[(c_\mathrm{4}, ^{\mathrm{post}}k_\mathrm{4}) = \mathrm{encaps}(^{\mathrm{post}}\mathrm{OPK}^i_{\mathrm{B; pub}})\big]</math><br />
<br />
All resulting keys are then combined using the KDF. Since it is not possible to calculate a PQ-secure pendant to ^{\mathrm{pre}}k_\mathrm{1}, the authentication of Alice is missing. To overcome this the authors proposed for Alice to sign the handshake message to Bob. While this enables mutual authentication, the deniability is weakened. It can be cryptographically proven, that Alice sent the handshake message to Bob. To improve deniability, Hashimoto et al proposed ring signatures to be used, enabling anonymous signing of the data. However, a PQ-secure instantiation appears to be very complex and needs more research.<br />
<br />
===PQXDH===<br />
In May 2023 Signal published the first revision of the PQXDH protocol, intended to replace X3DH. Similar to Tutanota's proposal it's a hybrid protocol. Currently, it is only a slight modification of X3DH. As of September 2023, Signal added PQXDH to all Signal apps, enabling some quantum secure handshakes. As KEM Kyber-1024 is used. Each user generates a set of one-time PQ-secure keys <math>^{\mathrm{post}}\textrm{PQOPK}_{X}^i</math> including signatures and a last resort (semi-)static <math>^{\mathrm{post}}\textrm{PQSPK}_{X}</math>. The server hands out one-time keys until they are exhausted. During the handshake, Alice encapsulates a secret using Bob's public key:<br />
<br />
<math>(c_\textrm{pq}, ^{\mathrm{post}}k_\textrm{pq}) = \textrm{encaps}(^{\mathrm{post}}\textrm{PQPK}_{B; pub})</math><br />
<br />
The additional key is added to the KDF. This construction enables protection against passive quantum adversaries and prevents "harvest-now-decrypt-later" approaches. However, the protocol adds no PQ-secure mutual authentication, and thus would be susceptible to an active quantum adversary. This decision is very deliberate since this simple construction keeps a high level of deniability.<br />
<br />
==References==<br />
# Ermoshina, K., Musiani, F. & Halpin, H. End-to-end encrypted messaging protocols: An overview in International Conference on Internet Science (2016), 244–254.<br />
# Marlinspike, M. WhatsApp’s Signal Protocol integration is now complete Signal Technology Foundation. https://signal.org/blog/whatsapp-complete/ (2022).<br />
# Unger, N. et al. SoK: Secure Messaging in 2015 IEEE Symposium on Security and Privacy (2015), 232–249.<br />
# Marlinspike, M. The X3DH Key Agreement Protocol tech. rep. (Nov. 2016). https://signal.org/docs/specifications/x3dh/x3dh.pdf, archived at https://web.archive.org/web/20221205210600/https://signal.org/docs/specifications/x3dh/x3dh.pdf on Dec. 5, 2022.<br />
# Dobson, S., & Galbraith, S. D. (2021). "Post-Quantum Signal Key Agreement with SIDH." Cryptology ePrint Archive, Paper 2021/1187. Retrieved from https://eprint.iacr.org/2021/1187.<br />
# Stadler, S., Sakaguti, V., Kaur, H., & Fehlhaber, A. L. (2021). "Hybrid Signal protocol for post-quantum email encryption." Cryptology ePrint Archive, Paper 2021/875. Retrieved from https://eprint.iacr.org/2021/875.<br />
# Hashimoto, K., Katsumata, S., Kwiatkowski, K., & Prest, T. (2021). "An Efficient and Generic Construction for Signal's Handshake (X3DH): Post-Quantum, State Leakage Secure, and Deniable." Cryptology ePrint Archive, Paper 2021/616. DOI: 10.1007/s00145-022-09427-1. Retrieved from https://eprint.iacr.org/2021/616.<br />
# Kret, Ehren, and Rolfe Schmidt. "The PQXDH Key Agreement Protocol." Retrieved from https://signal.org/docs/specifications/pqxdh/pqxdh.pdf</div>Ehlerttohttps://sarwiki.informatik.hu-berlin.de/Elektronische_Siegel_UrkundenElektronische Siegel Urkunden2023-10-09T11:54:39Z<p>Abertoglia: /* Forward Secure Seals & Signatures */</p>
<hr />
<div><br />
<br />
== Aufbau eines PDFs==<br />
Um elektronische Signaturen und auch Siegel zu verstehen, sind zu aller erst Grundlagen notwendig wie überhaupt ein PDF (Portable Document Format) aufgebaut ist und wie es gelesen wird.<br />
Um dies zu verstehen wird ein PDF im Texteditor geöffnet.<br />
<br />
Als Beispiel haben wir das PDF "Hallo Welt": <br />
<br />
<syntaxhighlight lang="postscript"><br />
%PDF-1.7<br />
1 0 obj<br />
<< /Title (Hallo Welt) >><br />
endobj<br />
2 0 obj<br />
<< /Type /Catalog<br />
/Pages 3 0 R<br />
>><br />
endobj<br />
3 0 obj<br />
<< /Type /Pages<br />
/MediaBox [0 0 595 842]<br />
/Resources<br />
<< /Font << /F1 4 0 R >><br />
/ProcSet [/PDF /Text]<br />
>><br />
/Kids [5 0 R]<br />
/Count 1<br />
>><br />
endobj<br />
4 0 obj<br />
<< /Type /Font<br />
/Subtype /Type1<br />
/BaseFont /Helvetica<br />
/Encoding /WinAnsiEncoding<br />
>><br />
endobj<br />
5 0 obj<br />
<< /Type /Page<br />
/Parent 3 0 R<br />
/Contents 6 0 R<br />
>><br />
endobj<br />
6 0 obj<br />
<< /Length 41<br />
>><br />
stream<br />
/F1 48 Tf<br />
BT<br />
72 746 Td<br />
(Hallo Welt) Tj<br />
ET<br />
endstream<br />
endobj<br />
xref<br />
0 7<br />
0000000000 65535 f <br />
0000000009 00000 n <br />
0000000050 00000 n <br />
0000000102 00000 n <br />
0000000268 00000 n <br />
0000000374 00000 n <br />
0000000443 00000 n <br />
trailer<br />
<< /Size 7<br />
/Root 2 0 R<br />
>><br />
startxref<br />
534<br />
%%EOF<br />
</syntaxhighlight><br />
<br />
Dabei lesen wir ein PDF von unten nach oben beginnend mit dem Trailer<br />
<br />
<syntaxhighlight lang="postscript"><br />
trailer<br />
<< /Size 7<br />
/Root 2 0 R<br />
>><br />
startxref<br />
534<br />
%%EOF<br />
</syntaxhighlight><br />
<br />
Dabei erkennt der PDF-Reader unter Root, dass 2 0 das erste bearbeitete Objekt ist und unter startxref, dass er die xref-Tabelle beim Byte 534 findet.<br />
<br />
Von dort aus greift das Programm dann auf die xref-Tabelle zu: <br />
<br />
<syntaxhighlight lang="postscript"><br />
xref<br />
0 7<br />
0000000000 65535 f <br />
0000000009 00000 n <br />
0000000050 00000 n <br />
0000000102 00000 n <br />
0000000268 00000 n <br />
0000000374 00000 n <br />
0000000443 00000 n<br />
</syntaxhighlight><br />
<br />
Hier sieht man zuerst die Anzahl der Objekte im Dokument und anschließend das Byteoffset. Das f am Ende der Zeile steht dafür, dass es nicht angezeigt wird und das n, dass das Objekt sichtbar ist.<br />
<br />
<syntaxhighlight lang="postscript"><br />
2 0 obj<br />
<< /Type /Catalog<br />
/Pages 3 0 R<br />
>><br />
endobj<br />
</syntaxhighlight><br />
<br />
Die Objekte bestehen aus den tatsächlichen Inhalten des PDFs und referenzieren auf spätere Objekte.<br />
<br />
== Allgemeines zu elektronische Siegel und Signaturen ==<br />
<br />
Elektronische Siegel und Signaturen sind Sicherheitsverfahren, die dazu verwendet werden, die Integrität, Authentizität und Unveränderlichkeit von elektronischen Dokumenten oder Informationen zu gewährleisten. Im Gegensatz zu herkömmlichen physischen Siegeln, die auf Papier aufgedruckt oder angebracht werden, nutzen elektronische Siegel kryptografische Verfahren, um sicherzustellen, dass ein Dokument nicht unbefugt geändert wurde und die Identität des Absenders authentisch ist. <br />
<br />
Elektronische Siegel und Signaturen benötigen eine Sicherheitsinfrastruktur um implementiert zu werden. Die Gültigkeit der erstellten Zertifikate ist zeitlich begrenzt und wird durch einen Zeitstempel kontrolliert. <br />
<br />
Elektronische Signaturen basieren auf die X.509 Standard und werden sowohl in online Protokolle wie TLS/SSl als auch in offline Bereich für elektronische Signaturen benutzt.<br />
<br />
Darüber hinaus existiert der Advanced Electronic Signature (AES) Standard basieren auf die EU Verordnung Nr. 910/2014 (eIDAS) mit folgenden Anforderungen:<br />
<br />
# Der Unterzeichner kann '''eindeutig identifiziert''' und mit der Unterschrift verknüpft werden.<br />
# Der Unterzeichner muss die '''alleinige Kontrolle''' über die zur Erstellung der elektronischen Unterschrift verwendeten Daten haben (in der Regel ein privater Schlüssel).<br />
# Die Unterschrift muss in der Lage sein, festzustellen, ob die begleitenden Daten nach der Unterzeichnung des Dokuments manipuliert wurden.<br />
# Falls die begleitenden Daten geändert wurden, muss die Unterschrift ungültig werden.<br />
<br />
Dadurch wird auch zwischen verschiedenen formen von elektronischen Signaturen unterschieden wie der (normale) Signatur, der Fortgeschrittene Signatur und der Qualifizierte Signatur, jede mit unterschiedlichen Zwecken und Befugnissen.<br />
<br />
== Versiegelung durch QR-Code ==<br />
Als Beispiel sehen wir uns die Studienbescheinigung der HU Berlin an. Dort gibt es eine Möglichkeit per QR-Code auf die Verifizierungsseite zu kommen. Die Verifizierungsseite wird dabei auf dem Dokument selbst angegeben.<br />
<br />
[[File:Studienbescheinigung.png]]<br />
<br />
Die Vorteile davon sind die einfache Einführung des Systems und die vielfältige Einsetzbarkeit.<br />
Allerdings ist es auch anfällig für:<br />
* Sybil-Angriffe<br />
* Verifizierungsprozess ist umständlich und erfordert externe Ressourcen<br />
* Verifizierung erfolgt online<br />
<br />
== Versiegelung durch elektronische Signatur ==<br />
<br />
In der Praxis werden die Richtlinien für elektronische Siegel und Signaturen mithilfe von Public-Key-Kryptographie im Rahmen einer Public-Key-Infrastruktur (PKI) umgesetzt.<br />
<br />
[[File:PKI01.png|Beispiel 1|center|500px]]<br />
<br />
'''Beispiel 1:''' Cross-Zertifizierung auf Root-Zertifizierungsstellen-Ebene zwischen zwei PKIs<br />
Um sicherzustellen, dass Benutzerzertifikate in PKI 2 (wie "Benutzer 2") von PKI 1 als vertrauenswürdig eingestuft werden, erstellt CA1 ein Zertifikat (cert2.1), das den öffentlichen Schlüssel von CA2 enthält.<br />
<br />
Nun haben sowohl "cert2" als auch "cert2.1" (in grün) denselben Betreff und öffentlichen Schlüssel, daher gibt es zwei gültige Zertifikatsketten für cert2.2 (Benutzer 2): "cert2.2 → cert2" und "cert2.2 → cert2.1 → cert1".<br />
<br />
Ebenso kann CA2 ein Zertifikat (cert1.1) generieren, das den öffentlichen Schlüssel von CA1 enthält, damit Benutzerzertifikate in PKI 1 (wie "Benutzer 1") von PKI 2 als vertrauenswürdig eingestuft werden.<br />
<br />
Um die PKI effektiv zu nutzen, ist eine Online-Verbindung erforderlich, trotz ihrer Selbstauthentifizierungsfähigkeit. Damit werden Datenbanken geladen die uns die Verifizierung der Signatur ermöglichen:<br />
* '''CRL''' - Certificate Revocation List (X.509, alle 24 Stunden)<br />
* '''OCSP''' - Online Certificate Status Protocol (Echtzeit, geringerer Bandbreitenverbrauch)<br />
<br />
Diese Aufzeichnungen werden aktiv erneuert, was zu einer kurzen Lebensdauer (2 bis 5 Jahre) führt, um elektronische Siegel und Signaturen online zu authentifizieren.<br />
<br />
[[File:PKI02.png|Beispiel 2|center|400px]]<br />
<br />
'''Beispiel 2:''' Hier vereinfacht sehen wir, wie Alice ihre Nachricht an Bob mit ihrem privaten Schlüssel signiert und dann Bob die Signatur der Nachricht mit Alices öffentlichem Schlüssel verifiziert.<br />
<br />
===Design Schwächen===<br />
* Die Verwendung von schwarzen Listen ungültiger Zertifikate (wie CRLs und OCSP) kann zu Problemen führen, insbesondere wenn CRLs nicht verfügbar sind.<br />
* CRLs haben Nachteile aufgrund ihrer Größe und komplizierten Verteilungsmuster.<br />
* OCSP hat mehrdeutige Semantik und bietet keine historischen Widerrufsstatusinformationen.<br />
* Die Widerrufung von Stammzertifikaten wird nicht behandelt.<br />
* Delegationsprobleme treten auf, da CAs die Ausstellung von Zertifikaten nicht auf bestimmte Namensräume oder Attribute beschränken können.<br />
* Probleme mit föderierten Zertifikatsketten und dem Fehlen von bilateralen Vertrauensbeziehungen.<br />
<br />
===Probleme mit Zertifizierungsstellen===<br />
* CAs senken oft ihre Preise und entfernen teure Validierungsprüfungen, um wettbewerbsfähig zu bleiben, was als "Race to the Bottom" bezeichnet wird.<br />
* CAs lehnen in ihren Zertifikatspraxiserklärungen oft fast alle Garantien für Benutzer und vertrauende Parteien ab.<br />
* CA's unterliegen die rechtlichen Zuständigkeiten deren Geschäftssitz und können gesetzlich verpflichtet sein, die Interessen ihrer Kunden und Benutzer zu beeinträchtigen.<br />
<br />
===Umsetzungsprobleme===<br />
* Viele Implementierungen schalten die Überprüfung von Widerrufsinformationen aus, was die Einhaltung von Richtlinien erschwert.<br />
* Es gibt allgemein Schwierigkeiten mit Notationen, einheitlichen internationalen Standards und mehrdeutigen Attributen.<br />
* Die Länge von Attributen ist nicht eindeutig definiert<br />
* Implementierungsfehler ermöglichen falsche Subjektnamen und Codeinjektionsangriffe.<br />
<br />
===Kryptografische Schwächen===<br />
* Elektronische Siegelsysteme sind grundsätzlich auf sichere kryptografische Hashfunktionen angewiesen. Falls die PKI unsichere Hashfunktionen zulässt oder einem Angreifer eine Kollision gelingt, könnten Siegel verfälscht werden.<br />
* Zum Beispiel, MD2-basierte Zertifikate wurden lange Zeit verwendet und waren anfällig für Preimage-Angriffe. Da das Stammzertifikat bereits eine Selbstsignatur hatte, konnten Angreifer diese Signatur nutzen und für ein Zwischenzertifikat verwenden.<br />
<br />
== Angriffe ==<br />
<br />
=== QR-Code Hijacking ===<br />
Wir führen eine Sybil-Attacke, indem wir ein fiktives Dokument im Namen der Humboldt Universität erstellen die uns unwahre Leistungen akkreditiert.<br />
Dafür erstellen wir zuerst ein Dokument, das einer Bescheinigung der Humboldt Universität entspricht, mit einen QR-Code die zu unserer Webseite hinführt.<br />
Unsere Webseite ähnelt dem Aussehen der Humboldt Verifizierungsseite und ist durch ausgeklügelte URL-Gestaltung schwer von einer echte Webseite der Humboldt zu unterscheiden.<br />
Zum Ausprobieren dürfen Sie gerne folgende PDF öffnen:<br />
<br />
[[File:StudienbescheinigungDruck.pdf]]<br />
<br />
=== Incremental Saving Angriff ===<br />
PDFs haben eine Funktion des Inkrementellen Updates, wobei die PDF am Ende der Datei ein Body Update, eine neue XRef Tabelle und einen neuen Trailer erhält. Leider haben wir es nicht geschafft, ein solches Update nachzubauen. Dennoch teilen wir hier unseren Versuch:<br />
<br />
<syntaxhighlight lang="postscript"><br />
%PDF-1.7<br />
1 0 obj<br />
<< /Title (Hallo Welt) >><br />
endobj<br />
2 0 obj<br />
<< /Type /Catalog<br />
/Pages 3 0 R<br />
>><br />
endobj<br />
3 0 obj<br />
<< /Type /Pages<br />
/MediaBox [0 0 595 842]<br />
/Resources<br />
<< /Font << /F1 4 0 R >><br />
/ProcSet [/PDF /Text]<br />
>><br />
/Kids [5 0 R]<br />
/Count 1<br />
>><br />
endobj<br />
4 0 obj<br />
<< /Type /Font<br />
/Subtype /Type1<br />
/BaseFont /Helvetica<br />
/Encoding /WinAnsiEncoding<br />
>><br />
endobj<br />
5 0 obj<br />
<< /Type /Page<br />
/Parent 3 0 R<br />
/Contents 6 0 R<br />
>><br />
endobj<br />
6 0 obj<br />
<< /Length 41<br />
>><br />
stream<br />
/F1 48 Tf<br />
BT<br />
72 746 Td<br />
(Hallo Welt) Tj<br />
ET<br />
endstream<br />
endobj<br />
xref<br />
0 7<br />
0000000000 65535 f <br />
0000000009 00000 n <br />
0000000050 00000 n <br />
0000000102 00000 n <br />
0000000268 00000 n <br />
0000000374 00000 n <br />
0000000443 00000 n <br />
trailer<br />
<< /Size 7<br />
/Info 1 0 R<br />
/Root 2 0 R<br />
>><br />
startxref<br />
534<br />
%%EOF<br />
8 0 obj<br />
<<<br />
/Length 41<br />
>><br />
stream<br />
/F1 48 Tf<br />
BT<br />
72 746 Td<br />
(Hello World) Tj<br />
ET<br />
endstream<br />
endobj<br />
xref<br />
0 8<br />
0000000000 65535 f <br />
0000000009 00000 n <br />
0000000050 00000 n <br />
0000000102 00000 n <br />
0000000268 00000 n <br />
0000000374 00000 n <br />
0000000443 00000 n <br />
0000000535 00000 n<br />
trailer<br />
<< /Size 9<br />
/Info 8 0 R<br />
/Root 2 0 R<br />
>><br />
startxref<br />
923<br />
%%EOF<br />
</syntaxhighlight><br />
<br />
Diese Funktion ermöglicht es, das Dokument zu ändern. Es gibt PDF-Reader die nicht erkennen, dass nicht das ganze Dokument signiert ist.<br />
<br />
<br />
<br />
=== Signature Wrapping Angriff ===<br />
Durch diese Funktion ist es möglich ein signiertes PDF zu verändern, ohne die Signatur zu zerstören.<br />
<br />
[[File:SignaturWrapping.png]]<br />
<br />
Hier wird zuerst die Byte-Range c geändert. Danach wird eine neue xref-Tabelle mit den neuen Objekten erstellt. Dabei wichtig ist, dass die Tabelle das gleiche ByteOffset behält. Am Ende fügt man die bösartigen Objekte am Ende der Datei ein.<br />
<br />
=== Universal Signature Forging ===<br />
Direkter Angriff auf der Signatur, sein Inhalt und seine Byte Range. Dabei werden Werte geändert oder wegelassen.<br />
<br />
[[File:USFAngriff.png]]<br />
<br />
== Langzeit Archivierung von elektronische Siegel und Signaturen ==<br />
<br />
Blanchette (2006) erörtert drei Möglichen Wege für digitale Archive:<br />
# Digitale Signaturen/Siegel aufbewahren<br />
# Digitale Signaturen/Siegel zu entfernen<br />
# Die Spuren der digitale Signaturen/Siegel als Metadaten aufbewahren.<br />
Blockchain Technologie erlaubt uns eine vierte Möglichkeit für digitale Archive mit Trustchain.<br />
<br />
Trustchain zielt darauf ab, die Herausforderungen der langfristigen Aufbewahrung digital signierter Dokumente zu bewältigen, insbesondere wenn Zertifikate ablaufen oder Zertifizierungsstellen ihre Funktion einstellen. Durch die Verwendung von Blockchain-Technologie schlagen die Autoren ein halb offenes System vor, in dem bestimmte Institutionen neue Einträge erstellen können, während jede interessierte Partei die Aufzeichnungen anzeigen und ihre Echtheit bestätigen kann. Das Modell bietet zeitunabhängige Bestätigung durch den Hash-Vergleich des Dokuments in der digitalen Signatur, während es die zeitabhängigen Herausforderungen durch die Zusammenarbeit mehrerer unabhängiger Institutionen und die Nutzung einer Blockchain angeht.<br />
<br />
[[File:TC01.png|Architektur Überblick|center|750px]]<br />
<br />
Die Lösung basiert auf einer Fusion der Blockchain-Technologie, wie im Bitcoin-Whitepaper beschrieben, und den Prinzipien der ursprünglichen Haber- und Stornetta-Zeitstempelverknüpfungs- und Zufallszeugenlösungen. TrustChain, entwickelt als Teil des TRUSTER Preservation Model (EU31) im InterPARES Trust internationalen Projekt, garantiert, dass Dokumente und Signaturen unverändert bleiben, seit der TrustChain-Eintrag erstellt wurde. Diese Herangehensweise schafft Vertrauen durch die Zusammenarbeit mehrerer Institutionen und bietet eine innovative Lösung für die langfristige Sicherung digital signierter Dokumente.<br />
<br />
[[File:TC02.png|Schritte des Verfahrens|center|750px]]<br />
<br />
Die Autoren betonen, dass TrustChain zwar nicht die Lebensdauer digitaler Zertifikate verlängern kann, jedoch eine zuverlässige Sicherheit bietet, selbst wenn Zertifikate abgelaufen sind. Das Modell adressiert somit eine wichtige Lücke in der Sicherung digitaler Signaturen und wird als eine von mehreren Lösungen im Rahmen des InterPares Trust-Projekts betrachtet, das verschiedene Fallstudien, einschließlich digital signierter Rentenunterlagen und medizinischer Aufzeichnungen, umfasst.<br />
<br />
[[File:TC03.png|Inhalt eines Blocks|center|500px]]<br />
<br />
Die TrustChain-Blockchain ist frei zugänglich, jedoch dürfen nur autorisierte Mitglieder neue Daten schreiben. Dies erfolgt zur Erfüllung archivarischer Anforderungen oder auf Anfrage interessierter Parteien. Die Kommunikation erfolgt über spezialisierte Software oder eine Web-Schnittstelle. Der Prozess zur Hinzufügung eines Dokuments beginnt mit der Auswahl eines digital signierten Dokuments, dessen Signatur durch eine Zertifizierungsstelle validiert wird. Das eigentliche Dokument wird außerhalb gespeichert, während TrustChain einen Kontroll-Hash speichert. Die Technologie wird in Anwendungen wie Siemens TrustChain und Deloitte TrustChain verwendet. Auch EU-Projekte wie TrustChain fokussieren auf vertrauenswürdige digitale Identitäten und Daten, mit Schwerpunkten wie dezentralem Identitätsmanagement und Protokollen zur Bewertung der Vertrauenswürdigkeit von Entitäten.<br />
<br />
== Forward Secure Seals & Signatures ==<br />
<br />
Forward-Security erfasst die Idee, dass es selbst im Falle einer Offenlegung des aktuellen geheimen Schlüssels für jeden Angreifer rechnerisch unmöglich sein sollte, eine Signatur für einen vergangenen Zeitraum zu fälschen.<br />
Die erste formelle Forward-Secure Signatur Verfahren wurde von Bellare and Miner in 1999 präsentiert.<br />
<br />
Gewöhnliche digitale Signaturen haben eine grundlegende Einschränkung: Wenn der geheime Schlüssel eines Unterzeichners kompromittiert wird, werden alle Signaturen (vergangene und zukünftige) dieses Unterzeichners wertlos. Diese Einschränkung untergräbt insbesondere die Nichtabstreitbarkeit, die digitale Signaturen häufig bieten sollen. Tatsächlich ist eine der einfachsten Möglichkeiten für Alice, ihre Signaturen abzulehnen, das anonyme Veröffentlichen ihres geheimen Schlüssels irgendwo im Internet und die Behauptung, Opfer eines Computer-Einbruchs zu sein.<br />
<br />
Vorwärtssicherheit erfasst die Vorstellung, dass es selbst im Falle einer Offenlegung des aktuellen geheimen Schlüssels für jeden Angreifer rechnerisch unpraktikabel sein sollte, eine Signatur für einen vergangenen Zeitraum zu fälschen.<br />
<br />
Es gibt zwei Hauptansätze:<br />
<br />
# Diejenigen, die willkürliche Signaturschemata auf eine Black-Box-Art verwenden<br />
# Diejenigen, die bestimmte Signaturschemata modifiziere<br />
<br />
===Schlüsselevolution===<br />
<br />
Der Ansatz von vorwärtssicheren Schemata besteht darin, den geheimen Schlüssel regelmäßig zu ändern (und den Besitzer dazu zu verpflichten, den alten geheimen Schlüssel ordnungsgemäß zu zerstören). Die Zeit wird in Zeiträume unterteilt; am Ende jedes Zeitraums wird ein neuer geheimer Schlüssel erstellt und der alte wird zerstört. Die Nummer des Zeitraums, in dem eine Signatur generiert wurde, ist Teil der Signatur und wird dem Verifikationsalgorithmus zugeführt; Signaturen mit falschen Zeiträumen sollten nicht verifiziert werden.<br />
<br />
=== Guillou-Quisquater Signaturverfahren ===<br />
<br />
Das Guillou-Quisquater Signaturverfahren ist eine kryptografische Methode, die es ermöglicht, eine Nachricht zu signieren, um deren Authentizität zu beweisen, ähnlich wie Sie Ihre Unterschrift auf einem physischen Dokument setzen würden. Es wurde entwickelt, um sicher und effizient zu sein.<br />
<br />
[[File:FSS01.png|Guillou-Quisquater Algorithm|center|600px]]<br />
<br />
In einfachen Worten funktioniert es folgendermaßen:<br />
# '''Schlüsselgenerierung''': Zunächst generieren Sie ein Schlüsselpaar - einen privaten Schlüssel und einen öffentlichen Schlüssel. Der private Schlüssel bleibt geheim, und der öffentliche Schlüssel wird mit anderen geteilt.<br />
# '''Nachrichten-Signierung''': Wenn Sie eine Nachricht signieren möchten, verwenden Sie Ihren privaten Schlüssel, um eine eindeutige Signatur für diese Nachricht zu erstellen. Diese Signatur ist vergleichbar mit Ihrer "digitalen Unterschrift" auf der Nachricht.<br />
# '''Nachrichten-Verifikation''': Andere können Ihren öffentlichen Schlüssel verwenden, um die Authentizität der Nachricht zu überprüfen. Wenn die Signatur mit der Nachricht und dem öffentlichen Schlüssel übereinstimmt, bedeutet dies, dass die Nachricht nicht manipuliert wurde und tatsächlich von Ihnen signiert wurde.<br />
<br />
Das Guillou-Quisquater Signature Scheme basiert auf komplexen mathematischen Operationen, aber die Grundidee besteht darin, Ihren privaten Schlüssel zu verwenden, um einen eindeutigen Code (die Signatur) zu erstellen, der von anderen mithilfe Ihres öffentlichen Schlüssels überprüft werden kann. Wenn der Code übereinstimmt, können sie darauf vertrauen, dass die Nachricht echt ist und von niemand anderem verändert wurde.<br />
<br />
=== Itkins and Reyzin Signaturverfahren ===<br />
<br />
Die Hauptidee des vorwärts-sicheren Schemas von Itkins und Reyzin besteht darin, das GQ-Schema mit Shamirs Beobachtung (Lemma 1) zu kombinieren.<br />
<br />
[[File:FSS02.png|Itkins and Reyzin Algorithm|center|600px]]<br />
<br />
Konkret werden e1, e2, ..., eT als verschiedene Ganzzahlen gewählt, alle größer als 2l, alle paarweise relativ prim und relativ prim zu φ(n). Es gelte s1, s2, ..., sT, wobei sei i ≡ 1/v (mod n) für 1 ≤ i ≤ T. In der Zeitperiode i wird der Unterzeichner einfach das GQ-Schema mit dem geheimen Schlüssel (n, si, ei) verwenden, und der Verifizierer wird das GQ-Schema mit dem öffentlichen Schlüssel (n, v, ei) verwenden. Intuitiv wird dies vorwärts-sicher sein, aufgrund der relativen Primzahligkeit der ei's: Wenn ein Fälscher während der Zeitperiode b einbricht und die eb-te, eb+1-te, ..., eT-te Wurzeln von v erlernt, wird ihm dies nicht helfen, die ej-te Wurzel von v für j < b zu berechnen (noch allgemeiner die r-te Wurzel von v, wobei r|ej).<br />
<br />
== Keyless Digital Seals & Signatures ==<br />
<br />
Schlüssellose Signaturen sind eine alternative Lösung zu herkömmlichen PKI-Signaturen. Das Wort "schlüssellos" bedeutet nicht, dass bei der Erstellung der Signatur keine kryptografischen Schlüssel verwendet werden. Schlüssel sind weiterhin für die Authentifizierung erforderlich, aber die Signaturen können zuverlässig überprüft werden, ohne die fortgesetzte Geheimhaltung der Schlüssel vorauszusetzen. Schlüssellose Signaturen sind nicht anfällig für Schlüsselkompromittierung und bieten somit eine Lösung für das Problem der Langzeitgültigkeit von digitalen Signaturen. Traditionelle PKI-Signaturen können zwar durch Zeitstempel geschützt werden, aber solange die Zeitstempeltechnologie selbst auf PKI basiert, ist das Problem der Schlüsselkompromittierung immer noch nicht gelöst.<br />
<br />
Schlüssellose Signaturen werden in der Praxis als Multi-Signaturen umgesetzt, d.h., viele Dokumente werden gleichzeitig signiert. Der Signierungsprozess umfasst die folgenden Schritte:<br />
# '''Hashing''': Die zu signierenden Dokumente werden gehasht, und die Hash-Werte repräsentieren die Dokumente im weiteren Verlauf des Prozesses.<br />
# '''Aggregation''': Es wird ein globaler temporärer Hash-Baum pro Runde erstellt, um alle während einer Runde signierten Dokumente zu repräsentieren. Die Dauer der Runden kann variieren, ist jedoch in der beschriebenen Implementierung auf eine Sekunde festgelegt.<br />
# '''Veröffentlichung''': Die Top-3-Hash-Werte der pro Runde aggregierten Bäume werden in einen dauerhaften Hash-Baum (sogenannter Hash-Kalender) übernommen, und der Top-Hash-Wert dieses Baums wird als Vertrauensanker veröffentlicht.<br />
<br />
=== Merkle-Hash-Bäume ===<br />
<br />
Die Aggregationstechnik von Hash-Bäumen wurde erstmals von Merkle vorgeschlagen und erstmals für digitale Zeitstempel von Haber et al. verwendet. Die Zeitstempelung mittels Hash-Bäumen verwendet eine Einweg-Hash-Funktion, um eine Liste von Dokumenten in eine Digest mit fester Länge umzuwandeln, die mit der Zeit in Verbindung gebracht wird. Der Benutzer sendet einen Hash eines Dokuments an den Dienst und erhält einen Signatur-Token - den Nachweis, dass die Daten zu einem bestimmten Zeitpunkt existierten und dass die Anfrage über einen bestimmten Zugangspunkt empfangen wurde. Alle empfangenen Anfragen werden zu einem großen Hash-Baum zusammengefasst, und die Spitze des Baums wird für jede Sekunde beibehalten (Abbildung 1).<br />
<br />
[[File:KDSS01.png|Abbildung 1|center|600px]]<br />
<br />
Signatur-Token enthalten Daten zum Rekonstruieren eines Pfads durch den Hash-Baum - beginnend von einem signierten Hash-Wert (einem Blatt) bis zum Top-Hash-Wert. Zum Beispiel, um ein Token y an der Stelle x2 zu überprüfen, verknüpfen wir zunächst y mit x1 (als Teil des Signatur-Tokens beibehalten) und berechnen einen Hash-Wert y2 = h(x1 | y), der als Eingabe für den nächsten Hash-Schritt verwendet wird, bis wir den Top-Hash-Wert erreichen, d.h. y3 = h(y2 | x34) im vorliegenden Beispiel. Wenn y3 = xtop ist, kann davon ausgegangen werden, dass y im ursprünglichen Hash-Baum vorhanden war.<br />
<br />
[[File:KDSS02.png|Abbildung 2|center|600px]]<br />
<br />
Trotz der konzeptuellen Einfachheit eines Merkle-Hash-Baums ist der Aufbau eines globalen Netzwerks von Servern für einen solchen Baum komplex. Einfache baumförmige Service-Architekturen sind unerwünscht, da jeder Knoten ein potenzieller Single Point of Failure ist. Daher muss der Aggregationsbaum von redundanten Serverclustern aufgebaut werden. Wir müssen auch Redundanz in der Behandlung des eindeutigen Tops des Baums haben, sodass potenziell unterschiedliche Top-Hash-Werte, Cluster-Partitionen usw. auftreten können.<br />
<br />
In jedem Aggregationszeitraum wird der oberste Teil des Aggregationsbaums in einer Kalenderdatenbank gespeichert. Um sich unwiderruflich zur geordneten Sequenz von Werten in der Kalenderdatenbank zu verpflichten, werden sie zu einem binären Hash-Baum verknüpft - sodass die Blätter nur auf einer Seite hinzugefügt werden, ähnlich wie die Markierungen auf der Zeitleiste (siehe t in Abbildung 2).<br />
<br />
=== Übersicht Architektur ===<br />
<br />
Die Architektur des Hochleistungssystems ist in Abbildung 3 dargestellt. Das Hashing von Dokumenten erfolgt in der Anwendung, die eine Anfrage zur Signierung (oder Zeitstempelung) bildet - unter Verwendung bereitgestellter Software-Tools. Die Anfrage wird an ein Gateway gesendet - das Systemkomponente, das den Service an Endbenutzer liefert. Das Gateway führt eine anfängliche Aggregation der in seinem Aggregationszyklus erhaltenen Anfragen durch und sendet dann seine aggregierte Anfrage an den übergeordneten Aggregationscluster.<br />
<br />
[[File:KDSS03.png|Abbildung 3|center|750px]]<br />
<br />
Anfragen werden durch mehrere Ebenen von Aggregator-Servern aggregiert, und ein global eindeutiger Top-Hash-Wert wird vom Kerncluster ausgewählt. Eine Antwort wird unmittelbar durch die Aggregationsebenen zurückgesendet. Top-Hash-Werte für jeden Aggregationszeitraum werden in der "Kalenderdatenbank" gesammelt und durch die "Kalendercache"-Ebene an den Erweiterungsdienst verteilt, der normalerweise am selben Ort wie der Gateway-Host ist. Client-Anwendungen verwenden den Erweiterungsdienst für Überprüfungszwecke.<br />
<br />
== Wünsche für einen digitalen Siegel ==<br />
Wir hätten gerne eine automatische Verifizierung, Schutz vor Sybil Angriffen und eine unabhängige Verifizierung wie TLS/SSL Zertifikate.<br />
<br />
Wir haben uns dabei ein Siegel ausgedacht:<br />
Unser Siegel besteht aus einer Datenbank, in welcher die Namen der Institutionen mit deren Verifikationswebseiten verknüpft sind, und einer elektronischen Signatur, welche den Namen der Institution, des Empfängers, der Dokumentart und einen Verfikationscode beinhaltet.<br />
<br />
META-Daten:<br />
- Empfänger<br />
- Institution<br />
- Dokumentenart<br />
<br />
Ein Beispiel:<br />
<br />
[[File:Siegel.png]]<br />
<br />
== Quellen ==<br />
* https://pdf-insecurity.org/<br />
* Bralić, V., Kuleš, M., & Stančić, H. (2017). A model for long-term preservation of digital signature validity: TrustChain. INFuture2017 Proceedings: The Future of Information Sciences/Atanassova, I., Zaghouani, W., Kragić, B., Aas, K., Stančić, H., Seljan, S.(eds.). Zagreb: Department of Information and Communication Sciences, Faculty of Humanities and Social Sciences, University of Zagreb, Croatia, 89-103.<br />
* Buldas, A., Kroonmaa, A., & Laanoja, R. (2013, October). Keyless signatures’ infrastructure: How to build global distributed hash-trees. In Nordic Conference on Secure IT Systems (pp. 313-320). Berlin, Heidelberg: Springer Berlin Heidelberg.<br />
* Itkis, G., & Reyzin, L. (2001). Forward-secure signatures with optimal signing and verifying. In Advances in Cryptology—CRYPTO 2001: 21st Annual International Cryptology Conference, Santa Barbara, California, USA, August 19–23, 2001 Proceedings 21 (pp. 332-354). Springer Berlin Heidelberg.</div>Abertogliahttps://sarwiki.informatik.hu-berlin.de/W2023-ITSW2023-ITS2023-09-11T13:04:35Z<p>Dabenedi: /* Vorträge */</p>
<hr />
<div><br />
=Organisatorisches und Anmeldung für [https://sar.informatik.hu-berlin.de/teaching/2023-w/2023w_ITSecurityWorkshop/#plan IT-Security Workshop] 2. bis 13. Oktober [https://sar.informatik.hu-berlin.de/teaching/2023-w/2023w_ITSecurityWorkshop/#plan 2023]=<br />
Wenn Sie die unten genannten Themen interessant finden und in den ersten beiden Oktoberwochen Lust und Zeit haben sich damit auseinanderzusetzen, so finden Sie hier den angestrebten [https://sar.informatik.hu-berlin.de/teaching/2023-w/2023w_ITSecurityWorkshop/#plan Zeitplan] sowie die Möglichkeit sich und (optional) ein spannendes eigenes Thema [https://sar.informatik.hu-berlin.de/teaching/2023-w/2023w_ITSecurityWorkshop/#anmeldung anzumelden].<br />
<br />
=Vorträge=<br />
<br />
'''Freitag 13.10. 2023,''' [https://www.openstreetmap.org/search?query=Rudower%20Chaussee%2025%2012489%20Berlin#map=19/52.42944/13.53060 Rudower Chaussee 25], [https://www.openstreetmap.org/way/164560677 Haus 3], '''Raum 3'328''' (dritte Etage)<br />
<br />
{| class="wikitable" style="text-align: left; background: #cfc;"<br />
|- style="background: #fee;vertical-align:top;"<br />
<br />
|- style="background: #eef;"<br />
| 12:30-13:15 || '''[[ W2023-ITS#NTLM_Relaying | NTLM Relaying ]]''' || Lea, Ben || [[Media:NTLM-Relaying-Vortrag.pdf | pdf]]<br />
<br />
|- style="background: #ddf;"<br />
| 13:30-14:15 || '''[[ Elektronische Siegel Urkunden ]]''' || Arturo, Marc || [[Media:ElSIG_Folien.pdf | pdf]]<br />
<br />
|- style="background: #dfd;"<br />
| 14:15-14:45 || '''Pause: Snack & Schnack''' || ||<br />
<br />
|- style="background: #eef;"<br />
| 14:45-15:30 || '''[[ SIKE: Los, Stop, Schade ]]''' || Jakob, Marvey || [[Media:SIKE_Folien.pdf | pdf]]<br />
<br />
|- style="background: #ddf;"<br />
| 15:45-16:15 || '''[[ W2023-ITS#Signal_Protocol_Post_Quantum_Security | Signal Protocol Post Quantum Security ]]''' || Emily || [[Media:PQSIG_Folien.pdf | pdf]]<br />
<br />
|- style="background: #fee;"<br />
| 16:30-16:40 || '''Zusammenfassung & Dank''' || [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] || <br />
|}<br />
<br />
=Themen=<br />
<br />
==JavaCard: Secure Channel==<br />
<br />
Für viele sicherheitskritische Anwendungen werden SmartCards als Sicherheitskern verwendet. Für viele Anwendungsfälle (E-Mail Signatur, QES, nPA, eGK, SIM...) gibt es bereits komplette Lösungen die die Karte als Plattform und eine fertige Anwendung enthalten.<br />
Will man jedoch eine eigene SmartCard-Anwendung schreiben, ist oft die Verwendung einer JavaCard und die Erstellung einer eigenen Applikation ein denkbarer Weg. Doch wie geht das konkret? Finden Sie es heraus und versuchen Sie eine eigene Smartcardanwendung in Java zu entwickeln und diese gemäß des Global Platform Standards auf der hoffentlich dann vorhandenen Javacard zu installieren und dann zu verwenden. [[JavaCard (erste Schritte)]]<br />
<br />
Um eine sichere Verbindung zwischen der SmartCard und der Anwendungauf dem Rechner zu gewährleisten (was bei Mehrbenutzersystemen (Zugriff via USB oder insbesondere bei kontaktlosen Karten) wird das "Secure Channel Protokoll" verwendet. Unsere Smartcard J3R180 unterstützt SCP in der Version 03. Versuchen Sie ein Beispiel für eine sichere Kommunikation einer Anwendung auf dem Rechner mit einem von Ihnen geschriebenen JavaCardApplet zu erstellen.<br />
<br />
Links:<br />
* [https://docs.oracle.com/javacard/3.0.5/guide/eclipse-java-card-plug.htm JavaCard Plugin für Eclipse]<br />
* [https://sourceforge.net/p/globalplatform/wiki/GPShell/ GP Shell]<br />
* [https://github.com/martinpaljak/GlobalPlatformPro GlobalPlatformPro]<br />
* [https://github.com/martinpaljak/GlobalPlatformPro/blob/master/library/src/main/java/pro/javacard/gp/SCP03Wrapper.java SCP03Wrapper]<br />
* [https://github.com/martinpaljak/GlobalPlatformPro/tree/master/docs/JavaCardBuyersGuide JavaCardBuyersGuide]<br />
* [https://www.cardlogix.com/downloads/support/JCOP4_P71_SecurityTargetLite_v34-java-card.pdf JCOP4 J3R180 SCP03]<br />
* [https://docs.oracle.com/javacard/3.0.5/prognotes/title.htm JavaCard 3.0.5]<br />
* [https://docs.oracle.com/javacard/3.0.5/api/index.html JavaCard 3.0.5: API]<br />
* [https://globalplatform.org/wp-content/uploads/2014/07/GPC_2.3_D_SCP03_v1.1.2_PublicRelease.pdf Secure Channel Protocol '03']<br />
* [https://stackoverflow.com/questions/29455715/java-card-applets-secure-data-transmission-and-secure-channel Beispiel für SCP02]<br />
<br />
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
==Umsetzung eines PQC-Verfahrens im Rahmen des CNG Frameworks==<br />
<br />
(spannend, aber anspruchsvoll)<br />
<br />
Post-Quanten-Kryptografie befindet sich derzeit im Prozess der Standardisierung und es werden viele Demo-Anwendungen umgesetzt. Statt jede Anwendung einzeln zu modifizieren und Support für diese neuen Verfahren einzubauen, bietet das MS CNG Framework die Möglichkeit, Module global im Betriebssystem zu ergänzen. Anwendungen, die die entsprechenden System-Routinen verwenden, erhalten werden damit PQC-fähig ohne modifiziert werden zu müssen.<br />
<br />
Aufgaben:<br />
* Einarbeitung in das CNG-Framework<br />
* Analyse des Beispielcodes (C++)<br />
* Auswahl eines geeigneten PQC-Verfahrens (z.B. Dilithium https://pq-crystals.org/index.shtml)<br />
* Implementierung von CNG Cryptographic Algorithm Provider sowie Signature/Encryption Provider<br />
<br />
Links:<br />
* [https://learn.microsoft.com/en-us/windows/win32/seccertenroll/understanding-cryptographic-providers Understanding Cryptographic Providers]<br />
* [https://www.microsoft.com/en-us/download/details.aspx?id=30688 SDK mit Dokumentation und Beispiel-Code]<br />
* [[File:Skizze_MS_CNG.png|32px |alt=Alt Skizze CNG|Skizze Microsoft CNG]] Skizze Microsoft CNG<br />
<br />
Mentoren: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller], [mailto:Frank.Morgner@BDr.de Frank Morgner], [mailto:Holger.Eble@BDr.de Holger Eble]<br />
<br />
==POC@FIDO2==<br />
Auch wenn FIDO2 ein Verfahren zur starken Authentisierung ist und somit nicht durch das "store now, decrypt later"-Szenario bedroht ist, so ist es sicher eine gute Idee auch an dieser Stelle bereits über die Verwendung von quantenresistenten verfahren nachzudenken. So sind ist der Plan ja die FIDO-Sticks eine lange Zeit als hardwaresichere Platform zu nutzen. Konkret wurde mit OpenSK einer in Rust geschriebenen Open-Source-Implementierung ein Prototyp vorgelegt, der die Signaturalgorithmen (klassisch) ECDSA und (PQC) Dilithium zu einer Hybridsignatur kombiniert, wobei die Signaturerstellung in einem akzeptablen Zeitrahmen auf dem FIDO-Stick erfolgt. Versuchen Sie diese Implementierung auf der Plattform Nordic nRF52840-DK zum laufen zu bringen, wie es in dem Abstract des Papers angeregt wird: "We publish an open-source implementation of our scheme at [https://github.com/google/OpenSK/releases/tag/hybrid-pqc hybrid-pqc] so that other researchers can reproduce our results on a nRF52840 development kit."<br />
Hierzu sollten Sie vielleicht erst einmal versuchen die klassische OpenSK-Version mit CTAP zu testen, um dann zu verstehen, wie man auf dem Stick das Erzeugen eines Schlüsselpaars anstößt. Erst im nächsten Schritt wird der Testaufbau dann auf die hybride Version erweitert.<br />
<br />
Links:<br />
* [https://www.golem.de/news/kryptografie-google-schuetzt-passwortlose-logins-vor-quantencomputern-2308-176932.html Golem Artikel]<br />
* [https://eprint.iacr.org/2022/1225.pdf Paper]<br />
* [https://github.com/google/OpenSK/releases/tag/hybrid-pqc hybrid-pqc Code]<br />
* [https://github.com/kaczmarczyck/OpenSK OpenSK]<br />
* [https://github.com/kaczmarczyck/OpenSK/blob/stable/docs/boards/nrf52840dk.md nRF52840-DK]<br />
<br />
Mentoren: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
==WireGuard@Informatik==<br />
WireGuard ist ein auf modernen kryptografischen Algorithmen basierendes, in den Linux-Kernel gut integriertes und sehr performantes VPN. Die Konfiguration für einzelne Peers ist sehr übersichtlich. Jedoch ist es nicht vorgesehen, dynamische IP-Adressen nach etablierter Verbindung zu nutzen, sondern diese werden direkt in der Konfigurationsdatei gesetzt. Das reduziert die Komplexität und erhöht die Geschwindigkeit. Wie könnte aber eine komfortable Konfiguration für sehr viele Nutzer (die potenziell auch noch mehrere Geräte haben) aussehen? Gibt es hier bestehende Ansätze, wie (z.B. über einen Webdienst für authentisierte Institutsmitglieder) Konfigurationsdateien (die vielleicht auch einen QR-Code beinhalten) für die Geräte generiert und an die berechtigten Nutzer ausgeliefert werden, so dass potenziell alle Benutzer all Ihre Geräte konfliktfrei mit dem VPN verbinden können?<br />
Auch hierbei ist es sicherlich sinnvoll bereits über eine hohe Sicherheit gegen zukünftige Angreifer mit Quantencomputer nachzudenken [https://man.archlinux.org/man/wg.8.en man]:<br />
<blockquote>"PresharedKey — a base64 preshared key generated by wg genpsk. Optional, and may be omitted. This option adds an additional layer of symmetric-key cryptography to be mixed into the already existing public-key cryptography, for post-quantum resistance."</blockquote><br />
Ein interessantes Projekt könnte vielleicht <code>wg-dynamic</code> sein. Aber suchen Sie getrost nach besseren Ideen oder Ansätzen.<br />
<br />
Links:<br />
* [https://www.wireguard.com/ WireGuard]<br />
* [https://www.wireguard.com/protocol/ Protokoll]<br />
* [https://github.com/WireGuard/wg-dynamic wg-dynamic]<br />
* [https://github.com/WireGuard/wg-dynamic/blob/master/docs/idea.md wg-dynamic: Idee]<br />
<br />
<br />
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
==OpenVPN: performant & sicher==<br />
OpenVPN ist ein sehr etabliertes und auch historisch gewachsenes VPN, welches viele Konfigurationsmöglichkeiten bietet. Das ist einerseits natürlich fantastisch, andererseits auch eine Herausforderung. Im Vergleich zu WireGuard, welches aufgrund seiner schlanken und "state of the art"-Kryptografie bereits Einzug in den Kernel gefunden hat, ist OpenVPN häufig signifikant langsamer und nicht immer sicher konfiguriert.<br />
<br />
Können Sie hier weiterhelfen?<br />
* So wäre es wünschenswert bereits jetzt etwas gegen Angreifer zu unternehmen, die den VPN-Verkehr aufzeichnen und später mit einem Quantencomputer entschlüsseln wollen. Weiterhin ist es wünschenswert, die Sicherheitsreserven zu erhöhen. Da Sie bei einer Authentifizierung mittels TLS-Client-Zertifikaten eine eigene PKI verwenden können, bietet es sich an, hier ECC-Schlüssel mit >400 Bit zu wählen. Weiterhin sind die Optionen <code>--tls-crypt</code> oder besser <code>--tls-crypt-v2</code> interessant. Versuchen Sie, einen schnellen und sicheren TLS-Handshake zur Authentifizierung und Schlüsselableitung zu etablieren.<br />
* Im zweiten Schritt müssen dann noch die eigentlichen Nutzdaten ver-/entschlüsselt werden. Um dies performant und dennoch sicher umzusetzen, können Sie zum einen versuchen, die Hardwareunterstützung für AES zu aktivieren. Aber selbst wenn Ihnen das gelingt, wird WireGuard wahrscheinlich immer noch weitaus performanter sein. Das Problem ist, dass bislang bei OpenVPN in der Regel zwischen Versenden und Empfang und der Ver-/Entschlüsselung ein aufwendiger Wechsel zwischen User- und Kernelspace erfolgt, der in WireGuard nicht erforderlich ist. Doch auch hier gibt es Hoffnung in Gestalt von "OpenVPN Data Channel Offload", welches unter Linux ein Kernelmodul "openvpn-dco" nutzt um hier die Performance deutlich zu steigern. Konkret werden die AEAD Verschlüsselungen AES-GCM-256, AES-GCM-128 und CHACHA20POLY1305 unterstützt.<br />
Motivation: Bei meinem OpenVPN unter Windows 10 hat sich der Downstream von 48 Mbit/s auf 182 Mbit/s (exemplarisch, nicht repräsentativ) verbessert.<br />
<br />
Links:<br />
* [https://openvpn.net/blog/openvpn-data-channel-offload/ OpenVPN DCO]<br />
* [https://github.com/OpenVPN/openvpn OpenVPN git für openvpn 2.6.0]<br />
* [https://github.com/OpenVPN/ovpn-dco-win git für ovpn-dco-win]<br />
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.html BSI TR-02102-2]<br />
<br />
Mentoren: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
==<span style="background:greenyellow">[[SIKE: Los, Stop, Schade]]!</span>==<br />
[Jakob, Marvey]<br />
<br />
Lange Zeit war SIKE "Supersingular Isogeny Key Encapsulation" ein heißer Kandidat im NIST-Wettbewerb für quantensichere Kryptoverfahren hier insbesondere für den asymmetrischen Diffie-Hellmann-artigen Schlüsselaustausch. Insbesondere interessant schienen die moderaten Längen der auszutauschenden Nachrichten, welche für Overhead in Protokollen wie TLS wichtig sind. Lange Zeit wurde der optimierte Algorithmus als sicher angesehen und schaffte es bis auf die Kandidatenliste für die vierte Runde. Dann wurde jedoch gezeigt, dass der private Schlüssel recht effizient (auf einem Laptop in einer Stunde) aus der Beobachtung von SIDH wiederhergestellt werden kann.<br />
<br />
Versuchen Sie (im Groben) zu verstehen, wie der Algorithmus funktioniert. Versuchen Sie, die Idee des Angriffs nachzuvollziehen. Probieren Sie an einem eigenen Beispiel den Angriff mithilfe von <code>SageMath</code>.<br />
<br />
... und jetzt die eigentliche Herausforderung: Versuchen Sie uns das im Vortrag zu erklären ;-).<br />
<br />
Links:<br />
* [https://www.golem.de/news/post-quanten-kryptographie-verschluesselung-mit-isogenien-ist-unsicher-2207-167267.html Golem]<br />
* [https://sike.org/ SIKE]<br />
* [https://csrc.nist.gov/News/2022/pqc-candidates-to-be-standardized-and-round-4 NIST:PQC:4. Runde Kandidaten]<br />
* [https://eprint.iacr.org/2022/975 An efficient key recovery attack on SIDH]<br />
* [https://homes.esat.kuleuven.be/~wcastryc/ PoC in Magma]<br />
* [https://research.nccgroup.com/2022/08/08/implementing-the-castryck-decru-sidh-key-recovery-attack-in-sagemath/ SIDH Key Recovery Attack in SageMath]<br />
* [https://www.sagemath.org/ SageMath]<br />
<br />
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
==VaultProject==<br />
An vielen Stellen werden Credentials für eine Authentisierung oder Ver-/Entschlüsselung benötigt. So können im Institut für Praktika oder Forschung VMs aufgesetzt werden und die jedoch zur Nutzung Passworte oder private SSH-Schlüssel benötigen. Wie können diese vorbereitet und sinnvoll an die berechtigten Nutzer ausgegeben oder verwaltet werden. Wenn ein verschlüsseltes Backup angelegt werden soll, wäre es vielleicht wünschenswert, dass der Nutzer ein Passwort setzt oder Schlüssel generiert. Doch was passiert, wenn der Nutzer dies vergisst? Vielleicht wäre es (zumindest im Sinne der Verfügbarkeit) eine Idee, einen zusätzlichen Weg zur entschlüsselten Wiederherstellung mit vorzusehen? Hier könnte eine Idee eine Wiederherstellung im "virtuellen Mehraugenprinzip für Administratoren" sein, also mehrere Administratoren müssen kooperieren, indem sie Ihre Keyshares zusammenbringen, um in dieser Situation dennoch eine Entschlüsselung des Backups zu ermöglichen. Aus Anwendersicht wünscht man sich natürlich volle Transparenz, also insbesondere im Vorhinein die Information unter welchen Bedingungen eine Entschlüsselung möglich ist.<br />
Ein Startpunkt welcher hinsichtlich seiner Möglichkeiten untersucht werden könnte, wäre "Vault". Versuchen Sie in den zwei Wochen sowohl den Möglichkeiten als auch den potenziellen Risiken eines solchen Ansatzes auf den Grund zu gehen.<br />
<br />
Links:<br />
* [https://www.vaultproject.io/ Vault]<br />
* [https://www.vaultproject.io/downloads Binaries]<br />
* [https://learn.hashicorp.com/collections/vault/getting-started Erste Schritte]<br />
<br />
Mentor: [https://www.informatik.hu-berlin.de/de/forschung/gebiete/sar/people/sombrutz Robert Sombrutzki], [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
<br />
==<span style="background:greenyellow">NTLM Relaying</span>==<br />
[Lea, Ben]<br />
<br />
NTLM (Windows New Technology LAN Manager) ist ein Authentifizierungsprotokoll von Microsoft, welches in den 90er Jahren eingeführt wurde. <br />
NTLM Relaying ist eine Standardklasse von Angriffen, die bei Zugriffen auf das interne Netz möglich ist. Das Grundproblem ist, dass NTLM an sich keinen Schutz vor Relay-Angriffen liefert, daher ist es aus heutiger sicher veraltet und sollte möglichst nicht mehr verwendet werden. Viele ältere Systeme sind jedoch weiterhin auf NTLM angewiesen, so dass NTLM noch immer verwendet wird, um Abwärtskompabilität zu gewährleisten. Daraus lassen sich recht komplexe Angriffsketten bauen (z.B. der PrivExchange Angriff, bei dem das hochprivilegierte Computerkonto des Exchange-Servers weitergeleitet wird), aber auch vergleichsweise einfachere Angriffe sind häufig noch möglich. Angriffe können auf Protokolle wie SMB, HTTP, MSSQL, SMTP, IMAP ausgeführt werden, wobei bspw. via SMB Zugriff auf FileServer gewährt werden kann. <br />
<br />
Die NTLM-Authentifizierung (NetNTLMv1) läuft folgendermaßen ab: <br />
# Negotiate: Der Client sendet eine Anfrage mit Benutzername und Konfigurationsinformationen zum Server<br />
# Challenge: Der Server generiert eine zufällige Challenge (Zufallszahl) und sendet diese an den Client<br />
# Authenticate: Der Client verschlüsselt die Challenge mit seinem Passwort → sendet Response. Der Server schickt das Challenge/Response Paar an den Domain Controller zur Validierung<br />
[[File:NTLM-Handshake.png|600px|rechts|NTLMv2 Response des Clients]]<br />
<br />
Quelle: https://en.hackndo.com/assets/uploads/2020/03/ntlm_challenge_response.png<br />
<br />
[[File:NTLMv2-Response.png|600px|links|NTLMv2 Response des Clients]]<br />
<br />
<br />
Folgende Vorraussetzungen müssen für einen Relay Angriff erfüllt sein: <br />
#Netzwerkzugriff:<br />Angreifer im gleichen Netzwerksegment wie der Client und Server: Man-in-the-middle<br />
#Aktive Authentifizierung:<br />Client muss auf Ressource zugreifen, die NTLM zur Authentifizierung verwendet.<br />
#Konfiguration des Servers:<br />Der Zielserver muss NTLM-Authentifizierung akzeptieren, Signieren darf nicht erforderlich sein<br />
<br />
Potentielle Opfer finden:<br />
Server zu finden, die diese Voraussetzungen erfüllen, ist gar nicht so schwer. Es müssen einfach nur Anfragen an Server geschickt werden, bei denen die Flags richtig gesetzt sind und, falls der Server einverstanden ist mit den Verhandlungen (NTLM-Negotiate SUCCESS), wäre der nächste Schritt die NTLM-Authentifizierung. Diese führt der Angreifer nicht aus, sondern merkt sich den Server-Namen. Somit kann er sich eine Liste mit potentiellen Opfern erstellen.<br />
<br />
Relay-Angriff:<br />
Sind die Vorraussetzung erfüllt so kann ein Angreifer den Datenverkehr auf dem Netzwerk überwachen. Für NTLM-Relaying fängt der Angreifer NTLM-Authentifizierungspakete zwischen einem Client und einem Server ab. Unter anderem durch fehlgeschlagene Suche nach Hostnames kann ein Angreifer in die Man-in-the-Middle Position kommen. Gründe dafür können bspw. Zugriff auf nicht mehr existierende Fileserver, alte Netzwerklaufwerke, Tippfehler im Hostname, inoffizIelle Browser mit Proxy-Autodiscovery oder sonstige fehlerhafte DNS Anfragen sein. Der Router im Netwerk sendet dann eine Anfrage (Broadcast) an alle Netzwerk-Geräte, um zu erfragen ob diese den fehlerhaften Hostname kennen. Das ist der Moment, in dem sich der Angreifer als der angefragte Server ausgeben kann und als dieser antwortet. <br />
Der Angreifer authentifiziert sich bei dem Server seiner Wahl und leitet alle Pakete zwischen Server und Client weiter. Der Client denkt, er authentifiziert sich bei seinem Server (Die NTLM-Inhalte müssen dafür nicht angepasst werden). Der Server authentifiziert den Angreifer, als wäre er der ursprüngliche Client und gewährt dem Angreifer schließlich Zugriff auf Ressourcen.<br />
<br />
[[File:Poisoning.PNG|600px|rechts|Poisoning von Angreifer um an NTLM-Hash des Client zu gelangen.]]<br />
<br />
Es existieren zwei Standard-Tools für Relaying Angriffe:<br />
<br />
* [https://github.com/lgandx/Responder Responder und MultiRelay]<br />
* [https://github.com/SecureAuthCorp/impacket Impacket und NTLMRelayX]<br />
<br />
=== Beispiel: Relay-Angriff mit Responder.py simulieren ===<br />
Ein beispielhafte Durchführung von NTLM-Relaying kann man mit folgendem Setup realisieren: <br />
* VMWare Workstation 17 Player mit 3 virtuelle Maschinen:<br />
*#Client: Windows 10<br />
*#Server: Windows 2012 (mit Domain Controller)<br />
*#Angreifer: Linux Ubuntu<br />
<br />
<br />
[[File:LaborSetup.PNG|600px|rechts|gerahmt|Labor Setup mit 3 virtuellen Maschinen.]]<br />
<br />
<br />
Der Angreifer fungiert in diesem Aufbau zeitgleich als Router, was mittels IPv4-forwarding realisiert wurde. Alle NTLM-Anfragen zwischen Client und Server müssen also automatisch über den Angreifer geschickt werden (ein sehr großer Luxus) und somit ist er bereits in der Man-in-the-middle Position. Versucht der Client nun auf einen shared-Folder des Servers zuzugreifen, kann der Angreifer mittels <code>Responder.py</code> auf die Server-Anfrage antworten, so dass der Client denkt er kommuniziert mit dem Server und seine Credentials preisgibt. Mittels <code>Multirelay.py</code> kann der Angreifer die Credentials direkt an eine Server weiterleiten, auf den er Zugriff erlangen will. MultiRelayX erlaubt das Filtern von weiterzuleitenden Nutzern mittels des Parameters -u, wodurch nach Nutzern mit besonderen Rechten wie "admin" gefiltert werden kann. In den Funktionen <code>ParseSMBHash</code> und <code>ParseHTTPHash</code> aus <code>ResponderNTLM/tools/Multirelay/RelayMultiCore.py</code>, kann die Variable "UserToRelay" so modifiziert werden, dass ebenfalls Wildcards (z.B. -u adm*) abgefragt werden können.<br />
<br />
<br />
[[File:Multirelay.PNG|600px|rechts|gerahmt|Labor Setup mit 3 virtuellen Maschinen.]]<br />
<br />
In der Testumgebung haben wir uns für einen Windows 10 Client und einen Windows Server 2012 entschieden. Um NTLM-Relaying zwischen einem Windows 10 Client und einem Windows Server 2012 simulieren zu können sind einige Grundeinstellungen vorher zu ändern, damit die Voraussetzungen erfüllt sind: <br />
*Client und Server: SMB2 → SMB1 <br />
*Client und Server: SMB Signaturen nicht erforderlich<br />
*Server: “Keine Kerberos-Präauthentifizierung erforderlich”<br />
*Server: NTLM-Authentifizierung möglich<br />
<br />
Um also NTLM-Relaying Angriffe zu unterbinden, müssen "nur" folgende Vorkehrungen getroffen werden:<br />
<br />
- Veraltete, unsichere Systeme weitestgehend deaktivieren<br />
<br />
- "Signierung erforderlich" aktivieren<br />
<br />
Folgendes Problem: <br />
Teure Geräte, die nur alle 10-20 Jahre erneuert werden, werden nur ungern vor ihrem "Lebensende" abgesteckt. Damit diese Systeme weiterhin genutzt werden können, muss also eine Abwärtskompatibilität gewährleistet werden... Eine Signierung mal kurz zu ergänzen ist auch nicht so einfach... <br />
Und selbst wenn die Systeme erneuert werden und neuere Protokolle unterstützen, wird das gleiche Spiel nur wieder widerholt. Von NTLM könnte z.B. auf Kerberos upgegraded werden, jedoch existieren für Kerberos bereits ebenfalls Relaying Angriffe.<br />
Somit müssten Unternehmen alle ihre Systeme auf dem neuesten Stand halten und Alt-Systeme rechtzeitig ersetzen. Da dies viel Zeit und Geld kostet, wird es in der Realität nicht immer praktiziert.<br />
Trotzdem zu gewährleisten, dass das System sicher ist, ist eine schwierige Aufgabe und nicht Teil dieses Projekts.<br />
<br />
<br />
Was tun mit den Hashes nach einem erfolgreichen NTLM-Relay Angriff?<br />
<br />
1. crack-the-hash<br />
Wenn die NTLM-Hashes komprimittiert wurden, kann der Angreifer versuchen, die Passwörter zu erraten. Hierfür kann z.B. Hashcat verwendet werden, um einen Dictionary-Angriff auszuführen. Die Voraussetzung ist natürlich, dass das gewählte Passwort des Clients (oder Admins) schwach genug ist, um über einen Dictionary-Angriff erfolg zu haben.<br />
Um einfach nur an das Passwort eines Clients zu kommen, könnte der Angreifer auch die NTLM-Authentifizierung selber durchführen und die NTLM-Challenge ("Zufallszahl") an den Client senden und danach eine Regenbogen-Tabelle verwenden, um das Passwort des Clients zu erfahren. Auch dieser Angriff ist nur möglich, wenn das Passwort in unserer Regenbogen-Tabelle enthalten ist. Der Angreifer könnte also leer ausgehen.<br />
[[File:hashcat.png|600px|links|NTLMv2 Response des Clients]]<br />
<br />
2. pass-the-hash<br />
Wenn z.B. der Dictionary-Angriff nicht funktioniert hat (oder man sich gar nicht für die Passwörter interessiert, da NTLM-Hashes bei der Authentifizierung gleichwertig sind), kann man auch einfach die NTLM-Hashes verwenden, um sich bei weiteren Servern anzumelden. Ein Client mit Admin-Rechten auf Server A, kann ebenfalls Admin-Rechte auf Server B haben. Und da die Authentifizierung mit dem gleichen NTLM-Hash stattfindet, kann der Angreifer sich bei Server B authentifizieren (ohne je das Passwort gewusst zu haben) und weitere Systeme komprimittieren.<br />
[[File:Pass-the-hash.png|600px|links|NTLMv2 Response des Clients]]<br />
<br />
Quelle: https://en.hackndo.com/assets/uploads/2019/11/pass-the-hash-schema.png<br />
<br />
Es existieren noch weitere Angriffe, die nach dem NTLM-Relay Angriff möglich sind, jedoch sind die Grundzüge in crack-the-hash und pass-the-hash enthalten. Je komplexer das anzugreifende System (unterschiedliche Hierarchien unter den Servern, etc.), desto ausgefallener werden auch die weiteren Angriffe. Dies könnte man sich in späteren Projekten genauer anschauen (jedoch würde dafür unsere Testumgebung zuerst angepasst werden müssen). Ein weiterer Schritt in die gleiche Richtung wäre, Kerberos-Relaying auszuprobieren.<br />
<br />
Anbei unsere Folien: [[File:NTLM-Relaying-Vortrag.pdf]]<br />
<br />
Mentoren: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
==WebAuthn / FIDO2==<br />
WebAuthn ist ein browserübergreifender Standard zur Authentisierung im Web. Die meisten modernen Browser Firefox, Chrome, Safari, Opera unterstützen die Verwendung von Sicherheitstoken zur Authentisierung gegenüber von besuchten Webdiensten ohne die Installation von weiterer Software oder Treibern. Während auch in WebAuthn aufgenommenen Standard FIDO-U2F ursprünglich dazu verwendet wurde, um eine Nutzername/Passwort-basierte Authentisierung durch die Nutzung eines universellen zweiten Faktors gegen automatisierte Angriffe entfernter Angreifer zu härten, ist es mit FIDO2 möglich, sich ganz ohne die Verwendung von Passwörtern zu authentisieren. <br />
<br />
Probieren Sie es aus! Wo kann man sich mit FIDO2 authentisieren? (Interessante Webdienste).<br />
Versuchen Sie, einen Web-Service mit FIDO2-Authentisierung aufzusetzen!<br />
Obwohl WebAuthn/FIDO2 primär zur Nutzung mit Webdiensten entworfen wurde, sind ggf. auch andere Nutzungen (lokales Login, Windows Hello, Linux PAM, SSH, SCP, ...) denkbar. Was geht (schon)?<br />
<br />
*[https://www.w3.org/TR/webauthn/ WebAuthn]<br />
*[https://youtu.be/CkJf8zv1yBw Video]<br />
*[https://fidoalliance.org/fido2/ FIDO2]<br />
*[https://www.yubico.com/product/security-key-by-yubico/ Security Key]<br />
*[https://gist.github.com/z4yx/218116240e2759759b239d16fed787ca WireShark-dissector]<br />
<br />
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
==<span style="background:greenyellow">[[ Elektronische Siegel Urkunden ]]</span>==<br />
[Arturo, Marc]<br />
<br />
Es wäre schön, zum Abschluss eine elektronisch gesiegelte oder unterschriebene Urkunde in den Händen zu halten. Aber wie kann das gehen?<br />
Entwickeln Sie erste Ideen und probieren Sie Dinge aus ...<br />
<br />
Startpunkte/Ideen:<br />
* Acrobat bietet das Unterschreiben an, das geht auch mit eigener Infrastruktur, wenn zuvor ein vertrauenswürdiges Zertifikat importiert ist.<br />
* eIDAS sieht die Verwendung von elektronischen Siegeln vor.<br />
* Können die gesiegelten Informationen auch in einer leicht verifizierbaren Form auf dem Papierdokument aufgebracht werden? ((PDF-Signatur, QR-Code, OCR-Text, Hash-Wert in HEX, URI, Blockchain oder PGP-Signatur)<br />
* Kann ein separates Gerät (z.B. Raspberry Pi, offline) zum Siegeln mit 2-Faktor-Authentisierung für ein Prüfungsbüro bereitgestellt werden?<br />
<br />
Links:<br />
<br />
* BSI Elektronische Signaturen, Siegel und Zeitstempel [https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/eIDAS-Verordnung/Elektronische-Signaturen-Siegel-und-Zeitstempel/elektronische-signaturen-siegel-und-zeitstempel_node.html]<br />
<br />
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
<!--<br />
==DNSSEC@Informatik==<br />
Eigentlich wird schon lange über die sichere Variante von DNS gesprochen. Dennoch ist die HU und auch unser Institut noch nicht über DNS-SEC von außen validierbar. Für die Domain <code>hu-berlin.de</code> hat das CMS schon Grundlagen geschaffen, aber die Einbindung nach oben ist noch nicht erfolgt.<br />
<br />
Erarbeiten Sie ein Konzept und versuchen Sie, exemplarisch einige Schritte umzusetzen. Welche Software wird benötigt, um eine Zone zu signieren. Wie können Schlüssel sicher aufbewahrt werden. Was ist mit dynamischen Einträgen?<br />
<br />
Welche Vorteile bietet DNSSEC bei erfolgreicher Validierung? Mit DANE können auch weitere Felder über DNSSEC ausgeliefert werden.<br />
Denkbar wäre zum Beispiel auch SMTP mithilfe von DANE stärker zu machen oder auch SSH-Fingerprints von Informatikrechnern automatisch ausliefern zu lassen und so Trust-on-First-Use oder das manuelle Vergleichen mit unserer Liste zu überwinden.<br />
<br />
Links:<br />
* [http://heise.de/-2619026 Heise: DNSSEC&DANE]<br />
* [https://www.golem.de/news/zertifikate-dane-und-dnssec-koennten-mehr-sicherheit-bringen-1405-106436-2.html Golem]<br />
* [https://heise.de/-3845855 Heise: aktuell]<br />
* [https://www2.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt70/BT70_IPWIN_DNSSec_Grubert.pdf Erfahrungen Uni Greifswald]<br />
* [https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml Signaturverfahren]<br />
<br />
Mentoren: [https://www.informatik.hu-berlin.de/de/forschung/gebiete/sar/people/sombrutz Robert Sombrutzki], [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
--><br />
<!--<br />
<br />
==DNS-over-HTTPS (DoH)==<br />
Das DNS-Protokoll stammt aus dem letzten Jahrtausend und weder Authentizität noch Vertraulichkeit der übertragenen Daten sind sichergestellt. Wenn man also in einem öffentlichen Netz unterwegs ist, kann ein recht genaues Profil erstellt werden, zu welchen Diensten man sich verbindet.<br />
Daher könnte es eine gute Idee sein, DNS-Anfragen durch HTTPS zu tunneln. Wenn wir dem Endpunkt Trusted Recursive Resolver (TRR) vertrauen, können Interessierte in der Mitte weniger über genutzte Dienste erfahren und insbesondere keine DNS-Antworten unbemerkt modifizieren.<br />
DoH ist bislang (kaum verwunderlich) vorwiegend für Browser angedacht. So unterstützt Firefox DoH ab Version 62 und verspricht eine verbesserte Privatsphäre durch Anwendung dieser Technik. Allerdings müssen die Nutzer dem TRR und insbesondere seine Policy zum Datenschutz stark vertrauen. Steht der TRR in einer anderen geografischen und damit oft juristischen Domain (Mozilla schlägt aktuell Cloudflare 1.1.1.1 vor), so gibt es ggf. für "Bedarfsträger" trotz der Policy rein praktisch die Möglichkeit zum Zugriff auf diese nun zentralisiert gewonnenen Daten. Daher wäre es interessant, einen eigenen DoH-Server zu betreiben und zu nutzen. Versuchen Sie, einen eigenen Server zu etablieren, der idealerweise (wo es möglich ist) bereits DNSSEC zur Beschaffung valider DNS-Antworten verwendet. Kann man diesen Service auch zuhause umsetzen? Könnte er auf einem WLAN-Raouter (OpenWRT oder Fritz!Box) untergebracht werden? <br />
<br />
Links:<br />
* [https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/ Firefox: DoH]<br />
* [https://www.privacy-handbuch.de/handbuch_21w.htm Firefox: Einstellungen]<br />
* [https://www.golem.de/news/dns-over-https-hoster-haelt-doh-im-firefox-fuer-gefaehrlich-1808-135854.html Golem]<br />
* [https://www.heise.de/newsticker/meldung/Google-stellt-Chrome-Nutzer-testweise-auf-DNS-over-HTTPS-um-4520039.html Chrome]<br />
<br />
Mentoren: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
--><br />
<br />
==CSP: Umwandlung von Inline / Internal CSS, JS und DATA in externe Ressourcen==<br />
<br />
Unser Institutswebserver verwendet aus Sicherheitsgründen Content Security Policies, um Angriffe wie CrosssiteScripting oder Ähnliches zu erschweren. Daher ist "unsafe-inline" dort verboten. In Praxis wird zwar die HTML-Seite mit dem potenziell unsicheren Inhalt ausgeliefert, jedoch wird der Client über die CSP-Wünsche des Servers im HTTP-Header informiert.<br />
<pre><br />
curl --head https://www2.informatik.hu-berlin.de/~wolfm/InternalInline.html<br />
Content-Security-Policy: frame-ancestors 'self' https://www.informatik.hu-berlin.de;<br />
X-Frame-Options: SAMEORIGIN<br />
X-Content-Type-Options: nosniff<br />
Content-Security-Policy: default-src 'self'; <br />
</pre><br />
Nach dieser Information ignoriert der Browser die entsprechenden potenziell unsicheren Anteile. Wenn Sie also die [https://www2.informatik.hu-berlin.de/~wolfm/InternalInline.html das Beispiel] in Ihrem Browser aufrufen, sieht es recht schlicht aus und der JavaScript-Code wird nicht interpretiert. Wenn Sie die Seite aber lokal herunterladen und dann über file:./InternalInline.html öffnen, so sind die CSP-Header nicht mehr aktiv und die Seite zeigt ein Bild und hat Farben.<br />
<br />
Aus Sicherheitssicht gibt es gute Gründe gegen eingebettete Styles, Javascript und die Nutzung von DATA. Jedoch erzeugen viele Programme (z.B. MS Office Word) beim HTML-Export HTML, was die Separierung der Anteile nicht konsequent umsetzt. Damit sehen solche Dokumente über den Webserver ausgeliefert eher unerwartet (schlecht) aus.<br />
<br />
Schreiben oder finden Sie ein oder mehrere Skripte, die eine für den Anwender komfortable möglichst Konvertierung ermöglichen, also alle Style-Informationen in CSS-Dateien, alles JavaScript in JS-Dateien und möglichst alle CDATA ggf. expandiert (so sie base64-kodiert sind) und diese in separate Dateien ausgliedert, die CSP-kompatibel in die konvertierte Datei dann regulär eingebunden werden. Optional können die CSS- und JS-Dateien noch kompakter dargestellt werden.<br />
<br />
Links:<br />
* [https://www2.informatik.hu-berlin.de/~wolfm/InternalInline.html Beispiel]<br />
* [https://content-security-policy.com/ CSP]<br />
* [https://www.html-tidy.org/ Tidy]<br />
* [https://www.minifier.org/ CSS, JS Minifier]<br />
<br />
Mentoren: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
==Absicherung KNXD==<br />
Der Zugriff auf KNX-Komponenten im Heimnetzwerk (KNX-Bus) kann mithilfe der Open Source Software knxd vom Netzwerk erfolgen. Sinnvollerweise wird der Dienst so konfiguriert, dass er nur im Heimnetzwerk (also in der Regel in einem privaten Netzwerk) verfügbar ist. Dennoch eröffnet sich damit die Möglichkeit, ohne eine weitere Authentisierung auf KNX-Komponenten zuzugreifen. So könnte ein bösartiges Gerät (Fernseher, Staubsauger, Smarter Lautsprecher) die mit meinem Heim-IP-Netzwerk verbunden sind, diese Möglichkeit ausnutzen, um Zugriff auf beispielsweise die Heizungssteuerung oder Türschlösser zu erlangen.<br />
Wünschenswert wäre hier eine stärkere Authentisierung. <br />
Ideen/Priobleme: <br />
* TLS mit Clientzertifikaten statt TCP-Socket?<br />
* Geht da was mit Wireguard?<br />
* TLS könnte in den Code von knxd integriert werden.<br />
* ETS 5 kann nicht modifiziert werden, geht da was mit stunnel?<br />
* Alternativ könnte man auch versuchen, eine Authentisierung gemäß KNX-IP-Secure Standard umzusetzen, was aber eher für eine Masterarbeit geeignet ist.<br />
<br />
Links:<br />
* [https://github.com/knxd/knxd KNXD (git)]<br />
* [https://www2.knx.org/lu-de/software/ets/herunterladen/index.php ETS (KNX Konfigurationssoftware]<br />
* [[KNXD_Tutorial]]<br />
* [[OpenHAB_Tutorial]]<br />
<br />
Mentoren: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
==Sicherer und schneller SSL/TLS-Handshake==<br />
[Ridvan]<br />
<br />
Nach den Enthüllungen von Edward Snowden haben wir verstanden, warum authentische und vertrauliche Kommunikation wichtig ist. Naiv betrachtet, könnte man denken, es ist ausreichend "s"-Protokolle wie https, imaps, pops ... zu verwenden und alles ist gut. Es ist in Praxis jedoch wesentlich komplexer eine unter dem gegenwärtigen Angreifermodell hinreichend starke SSL/TLS-Verbindung zu erzwingen.<br />
<br />
In der Vergangenheit wurden zahlreiche teils sehr originelle Angriffe auf SSL/TLS entwickelt, die Seitenkanäle oder auch Probleme im Protokollentwurf oder der Implementierung adressieren. Weiterhin ist es wünschenswert, "forward secureness" zu nutzen, da auch nicht für jeden Server der private Schlüssel immer privat bleiben muss.<br />
<br />
Versuchen Sie für einen aktuellen SSL/TLS-Server (z.B. Apache oder NGINX) eine möglichst sichere Konfiguration zu erstellen. Eine gute Orientierung bietet die Technische Richtlinie "BSI TR-02102-2" Behalten Sie dabei auch die Performance für den Handshake im Auge:<br />
* Könnte die Nutzung von ECC hier weiter helfen?<br />
* DH oder ECDH?<br />
* Was muss ein sorgsamer Client alles prüfen, wie kann ihn der Server dabei unterstützen?<br />
** Kann man die gesamte Zertifikatskette auch ECC-signiert bekommen?<br />
** Was ist OCSP-stapling<br />
** Was bringen die einzelnen Maßnahmen?<br />
* Kann Kernel-Level-TLS helfen?<br />
* Wie kann eventuell die Hardwareunterstützung für AES (oder gar ChaCha20) aktiviert werden?<br />
<br />
Links:<br />
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=4 BSI TR-02102-2]<br />
* [https://en.wikipedia.org/wiki/Transport_Layer_Security#Attacks_against_TLS.2FSSL Angriffe auf SSL/TLS]<br />
* [https://www.ssllabs.com/ssltest/ (Web-)Server Test]<br />
* [https://www.digitalocean.com/community/tutorials/how-to-configure-ocsp-stapling-on-apache-and-nginx HOWTO OCSP stampling]<br />
* [https://docs.kernel.org/networking/tls.html Kernel TLS]<br />
<br />
Mentor: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]<br />
<br />
==<span style="background:greenyellow">[[Signal Protocol Post Quantum Security]]</span>==<br />
[Emily]<br />
<br />
Das Signal Protocol ist eines der beliebtesten E2EE-Messaging Protokolle und bietet bemerkenswerte Eigenschaften wie Forward und Future Secrecy. Zwar gab es schon einige Forschung zu den Möglichkeiten, das Protokoll PQS zu machen jedoch beruhten viele Überlegungen auf den nun obsoleten SIKE/SIDH Algorithmus. Vor kurzem hat Signal nun ein Whitepaper zum PQX3DH Protokoll veröffentlich, was den Handshake zwischen zwei Clients quantensicher macht.<br />
<br />
Interessant ist es nun sich diese Protokoll anzuschauen und mit der bisherigen Implementation zu vergleichen. Gibt es auch Möglichkeiten den Double Ratchet Mechanismus gegenüber Quantencomputern zu sichern?<br />
<br />
Links:<br />
* [https://signal.org/docs/specifications/pqxdh/ Whitepaper zu PQX3DH]<br />
* [https://eprint.iacr.org/2021/875.pdf Hybrid Signal protocol for post-quantum email encryption]</div>Wolfm