 Und dann darf ich euch vorstellen, Guido Schmidt und Daniel Fett, die geben heute diesen Talk, es geht um Singlesign-Ordnen im Netz. Und hoffentlich freut ihr euch schon mit uns auf den Talk. Hallo zusammen. Willkommen zum Talk. Es geht um die Sicherheit und die Privatsphäre von modernen Singlesign-Ordnen im Internet. Und Daniel und ich, wir werden nicht nur Angriffe auf O-Out und OpenID Connect präsentieren, sondern auch ein paar Gedanken, die die Analyse dieser Standards betrifft. Also, zunächst mal eine kurze Einführung. Wer sind wir eigentlich? Wir sind Forscher von der Universität Trier, aber bald wechseln wir an die Universität Stuttgart. Und außerdem sind wir die Gründer von Maschinen-Deck, also der Maschinen-Deck Kekerspace in Trier und dem Pie-and-more Raspberry-Veranstalter. Also, wenn euch das Zeug, was wir sonst zu machen interessiert, dann könnt ihr uns über Twitter erreichen. Also, worum geht es bei Singlesign-Ordnen? Worüber reden wir eigentlich? Wahrscheinlich haben alle von euch schon Webseiten wie diese hier gesehen. TripAdvisor zum Beispiel, wo ihr eine ganze Menge von Methoden benutzen könnt, um euch anzumelden. Ihr könnt mit eurem Facebook-Account euch anmelden, mit dem Google-Account. Ihr könnt euch registrieren direkt auf der Herb-Seite mit der E-Mail-Adresse und einem Passwort. Oder ihr könnt in dem Fall auch den Samsung-Account benutzen oder wahrscheinlich mittlerweile noch mehr Systeme. Und wenn ihr auf Lock-in mit Facebook klickt in dem Fall, dann geht es um die Webseite auf. Da müsst ihr dann euer Facebook-Benutzern einmal ein Passwort eingeben. Oder wenn ihr bei Facebook schon angemeldet seid, dann fragt es nur nach Bestätigung. Und das ist also jetzt hier die Situation, die wir uns anschauen. Es gibt zwei verschiedene Teilnehmer, TripAdvisor, das ist die sogenannte Relying-Party. Und Facebook ist in dem Fall der Identity-Provider, also der Provider für die Identität. Und grundsätzlich funktioniert das wie folgt. Ihr geht mit eurem Browser auf die Webseite von der Relying-Party und wollt zum Beispiel RP und dann authentifizierte Identitätsprovider, also in dem Fall Facebook, euch und stellt euch dann einen Token aus, also irgendwie einen String. Und das wird dann an die Relying-Party geschickt. Und die können das dann benutzen, um den Account beim Identitätsprovider zu bestätigen. Und das nennt man dann Autorisation, also die Relying-Party kann das jetzt zum Beispiel benutzen, um auf eurer Facebook-Zeitleiste zu posten oder eure Freundesliste bei Facebook auszulehren. Und außerdem kann die Relying-Party auch irgendeine Art von eindeutigem Benutzer-Ident, also irgendein Benutzer-Identifikation, die eindeutig ist, bekommen. Und das kann er auch benutzen, um zu sehen, dass ihr eingeloggt seid und das ist dann Authentifikation. Also er kann sich dann insbesondere merken, diese Session, eure Session, die gehört dann zu diesem Nutzer, zum Beispiel euren Benutzername bei Facebook. Und das ist das grundsätzliche Prinzip, warum sollten wir das nicht benutzen oder warum sollten wir es benutzen. Und für Benutzer, es ist leicht zu benutzen, es ist bequem, ihr müsst euch nicht merken, welchen Account ihr wo benutzt habt und so weiter, ihr braucht keinen Passwort, ihr klickt einfach auf Login mit Facebook, aber das ist ein Problem für die Privatsphäre, weil Facebook jetzt weiß, wo ihr euch einloggt. Und außerdem ist er auch ein Problem, wenn der Identitätsprovider nicht mehr funktioniert oder heruntergefahren wird. Dann könnt ihr euch in die Accounts nicht mehr anmelden auf der anderen Webseite. Und für die Relying Parties, die müssen natürlich weniger Daten speichern, sie müssen sich die Passwortdatenbanken irgendwie nicht speichern, die können ja auch im Internet landen, sie müssen sich nicht darum kümmern, was passiert, wenn die Leute ihr Passwort vergessen und so weiter, aber sie haben aber auch weniger Kontrolle über die Accounts von ihren Benutzern, denn die Authentifikation liegt jetzt bei dem Identitätsprovider. Und auch hier ist der Identitätsprovider wieder ein Single Point of Failure, also wenn der ausfällt, können sich die Leute nicht mehr einloggen. Für die Identitätsprovider großer Vorteil, sie kriegen mehr Benutzerdaten, also können außerdem auch einen zusätzlichen Dienst anbieten, was vielleicht für die Nutzer interessanter ist, dann diesen Dienst zu benutzen. Und als Nachteil, die müssen jetzt natürlich mehr Nutzerdaten speichern und müssen es auch beschützen. Und außerdem müssen sie zusätzlich diesen Single Sign On Dienst noch betreiben und einrichten. Und was sind das für Single Sign On Systeme? Ich werde euch mal ein paar Beispiele zeigen, die wichtig sind. OOUT 1.0, das ist ein nicht so modernes Single Sign On System, das ist jetzt zehn Jahre alt, hat auch viele Fehler oder Probleme und niemand, also im Wesentlichen benutzt es niemand mehr außer Twitter, Twitter benutzt eine modifizierte Version, die mehr oder weniger die bekannten Probleme repariert, aber allgemein kann man sagen, benutzt OOUT 1.0 nicht. Und dann gibt es OpenID, auch das ist ziemlich alt, neun Jahre alt. Es ist nicht so richtig benutzerfreundlich, der Standard soll super flexibel sein, alle möglichen Leute sollen das benutzen können und alle möglichen Dinge, wo die Entwickler damals dran gedacht haben und das macht es auch extrem schwierig, das richtig zu benutzen. Da passieren einfach sehr viele Dinge. Dinge ändern sich während OpenID schon abläuft, also während eines Durchgangs und es ist einfach nicht so angenehm, das zu benutzen. Also auch bei OpenID benutzt es bitte nicht. Und jetzt gibt es auch modernere Systeme, also zum Beispiel OOUT 2, das wird zum Beispiel bei Lock-in mit Facebook benutzt, das ist komplett inkompatibel mit OOUT 1 und OOUT 2 benutzt sogenannte Bearer Tokens, das alte Protokoll basiert auf Zufallswerten, die hin und her geschoben werden, aber es gibt keine Kryptografie, außer die Transportverschlüsselung, also HTTPS. Und OOUT 2 wird überall benutzt, fast überall, also das populärste dieser Systeme, aber es geht eigentlich nicht um Authentifikation. Also wirklich, dafür ist es eigentlich nicht gebaut. Und wenn man jetzt nach OOUT 2 und Authentifikation googelt, dann landet man nach einer Weile bei diesem Bild. Diese zwei Leute sind Mitglieder der OOUT 2 Working Group. Es geht eigentlich nicht um Authentifikation, nur Autorisation. Trotzdem wird es benutzt in der Praxis für Authentifikation, Facebook zum Beispiel benutzt das ja für Authentifikation. Und das Protokoll ist jetzt fünf Jahre alt. Viele Probleme wurden gefunden, die meisten wurden auch repariert. Wir werden im Anschluss dann auch noch über ein paar von diesen Problemen reden. Also das ist OOUT 2 und dann gibt es auch noch OpenID Connect. OpenID Connect ist relativ neu, das ist erst anderthalb Jahre alt und das ist jetzt Authentifikation, was für seine Technik OOUT benutzt. Also das ist quasi jetzt ein Standard, der sagt, so sollte man OOUT für Authentifikation benutzen. Aber es ändert auch den Standard ein bisschen, deswegen kann man es auch als eigenes Protokoll betrachten. Und obwohl es denselben Namen hat, ist es auch komplett incompatibel mit OpenID. Es hat auch ein paar dynamische Features wie Identity Providererkennung und das bringt uns jetzt zu der großen Verwirrungskarte. Also OOUT 1 und OOUT 2 sind komplett incompatibel und machen beide Autorisationen, wird aber von Facebook auch für Authentifikation benutzt. Insbesondere benutzt es auch OpenID Connect. Und OpenID Connect ist der Nachfolger im Marketing für OpenID, aber ist ebenfalls nicht kompatibel mit OpenID Connect und wird aber zum Beispiel bei Google benutzt, mit Google einloggen. Also das sind die meisten benutzen Singlesign-On-Systeme im Internet. Es gibt auch ein paar andere, zum Beispiel Mozilla Persona von Mozilla. Wie viele von euch haben davon schon mal gehört? Okay, also ich würde sagen vielleicht 5%, mehr oder weniger. Und der Originallname ist BrowserID und die Idee war, dass die E-Mail-Provider die Identitätsprovider werden. Denn klassischerweise bei einer Webseite, wenn ihr euch registriert, die schicken euch E-Mails, wo man dann draufklicken kann, damit man das Passwort zurücksetzen kann und sich einloggen kann. Das heißt, in gewisser Weise ist der E-Mail-Provider schon euer Identitätsprovider. Und Persona ist der erste Singlesign-On-System mit privatsphäre Ziel. Das heißt, in dem Fall sollen die Identitätsanbieter nicht lernen, wo man den Account überall benutzt. Und das wurde von Mozilla entwickelt. Und die erste Idee war, das in den Browsern mit einzubauen, was nie passiert ist. Und deswegen haben sie jetzt eine, also das Ziel war jetzt, eine reine Web-Implementierung zu bauen, nur mit HTML5. Und sie bauen auch Bridges, die dann Richtung OpenID und Oout funktionieren, damit man große Identitätsprovider schon mal hat in dem System. Aber der Ansatz ist fehlgeschlagen. Also er ist interessant, wenn man sich das mal anschauen will, gerade im Hinblick auf Privatsphäre, aber es ist leider fehlgeschlagen. Ja, was gibt es sonst noch so? Darauf habe ich jetzt noch nicht gesprochen und ich übergebe es an Daniel. Ja, worum geht es eigentlich bei dem ganzen Talk? Was wir machen wollen, ist, wir wollen analysieren, ob eben diese Web-Single-Sign-On-Protokolle sicher sind, wenn sie korrekt implementiert sind. Das heißt, wenn wir den Standards folgen und den ganzen Best-Practices folgen, können wir das sicher implementieren. Also in anderen Worten sind die Standards und Protokolle, die wir hier definiert haben, sicher. Der aktuelle Stand der Kunst ist, dass wir eine große Menge an Dokumenten haben, die ein Mechanismus beschreiben, zum Beispiel O-Rof. Und wir haben einen Experten oder eine Gruppe von Experten, die darauf gucken und dann entscheiden, ob das für sie gut aussieht oder nicht. Und dann sagen die irgendwann, dass es sicher, und das ist, wie der aktuelle State of the Art ist. Was wir mit unserer Forschung machen wollen, ist genau das ändern. Und zwar auf eine Art und Weise, die schon in anderen Bereichen in Internet-Sicherheit erfolgreich waren. Wir möchten ein formales Modell von der Webinfrastruktur und der Anwendung erstellen. Und diese Modelle sind natürlich immer unvollständig, aber trotzdem sinnvoll. Wir stellen also diesen Modell, tun sehr viel Arbeit da rein, das schauen wir uns nachher genauer an und können dann einen Sicherheitsbeweis herstellen, sodass wir dann definiert sagen können, ob eben das Protokoll sicher ist. Der schwierige Teil ist hierbei natürlich Punkt zwei. Und wie immer gilt, manche Dinge können wir in unserem Modell nicht abbilden. Was zum Beispiel nicht zu unseren Sachen gehört sind Fishing, Clickjacking, Attacken, einfach dumme Nutzer, also zum Beispiel Fishing-Angriffe. Das sind alles Dinge, die wir in unserem Modell nicht betrachten. Genauso kompromitierte Browser, Datenbanken etc., das betrachten wir nicht. Also, wenn wir also dieses Modell von unserer Web-Anwendung haben, die ist eine der wichtigen Fragen, vielleicht sogar die wichtigste Frage, was ist Sicherheit und was ist Privatsphäre? Was ist also unsere Definition hier? Glücklicherweise können wir das dann definieren, wenn wir ein formales Modell endlich mal haben. Ich werde hier jetzt nicht den ganzen formalen Kramen präsentieren, weil es dann doch etwas langweilig ist. Aber dafür gibt es einen High-Level-Overview über das Ganze. Autofizierung in einem Web-Single-Sign-On-System bedeutet, dass ein Angreifer, der die volle Kontrolle über das Netzwerk hat, sollte den Service, den der Relying-Party bereitstellt, nicht nutzen können. Und das ist eine ziemlich offensichtliche Eigenschaft. Es gibt dann noch eine etwas weniger offensichtliche Eigenschaft, die sagt, dass ein Angreifer nicht in der Lage sein sollte, ein Browser, der sich ehrlich verhält, ein Angreifer soll nicht in der Lage sein, dass ein Browser unter einem Benutzernahme eingeloggt sein soll, den er quasi dem gar nicht gehört. Das nennt man dann Session Fixation oder Session Swapping, dass man also quasi den Benutzernahme unter dem Benutzereingelogtes austauscht. Dann haben wir noch eine weitere Eigenschaft, die wichtig ist, nämlich Session Integrity. Session Integrity bedeutet, dass wenn die Relying-Party unter Alice's Handel mit dem Identity-Provider redet, dass dann Alice explizit gesagt hat, dass sie bei dieser Relying-Party sich anmelden möchte. Das ist Session Integrity. Und die dritte Eigenschaft, die wir haben, ist Privacy. Privacy bedeutet, dass ein böswilliger Identity-Provider nicht in der Lage sein sollte, dass ein Nutzer sich bei einer Relying-Party anmeldet. Das heißt zum Beispiel, wenn Olaf Privacy hätte, dann könnte Facebook nicht feststellen, wo sich die Nutzer anmelden. Es gibt auch noch andere Begriffe von Privacy, die wir aber in unserem Talk hier nicht weiter berücksichtigen werden. Also fangen wir jetzt an mit OAuth 2. Der Test funktioniert. Und es geht los mit einem näheren Blick auf OAuth 2. Und wenn ich OAuth sage, dann meine ich immer OAuth 2, also nicht OAuth 1. Und OAuth 2 ist definiert im Wesentlichen in RFC 6749 und auch in ein paar anderen Dokumenten. Und OAuth selbst hat vier verschiedene Modi, in denen man es ausführen kann. Da gibt es den implizierten Modus, den Autorisationscode-Modus, den Ressourcenbesitzer-Passwort-Authentifizierungsmodus und die Client-Authentifizierungsmodus. Und alle haben eine ganze Menge Optionen. Und von diesen vier Modi sind die ersten zwei, also der Implizite und der mit dem Autorisationscode, sind die häufigsten, die benutzt werden. Also schauen wir uns diese zwei mal genauer an. Also der Implizite-Modus funktioniert wie folgt. Wir haben ein Beispiel mit einer Zufälle, also mit irgendeiner Relying Party und Facebook ist der Identitätsprovider. Das heißt, ich sage, ich möchte bei der Relying Party mich mit Facebook anmelden und dann wird der Browser umgeleitet auf Facebook und Facebook fragt nach den Benutzernamen und so weiter oder will eine Bestätigung, dass du auch wirklich ein dich einloggen willst mit Facebook und daraufhin stellt Facebook ein Zugangstoken aus und leitet den Browser um auf die Relying Party wieder zurück und in der URL ist das Zugangstoken enthalten. Und aus technischen Gründen brauchen wir noch ein paar zusätzliche Gründe, um auf dieses Token zuzugreifen, denn das ist in dem Fragment der URL enthalten und ganz zum Schluss bekommt dann also die Relying Party dieses Access-Token, also dieses Zugangstoken und mit diesem, also ein Zugangstoken ist im Wesentlichen dasselbe, wie in diesem ersten Groben, in dieser ersten Grobenübersicht, die ich vorhin gegeben habe, ist also dasselbe, also so ein Access-Token, also so ein Zugangstoken ist so ein Token, das gibt dem der Relying Party Zugriff auf den Benutzer-Account bei Facebook und jetzt kann die Relying Party eben Datenempfangen von Facebook oder abrufen und kann eben auch den Benutzer-Namen bekommen und damit ist der Benutzer eingelockt und er bekommt einen Browser-Cookie gesetzt und ist jetzt eingelockt. Das ist also der implizierte Modus und dann gibt es eben auch den Autorisationscode-Modus. Hier geht es ganz ähnlich los. Der Benutzer sagt, ja, also ich möchte mit Facebook einloggen, dann wird er umgeleitet auf die Facebook-Webseite, identifiziert sich da und jetzt stellt Issue kein Zugangstoken aus, sondern einen sogenannten Autorisationscode und die Relying Party nimmt dann diesen Autorisationscode und kriegt dafür von Facebook einen Zugangstoken. Also es gibt nochmal einen Zwischenschritt, also mit diesem Autorisationscode gibt es noch einen zusätzlichen Zwischenschritt und dieses Zugangstoten, was er dann bekommt, was die Relying Party bekommt von Facebook, das kann dann benutzt werden, um Dinge im Namen des Nutzers bei Facebook auszuführen oder eben auch um den Nutzer zu autorisieren. Also reden wir mal über ausgewählte Angriffe auf O-Out. Also lass uns zuerst ein bisschen über bekannte Angriffe reden, die sogenannte Cut-and-Paste-Attacke, also Ausschneiden und Einfügen, wo man gewisse Tokens, also zum Beispiel Zugangstoken oder auch den Autorisationscode und es gibt auch ein paar andere Tokens, über die ich noch gar nicht gesprochen habe. Ich habe vorhin ein paar Details weggelassen und diese werden wieder benutzt und zusammengebastelt in eine neue Verbindung und damit wird das System umgangen. Also es gibt eine ganze Menge von diesen Cut-and-Paste-Attacken und die Working Group versucht, also gibt die ganze Zeit Hinweise, wie man diese Angriffe vermeiden kann und ein weiteres Problem ist, wenn man HTPS nicht benutzt, dann hat man völlig verloren, denn jemand, der die Verbindung mitlesen kann, also ein Männende im Mittel, der kann diese Tokens dann abfangen. Also wenn ihr in einem WLAN seid und jemand, der neben euch sitzt, snifft das WLAN, dann weiß der, also weil ihr zum, also ihr benutzt jetzt eben kein HTPS, weil der Entwickler das vergessen hat. Der Entwickler hat vergessen, dass es sowas gibt wie HTPS, dann ist dieses ganze System kaputt. Und wenn ihr euch auf die Cookies verlasst, dann habt ihr auch ein Problem, dann ist es auch total kaputt, denn Cookies werden nicht integriertätsgeprüft, also es ist recht einfach, Cookies in den Browser zu injizieren über HTTP und diese Cookies werden später dann auch über HTPS benutzt. Also Cookies sind auch keine gute Sache, auf die man sich verlassen sollte. Also reden wir mal drüber, über ein paar von diesen Attacken, die wir in unserer Forschung gefunden haben. Also es gibt die 307 Umleitungsattacke, die funktioniert wie folgt. Zunächst machen wir eine ganz normale O-Out-Verbindung und wenn wir in dieser O-Out-Verbindung mal uns genauer anschauen, was hier in Schritt 2 bis 4 passiert, da wird der Benutzer authentiziert, danach wird der Nutzer umgeleitet zurück zu der Relying Party und wenn man sich das jetzt mal genauer anguckt von diesen Anfragen, dann also zuerst gibt es die Anfrage, wo man zum Identitätsprovider geht und sagt hier, also wo man anfängt, die O-Out-Verbindung aufzubauen, man kommt gerade von der Relying Party, klickt auf den ich möchte, gerne mich einloggen button und wird umgeleitet und dann kontaktiert der Browser den Identitätsprovider, zu dem man umgeleitet wurde und der Browser sagt dann, bitte authentifiziere den Nutzer, das ist hier Schritt 2a und dann gibt der Identitätsprovider ein Formular zurück, wo man Benutzernahme und Passwort normalerweise eingeben muss und dann gibt man Benutzernahme und Passwort ein und die werden dann Identitätsprovider geschickt und jetzt, wenn der Identitätsprovider einen wieder umleitet zu der Relying Party, in dem Fall die falsche Methode benutzt für HTTP-Umleitung, nämlich 307 in dem Fall, dann passiert das folgende, der Browser schickt die Benutzernahme und Passwort nochmal ab, und zwar in dem Fall an die Relying Party und wenn die Relying Party jetzt nicht vertrauenswürdig ist, dann hat die Relying Party jetzt euer Benutzernahme und euer Passwort. Und das passiert, wenn der 307 Redirect benutzt wird und glücklicherweise haben wir keinen Identitätsprovider im wirklichen Internet gefunden, der das tatsächlich auch benutzt, aber man kann das natürlich nicht ausschließen, dass es irgendwie eine Implementierung gibt, die diese 307 Methode benutzt. Und wenn man sich den Standard anschaut, wie das definiert ist, dann ist das nicht immer klar, was für eine Umleitungsmethode man da, also welche Details dahinterstehen und die O-Outworking Group hat sich das auch nicht sehr genug überlegt und im Standard steht, da sind nur drinnen benutzt irgendeine Art, irgendeine Methode und es wäre hier sicher sinnvoll gewesen, da dazuzuschreiben, benutzt mal nicht 307, sondern irgendeine andere Methode. Und die nächste Angriff ist die Mix-Up-Attacke, die zeige ich jetzt mal hier im Impliciten-Modus und nur eine Variante davon. Und hier in der Attacke haben wir das folgende Setting, also alle diese Anfragen sind üblicherweise verschlüsselt, aber bei der ersten Anfrage, da können wir nicht sicher sein, denn eine ganze Menge Relying-Partys, also wenn man zu einer Webseite geht, dann geht man da zum Beispiel über HTTP. Und diese erste Information, wo man nur, ich möchte gern Facebook benutzen, da kann man davon ausgehen, dass das häufig eben keine Information ist, die man verschlüsseln müsste. Und diese erste Anfrage geht entsprechend häufig auch unverschlüsselt über das Netz oder wenn man sich andere Angriffe anschaut, wie zum Beispiel TLS-Tripping, also dann kann man eben auch nicht garantieren, dass diese Anfrage hier verschlüsselt ist. Und jetzt, wenn der Angreifer, also der Angreifer sitzt zum Beispiel ganz einfach im selben WLAN-Netzweg wie ihr, zum Beispiel der Typ rechts von euch, der könnte einfach Folgendes machen. Wenn der Browser diese Anfrage an die Relying-Party schickt, lock-in mit Facebook, dann kann er das einfach austauschen. Also er kann zum Beispiel sagen, ja, ich benutze einfach den Identitätsprovider, der vom Angreifer betrieben wird. Man kann eine ganze Menge Optionen haben, eine ganze Menge, und man kann da auch das Ganze ein Stück weit auch dynamisch erweitern, reagierend auf irgendwelche Events. Und jetzt denkt die Relying-Party, ah, okay, dieser Benutzer möchte also den Angreifer als Identitätsprovider benutzen und antwortet den Browser jetzt mit einer Umleitung. Aber der Angreifer sitzt ja immer noch in der Mitte und kann jetzt diese Umleitung austauschen als eine Umleitung zu Facebook. Das heißt, was jetzt passiert ist, man geht ganz normal zu Facebook, kann sein Benutzer einmal an den Passwort, wird umgeleitet, und die Relying-Party kriegt dieses Access-Token und möchte dieses Access-Token benutzen. Und was jetzt passiert ist Folgendes, es wird dieses Access-Token nicht an Facebook schicken, sondern wird es an den Angreifer schicken. Denn es denkt, dass der Angreifer jetzt der Identitätsprovider ist, den der Benutzer benutzt hat. Das heißt, in der Praxis, wenn man das machen möchte, diese Angriff, dann muss man noch ein paar Details beachten. Man muss also, wenn man zum Beispiel Authentifikationen kaputt machen will und nicht Autorisationen, also ich habe in dem Beispiel nur gezeigt, der Benutzer hat das Zugriffstoken und kann dann möglicherweise bei Facebook oder irgendeinem anderen Identitätsprovider dieses Zugriffstoken benutzen. Also es geht ja nicht nur um Facebook, aber um Authentifikationen kaputt zu machen bei der Relying-Party, da muss man noch ein paar zusätzliche Schritte machen. Und es gibt auch ein paar zusätzliche Schritte, über die man sich Gedanken machen, wie zum Beispiel dem Client-Identifikations, also Benutzernahme im Wesentlichen. Und das muss dann, also es ist häufig dasselbe wie Benutzernahme und Passwort. Und bei OpenID Connect, das was zusätzlich zu O-Out benutzt wird, dann muss man auch noch auf ein paar andere Sachen sich Gedanken machen, wie zum Beispiel ein paar Signaturen ausschalten und ein paar Signaturen auszutauschen und so weiter. Aber es ist immer noch möglich, das heißt, wir haben hier einen Angriff auf tatsächlich benutzte Authentifikationsschemas in der wirklichen Welt. Und es gibt eine ganze Menge Webseiten, die sich nicht auf HTTPS verlassen und wo das tatsächlich so funktioniert. Also wir überspringen das jetzt erstmal und reden darüber, wie man das dagegen tun kann. Und was wir vorschlagen, ist ganz einfach, also ein Problem ist in Schritt 3, dass das Zugangstoken einfach nur ein String ist. Also die RelyingParty weiß nicht, von wem dieses Zugangstoken ist. Das heißt, wir müssen da noch ein bisschen Informationen anhängen. Und das ist in dem Fall einfach der Identitätsprovider, der dieses Token ausgestellt hat. Und wenn man diese Informationen mit übergibt, dann kann die RelyingParty diese Attacke leicht detektieren, kann sehen, in Schritt 5 gibt es einen Unterschied zwischen dem Identitätsprovider in Schritt 5 und dem Identitätsprovider in Schritt 1. Und in Schritt 1 soll es der Angreifer sein und in 5 kriegt es die Nachricht, hier gibt es einen Zugangstoken und es ist von Facebook. Und in dem Fall kann man einfach die Verbindung abbrechen, ohne dass der Angriff erfolgreich ist. Also, das ist wie man das umgehen kann. Wir haben über mit der O-Out Working Group geredet beim IETF-Meeting. Die haben uns da eingeladen zu einem quasi Notfall-Meeting. Und wir haben bereit Bescheid gesagt, dass wir das öffentlich machen werden, diese Angriffe. Und im Juni gab es dann einen Sicherheitsworkshop und einen neuen RFC mit diesen Umgehungsmethoden, ist in Vorbereitung und die Working Group war auch sehr daran interessiert, hier eine formale Analyse von O-Out durchzuführen, wie wir sie zum Beispiel machen. Also, um das hier nochmal zusammenzufassen, die Sicherheit von O-Out 2, wenn man diese Umgehungsmaßnahmen alle benutzt, und es gibt keine Implementierungsfehler, dann kann man sagen, was um Sicherheit geht, ist O-Out 2 ziemlich gut. Wir haben einen formellen Beweis in unserem Modell dafür. Aber wenn es um Privatsphäre geht, Privacy geht, dann gibt es keine Privatsphäre, die O-Out 2 in irgendeiner Art und Weise anbietet. Wenn wir dann über Privatsphäre sprechen, haben wir vorher schon Singles, wir haben vorher schon gesagt, es ist ein webbasiertes Singles, ein On-System mit dem expliziten Design-Ziel, das es keine zentrale Autorität gibt, die das verwaltet, und eben mit erhöher Privacy. So, wie funktioniert BrowserID? Schauen wir von der ganzen großen Formation, die wir vorhin schon gesagt haben, es ist ein webbasiertes Singles, ein On-System mit dem expliziten Design-Ziel, dann kommen wir von der ganzen großen Vogelperspektive drauf. In BrowserID ist der MailProvider der IdentityProvider. Das heißt, Alice at MailProvider.com hat einen Account bei MailProvider.com. Und in der ersten Phase tut sie Folgendes, sie geht zum IdentityProvider, also zum MailProvider.com, und erstellt zunächst einen Public Private Key per. Dann sendet sie den Public Key, den sind wir hier auf dem Dokument, zu dem MailProvider, und der MailProvider unterschreibt dieses Dokument. Und das erstellt dann ein sogenanntes User-Zertifikat, also Nutzer-Zertifikat, und dieses Zertifikat wird zurück an Alice geschickt. Nun, in der nächsten Phase, wenn Alice dann tatsächlich sich irgendwo einloggen möchte, erstellt sie ein weiteres Dokument, dass die Identität von der Webseite beinhaltet, wo sie sich einloggen möchte, zum Beispiel Wikipedia. Um das zu machen, signiert sie die Identität von Wikipedia mit ihrem eigenen Private Key, und das erstellt die sogenannte Identity Assertion. Und sie sendet beide Dokumente an Wikipedia, und Wikipedia kann diese beiden Dokumente überprüfen. Das heißt, es muss zuerst den Public Key des MailProviders finden, und kann dann das Nutzer-Zertifikat überprüfen, und die Identity Assertion überprüfen. Und wenn das beides zusammenpasst, dann kann Wikipedia alles als eingeloggt betrachten. Diese Idee ist ziemlich einfach und simpel, und wenn man dann angefangen hat, das alles zu implementieren, mit Standard Browser Features, zusammen mit den ganzen Workarounds für Internet Explorer, kann man dann doch bei einer relativ komplizierten Lösung raus. Hier haben wir also auf der linken Seite Alice's Browser, mit zwei Fenstern, nämlich Emma Wikipedia und dem Login der Dialog, der von einer zentralen Autorität, nämlich persona.org, präsentiert, was wir eigentlich verhindern wollten. Und in diesen Fenstern sind mehrere Iframes, teilweise auch verschachtelt, und auf der richten Seite haben wir die verschiedenen Server von dem Identity Provider, der Authority und so weiter. Die sprechen alle miteinander, mit HTTP-Requests, also Post-Nachrichten, XML-RPC-Requests, und dieses System ist ziemlich kompliziert. Um dem Ganzen noch mal was draufzusetzen, haben Sie sich Folgendes ausgedacht. Manche Nutzer benutzen ja schon Gmail oder Yahoo, und da sollten wir doch irgendein sinnvolles Interface oben draufpacken, dass wir da schon mal ein paar Nutzer haben. Und deswegen haben Sie sogenannte Identity Bridges implementiert, speziell für Gmail und Yahoo, und Sie haben dazu Bridging-Server implementiert, so heißen die, einer Sideshow genannt, und einer für Yahoo BigTent genannt. Der Nutzer autorisiert sich jetzt bei diesen Bridging-Servern mittels OpenID, und der Bridging-Server hat dann wieder ein Interface zu einem Standard-Browser-ID-Interface. Ein Problem hierbei war, dass die OpenID-Entitäten nicht immer E-Mail-Adressen sein müssen, sodass wir quasi ein zusätzliches Attribut einfügen mussten, namens das E-Mail-Attribut. Und nun schauen wir uns an, wie diese Identity Bridges eigentlich funktionieren. Wir gehen da jetzt nicht total ins Detail, wir schauen uns nicht genau an, wie das Personal-Protokoll funktioniert, aber die Identity Bridge ist insofern interessant für die ganzen verschiedenen Attakten, die wir so gefunden haben. In der Identity Bridge passiert das folgende. Auf der linken Seite haben wir LSS Browser und in der Mitte Sideshow und auf der rechten Seite Gmail. Könnte auch Yahoo sein, das ist in dem Fall egal, wir gucken uns jetzt mal Gmail an. Als erstes sendet der Nutzer einen Automationsrequest, das heißt, sie möchte sie einloggen und Sideshow sendet dann ein OpenID-Request zurück, der signiert ist, der das E-Mail-Attribut anfragt. Diesen Request wird dann weitergeleitet an Gmail, der Nutzer muss sich dann wieder da einloggen und dann erstellt Gmail eine OpenID-Assertion, die das signierte E-Mail-Attribut von Alice beinhaltet. Wie ihr sehen könnt, ist das alles in einer grünen Box, das heißt, alles wunderschön signiert. Jetzt gibt Alice das Browser, dieses Dokument wieder zurück an Sideshow und Sideshow guckt sich das überhaupt nicht an, sondern sendet es einfach weiter an Gmail und Gmail guckt sich dann alles, was signiert, ist da drin an und sagt Sideshow wieder zurück, das passt, es ist signiert und es wurde alles von mir signiert. Dann kann Sideshow auf das Dokument draufgucken. Aha, diese E-Mail-Adresse, die E-Mail-Attribut entspricht Alice, also war die das wohl jetzt, sich einloggen wollte und gibt dann eben ein Cookie zurück und Alice ist so eingeloggt, so weit gar nicht so kompliziert. Manche der Attacken, die wir gefunden haben, da war zum Beispiel die erste Attacke Identity Forgery. Das heißt, wir haben quasi wieder das selbe Szenario, aber wir haben nicht Alice Browser auf der linken Seite, sondern den Attacker und der Attacker könnte auch wieder einen Autotvisionsanfrage stellen und Sideshow gibt dann wieder den Open ID-Request zurück an den Angreifer und der Angreifer kann halt die Anfrage natürlich ändern, bevor sie wieder an Gmail geschickt wird und das ist dann immer noch ein valider Open ID-Request. In dem Fall wurde das E-Mail-Attribut entfernt. So, jetzt fragt Gmail den Angreifer nach den Zugangsdaten und der Angreifer gibt, weil er Alice Zugangsdaten, ich hatte einfach seine eigenen Zugangsdaten ein, weil dann eine Open ID-Assertion, die die Zugangsdaten des Angreifers enthält, allerdings ist das Dokument dann halt ohne E-Mail-Adresse und weil eben das E-Mail-Attribut entfernt wurde. Jetzt kann der Angreifer ein neues E-Mail-Attribut zu diesem Dokument hinzufügen, das halt eben komplett arbiträr ausgewählt hat. Das ist natürlich nicht signiert, aber das ist kein Problem, weil das Dokument nach Standard teilweise signiert werden kann und dieses Dokument wird dann weiter an Gmail geleitet und Gmail schaut sich das an, ja, ist ja ein signierter Teil auf diesem Dokument, dann schaue ich mir wohl diesen signierten Teil mal an und dieser signierte Teil beinhaltet natürlich nichts Sinnvolles, aber es ist korrekt signiert und wenn das alles so korrekt ist, dann wird das eben auch an SideShow so zurückgemeldet. So, SideShow guckt sich das jetzt an, schaut sich das Dokument an und sieht, dass da ein E-Mail-Attribut ist und setzt das Cookie und damit hat sich der Angreifer einfach mit einem freien gewählten E-Mail-Attribut eingelockt. Das ist ziemlich schlimm, wie ihr euch sicher vorstellen könnt. Wir haben den Mozilla-Leuten hier zu Bescheid gesagt und sie waren ziemlich schnell darin zu antworten. Da waren wir relativ überrascht. Es war ziemlich tief in der Nacht für die meisten von ihnen, aber sie waren sehr aktiv, als wir das in den Backtracker eingetragen haben und nach 24 Stunden war das ganze Problem behoben. Also, die Reaktion könnte man als ziemlich gut betrachten. Allerdings haben wir uns dann das System noch einmal angeschaut und wir haben einen weiteren Identitätsfälschungsangriff entdeckt. Der funktioniert folgendermaßen. Der Angreifer auf der linken Seite sendet eine Authentifizierungsanfrage an SideShow und bekommt dann wieder ein signiertes E-Mail-Attribut zurück und ändert dieses Mal nichts, sondern sendet einfach genau das an gmail.com. Gmail fragt wieder nach Zugangsdaten. Der Angreifer authentiziert sich mit seinen Zugangsdaten und sendet und Gmail sendet dann die signierte E-Mail-Adresse des Angreifers zurück, wie wir sehen können in dieser grünen Box. Und nun kann der Angreifer eben genau Folgendes tun, kann einfach ein nicht authentifiziertes E-Mail-Attribut dazu packen, also nicht signiertes E-Mail-Attribut dazu packen. Und ihr könnt euch sicher schon vorstellen, was passiert. Die SideShow sendet das weiter an Gmail. Das ist natürlich dann immer noch unsigniert das Attribut. Gmail bestätigt wieder, dass halt alles, was in dem Dokument signiert wurde, korrekt ist. Und SideShow nimmt halt einfach das File-Gmail-Attribut und authentifiziert dann, oder setzt den Lock in Cookie für den entsprechenden Nutzer, den der Attacker gewählt hat. Das war die zweite Identitätsfälschung. Wir haben noch eine weitere gefunden, die aber nicht so spektakulär war. Das war natürlich Authentifizierung. Und wir hatten natürlich auch ein gewisses Auge für Privatsphäre bei der ganzen Sache. Wie ihr euch erinnert, bedeutet Privatsphäre nach unserer Definition, genauer nach der Definition nach Mozilla, dass das Browser-ID-Protokoll niemals Informationen darüber preisgibt, was der Nutzer macht an den Identity-Provider. Idealerweise sollte der Identity-Provider nicht in der Lage sein, zu sagen, wo sich der Nutzer einlockt. Und eben genau das ist kaputt bei OpenID. Wenn der bösartige Identity-Provider rausfinden möchte, ob der Nutzer bei einer bestimmten Relying-Party eingelockt ist oder nicht, kann der bösartige Identity-Provider einen Iframe öffnen mit der Website der Relying-Party und dann passiert das folgende. Normalerweise das normale JavaScript im Browser, das Browser-ID-Support hat, erstellt wieder ein Browser-ID-Iframe und in diesen Browser-ID-Iframe wird noch ein weiterer Iframe erstellt, aber der innere Iframe wird nur erstellt, wenn der User sich bei der Relying-Party schon mal eingelockt hat. So, weil jetzt der äußerste und der innerste Iframe im selben Fenster laufen und deswegen zusammenkollaborieren können und auf dem selben Host laufen und deswegen kommunizieren können, kann der Identity-Provider sehr leicht herausfinden, ob ein Nutzer sich schon mal bei einer Relying-Party eingelockt hat oder nicht. Und dieses Problem kann nicht ohne eine größere Umstellung des Protokolls behoben werden bei Browser-ID. Das heißt, dies kann eigentlich komplett als kaputt betrachtet werden. Wir haben auch noch einige Varianten von diesen Privatspieler-Attacken gefunden, die auf andere Teile hier von abzielen. Aber ja, in der Summe ist Browser-ID sicher, aber also, nachdem wir unsere Vulnerabilities dort gefunden und gefixt haben, wir haben auch formale Methoden genutzt, um zu verifizieren, dass Browser-ID tatsächlich sicher ist. Aber privatsphäremäßig ist Browser-ID komplett kaputt. Das führt uns dann eben zu der Frage, ob wir ein einzelnes Single-Sign-On-System bauen können, dass sowohl Sicherheit als auch Privatsphäre implementiert. Ja, und wir haben uns da lange Gedanken dazu gemacht und haben unser formelles Modell benutzt, um so ein System zu designen. Und dann könnten wir auch dieses formelle Modell benutzen, um zu beweisen, dass diese Eigenschaften tatsächlich auch da sind. Und das grundsätzliche Prinzip sieht wie folgt aus, also es heißt Espresso für ... und wir haben einen Benutzer mit einem Browser, der möchte sich einloggen bei einer gewissen Relying-Party, also zum Beispiel Wikipedia. Und hier haben wir jetzt also dieselbe Idee wie bei Browser-ID. Wir möchten also die E-Mail-Adresse benutzen und den E-Mail-Provider als Identitätsprovider. Das heißt, der Benutzer gibt seine E-Mail-Adresse ein und die Relying-Party hätte jetzt gerne irgendein Beweis, dass diese Identität auch stimmt. Das heißt, der Benutzer geht zu seinem E-Mail-Provider, der in dem Fall auch der Identitätsprovider ist, authentifiziert sich und der Identitätsprovider erzeugt ein Dokument. Das Beweis, dass LSL es ist, dieses Dokument wird dann weitergeleitet und die Relying-Party kann dann überprüfen, ob alles auch stimmt und kann dann eben sagen, ja, der Benutzer ist jetzt eingeloggt. Also schauen wir uns mal genauer an, wie das funktioniert. Also hier haben wir wieder Alice mit ihrem Browser mit dem Fenster von der Relying-Party, also Wikipedia in dem Fall und Alice gibt hier ihre E-Mail-Adresse ein. Die wird an die Relying-Party geschickt und die Relying-Party erzeugt jetzt ein Dokument, dass die Identität der Relying-Party selbst enthält. Also dieses Dokument wird dann verschlüsselt und wir nennen dieses Dokument dann den TAG. Und dieser TAG wird jetzt zusammen mit dem Schlüssel, der für die Verschlüsselung benutzt wird. Also es ist eine symmetrische Entschlüsselung mit einem neuerstellten Schlüssel und wird jetzt an den Browser geschickt. Und der Browser öffnet dann der Espresso-Code ein neues Fenster von dem Identitätsprovider. Das sehen wir an der Domain der E-Mail-Adresse. Und jetzt wird der TAG an dieses Fenster drüber geschickt. Und der Lock-in-Dialog, der sorgt jetzt dafür, dass der Benutzer da sein Passwort eingibt. Und das wird dann zusammen mit dem TAG an den Server geschickt. Und der Server erstellt ein Dokument, das ich ja gerade schon beschrieben habe, auf der letzten Folie. Und dieses Dokument, das nennen wir dann das Benutzer-Zusicherung. Und jetzt haben wir ein Problem. Wir könnten diese Zusicherung einfach an das Wikipedia-Fenster drüber schicken. Aber ich zeige euch gleich, warum das eine schlechte Idee ist. Und was wir stattdessen machen, ist, wir haben einen dritten Teilnehmer hier, den Forwarder, den Weiterleiter, der nur ein einzelnes JavaScript-Datei ausliefert. Und das wird in einem iFrame in diesem Lock-in-Dialog ausgeliefert. Und dieses iFrame kriegt die Benutzer-Zusicherung und den Schlüssel. Und der kann jetzt schauen, wer ist jetzt der Empfänger und schickt dann diese Benutzer-Zusicherung an die Relying-Party. Da wird es dann weitergeleitet an den Server von der Relying-Party. Und da kann man dann gucken, ist das alles korrekt und ist der eingelockt. Und warum brauchen wir jetzt diesen Weiterleiter? Das sieht ja erstmal komisch aus. Also schauen wir mal, was passiert, wenn wir diesen Forwarder nicht haben, diesen Weiterleiter nicht haben. Also nehmen wir mal an, der Benutzer möchte sich bei einer bösartigen Webseite einloggen. Er kontrolliert vom Angreifer, also attacker.com. Und der Angreifer möchte den Benutzer gerne, also sich als der Benutzer ausgeben, bei einer anderen Webseite. Also der Angreifer sagt, hallo, ich bin Alice. Ich möchte mich einloggen. Und Wikipedia zeugt einen Tech. Der Angreifer leitet das einfach weiter an den Benutzer. Und der Benutzer geht zu sein, also das Protokoll geht weiter. Der Benutzer identifiziert sich bei seinem Identitätsprovider. Und jetzt schicken wir den Tech an den Angreifer. Und der Identitätsprovider weiß natürlich nicht, wer der echte Empfänger ist. Denn wir wollen ja, dass die Privatsphäre gewahrt bleibt. Und dann geht es einfach durch. Damit hat der Angreifer das Benutzer-Zertifikat, also die Benutzerzusicherung, die User Assertion. Und der kann es einfach weiterleiten an Wikipedia. Und damit ist der Angreifer für Wikipedia Alice. Und das ist natürlich schlecht. Das heißt, wir brauchen ein Mechanismus, der verhindert, dass diese Benutzerzusicherung an eine beliebige dritte Partei weitergeleitet wird. Und wie machen wir das? Das ist genau das, was dieser Vorborder macht. Also ihr könnt euch vorstellen, der Vorborder ist möglicherweise auch bösartig. Aber, ja gut, also vielleicht reden wir gleich drüber. Also warten wir kurz mal. Also der Vorborder bekommt diese Benutzerzusicherung und er bekriegt diesen Schlüssel, um diesen Tag zu entschlüsseln. Und jetzt kann er dem Browser sagen, schick mal eine Postnachricht, aber nur an ein Wikipedia-Fenster. Das heißt, der Browser prüft jetzt, ist Empfänger tatsächlich ein Wikipedia-Fenster und wenn nicht, dann geht das eben nicht durch. Das verhindert eben, dass diese Benutzerzusicherung da an irgendein anderns rausgegeben wird. Und jetzt kann man sagen, naja, der Weiterleiter ist ja vielleicht auch bösartig und gibt einfach ein anderes Skript raus, was böse Dinge macht. Also zum Beispiel alle Texts an den, direkt an den Attacker. Aber wir können über Sub-Resource Integrity sicherstellen, dass das ein sehr spezielles Skript ist. Also in diesem Browser-Fenster darf nur genau dieser Code rerlaufen. Und in dem Fall kann dann der Weiterleiter keinen beliebigen oder bösartigen Code in diesem Iframe einfügen. Und es gibt außerdem auch keine Informationen, die der Browser wieder an den Vorwörter weitergibt. Also um das mal zusammenzufassen, das ist das Espresso-Protokoll. Es stellt Privatsphäre sicher und man kann sicher sich authentifizieren. Es verlässt sich auf HTML5 und wir haben formelle Beweise, dass alle diese Eigenschaften auch tatsächlich auch wahr sind. Und ihr könnt euch eine Demo dazu angucken auf Espresso.me. Okay, was nehmen wir dann hier von mit? Was, was quasi die Zusammenfassung des Talks. Zunächst ist, ja, haben wir die meiste Zeit eigentlich über ORF2 und dementsprechend, also und dann auch über OpenID Connect geredet. Wir haben formal bewiesen, dass ORF2 und OpenID Connect korrekt sind und sicher sind. Und dass die Protokolle grundsätzlich okay sind, solange man halt damit okay ist, dass eben diese Protokolle keine Privatsphäre bieten. Nach unserer Definition von Privatsphäre. Bezüglich ORF1.0 und OpenID können wir uns sicher sein, dass sie eigentlich als deprecated Market sind und nicht benutzt werden sollten. BrowserID und Mozilla Persona sind tot und hat eine kaputte Privatsphäre-Garantie. Und Espresso bietet uns eben beide Features, also Privacy als auch Security. Und wie wir gesehen haben, nutzt es halt native ATML 5 Features, ist modern, formal bewiesen und allerdings derzeit nur ein Proof-of-Konzept. Ja, deswegen an die Entwickler gilt, dass ihr immer Libraries benutzen solltet, soweit es möglich ist, beispielsweise Pi OpenID Connect sollte genutzt werden. Außerdem, mit einem Blick auf RFCs sind meistens relativ hart zu lesen und oft über mehrere RFCs verteilt, oft auch nicht klar formuliert und auch nicht immer up to date. Aber sie sind immer noch eine wichtige Referenz und ich denke, dass es wichtig ist, dass man auch mal in die RFCs schauen sollte. Ja, vielen Dank für eure Aufmerksamkeit. Falls ihr mit uns sprechen wollt, kommt zur Maschinen-Deck-Assembly in Halle 3 oder trefft uns am nächsten Pi & More-Event, ein shameless Block an dieser Stelle, am 14. Januar in Krefeld oder an der Uni Stuttgart ab Januar. Vielen Dank. Wir haben noch 8 Minuten für Fragen. Welche Fragen kommen aus dem Internet? Das Internet hat zwei Fragen. In dem Diagramm habt ihr gezeigt, warum folgt die Authentifizierung der Autorisierung? Sollte das nicht andersrum sein? Es wird jetzt also darum gebeten, die Frage nochmal zu wiederholen. In dem Diagramm, das ihr auf einem der ersten Folgen gezeigt habt, also das, das man jetzt sieht, folgt Authentifizierung auf Autorisierung und nicht andersrum. Sollte es normalerweise nicht andersrum sein? Na gut, also das sind zwei Konzepte, die in gewisser Weise orthogonal zueinander sind. Das heißt, ihr könnt also entweder mit Authentifikationen anfangen, um sicher zu sein, dass der Benutzer tatsächlich er ist, was er ist, was er ist. Man kann im Namen des Benutzers auf die Facebook Timeline posten oder so, aber wenn es um Authentifikationen geht, dann braucht man eine Benutzer-ID und das benutzt im Wesentlichen diesen Autorisationsmechanismus. Also man wird zuerst autorisiert, diese Benutzer-ID zu empfangen und die benutzt man dann für Authentifikation. Fragen aus dem Raum? Für das Espresso-Protokoll habt ihr ja gesagt, dass man, dass die vorwolligen Party tatsächlich überprüfen muss, ob das Zertifikat von Wikipedia ist und nicht von taker.com. Aber könnte man denn diese Überprüfung nicht einfach selber machen? Also ihr meint, wir zeigen irgendwas dem Nutzer und der Nutzer akzeptiert es dann oder lehnt es ab in dem Sinne? Oder sie hat die Challenge, die von ihrem E-Mail-Provider-Signal wieder unter den Schlüssel von Wikipedia seit Identität so. Eigentlich könnte sie also das selber überprüfen. Ja, also prinzipiell schon. Also du meinst jetzt, der Nutzer könnte das überprüfen. Ja, der Nutzer könnte das natürlich überprüfen. Und wir können natürlich den Benutzer dann fragen, wo wolltest du wirklich bei Wikipedia kommen oder attacker.com einloggen. Aber wir wissen auch, dass Nutzer einfach schlecht sind, Entscheidungen zu treffen. Hallo, danke für den interessanten Talk. Ich möchte eine Anmerkung machen, dass Nutzer, dass etwas unfair ist, Nutzer als dumm zu betrachten, dass sie auf Fishing-Attacken oder Ähnliches hineinfallen. Und wenn man ein 4K-Monitor benötigt, um zu sehen, dass da irgendwo Zeichen von Fishing erkennbar sind, dann ist es nicht unbedingt ein schuldes Nutzer. Ja, das ist richtig. Und manchmal kann man es halt auch überhaupt nicht sehen. Also insofern ja. Thank you. Questions from down there? Sorry. Questions? Ihr habt über formale Verifikationen von sowohl ORF als auch eurem Protokoll gesprochen. Mich würde interessieren, welches Programm, welches Software, welche Methoden ihr genutzt habt, um diese formale Verifikation zu betreiben. Und außerdem, ihr habt nur ein Subset von ORF verifiziert. Also fangen wir mal mit der zweiten Frage an. Und was ORF angeht, haben wir wirklich versucht, möglichst viele Optionen, die im Standard auch drin waren, mit zu prüfen. ORF ist ein relativ lockerer Standard. Also es gibt viele Optionen und viele Dinge, die man machen kann. Ein paar Dinge mussten wir ausschließen und man muss alle Optionen, die ORF auch anbietet, auch mit eingebunden. Und es gibt auch einen sehr detaillierten Aufschrieb, den wir gemacht haben, die wir, also Optionen, die wir ausgeschnitten haben, die wir nicht benutzt haben und die wir benutzt haben. Da steht das alles drin. Und jetzt zum ersten Teil der Frage. Unser Modell ist ein Manueller-Ansatz. Also wir machen unsere Beweise auf Papier, auf Papier. Wir schränken die einen immer ein Stück weit ein. Und das gab, also im Wesentlichen zwei Modelle, die es schon gab, Formale Webmodelle in dem selben Bereich, in dem wir auch arbeiten. Aber die haben beide ein Modelchecker benutzt. Also zwei verschiedene Alloy war der zweite. Und bei beiden wurde man eingeschränkt durch diese Möglichkeiten, die man in diesem Tool hat. Und was wir also machen wollten, war genau andersrum. Wir wollten ein manuelles Modell bauen, das sehr genau das Web abbildet, sehr umfangreich. Und dann als zweiten Schritt, als da arbeiten wir jetzt dran, ist dieses Modell in irgendeinen Tool mit zu integrieren. Vielen Dank. Fragen aus dem Internet? Ich habe mich gefragt, ob ihr über Indios informiert seid. Und was ihr über die Idee denkt, dass man Domain-Namen statt E-Mail-Adressen als Nutzer Identifier genutzt. Ja, die Frage soll noch mal lauter wiederholt werden. Neben Indios wird auch nach Realm-Meos gefragt. Also diese beiden Systeme haben wir uns nicht angeschaut. Die Frage bezüglich des Vorworders. So weit ich es verstehe, wird der Vorworder genutzt in einem eigenen Iframe, um den IDP daran zu hindern, Kontrolle über die konkrete Anwendung zu bekommen. Aber was ist, wenn der eigenen Identity-Provider und der Vorworder kooperieren? Ja, das würde die Privatsphäre tatsächlich kaputt machen. Wenn diese zwei zusammenarbeiten, dann ist da diese Zusicherung kaputt. Das heißt, wir haben jetzt die Details nicht, also wir haben nicht die letzten Details gezeigt. Das ist wirklich schwer, das zu verhindern. In Espresso wird die Relying-Party entscheiden können, welcher Vorworder, also welcher Weiterleitungsserver da benutzt werden soll. Und der Relying-Party benutzt dann im Zweifel einen Vorworder, den man vertraut. Und das ist in dem Fall die Gegensmaßnahme. Aber wenn die zwei zusammenarbeiten, dann habt ihr tatsächlich verloren. Und ich denke, es ist auch wirklich wichtig, Ihnen zuzufügen, dass das Weiterleiter so eine halb vertrauenswürdige Teilnehmer ist. Also wir können auf der einen Seite sicherstellen, dass es den richtigen Code benutzt, aber der Identity-Provider muss das sicherstellen natürlich. Aber andererseits gibt es natürlich auch Side-Channels. Also Timing zum Beispiel. Also wenn ihr, ihr könntet zum Beispiel prüfen, welche IP-Adresse greift gleichzeitig auf den Identity-Provider und auf das Weiterleitungsserver zu. Und das bedeutet natürlich, es gibt ein paar Side-Channels und dieses Risiko, das müssen wir minimieren und das wollen wir dadurch machen, dass wir eine Menge von vertrauenswürdigen Weiterleitungsservern anbieten. Die könnten zum Beispiel angeboten werden von, zum Beispiel Mozilla oder der EFF. So dass man eine Menge von Weiterleitungsservern hat, die, wo man sich einen aussuchen kann und hoffentlich nimmt ja dann vertrauenswürdig. Dann auch herzlichen Dank von uns hier aus der Übersetzungskabine.