Bachelor-Seminar: Netz- und Datensicherheit. Thema: BrowserID

Transkript

1 Bachelor-Seminar: Netz- und Datensicherheit Thema: BrowserID Lehrstuhl für Netz- und Datensicherheit Ruhr-Universität Bochum Autor: Stefan Hausotte Stand: 13. Februar 2012 Version: 0.1

2 Inhaltsverzeichnis Inhaltsverzeichnis 1 Identifizierung bei einem Webservice Single-Sign-On Systeme Identity Systeme Mozilla BrowserID BrowserID Was ist BrowserID? Voraussetzungen, um BrowserID zu nutzen Identitätsbestätigung durch BrowserID Erstellen eines BrowserID Accounts Identitätsbeweis - Primary Authority Identitätsbeweis - Secondary Authority Anmelden bei einem Webservice Protokollteilnehmer User Primary Authority Secondary Authority Relying Party Datenformate Assertion Zertifikat JWT Beispiel Sicherheit von BrowserID Verfügbarkeit Verbindungssicherheit Zertifikate Secondary Authorities Web-Angriffe Zusammenfassung 18 4 Quellenangaben 19 Bachelor-Seminar: BrowserID Februar 2012

3 1 Identifizierung bei einem Webservice 1 Identifizierung bei einem Webservice Heute ist es üblich, dass Benutzer mehrere Webservices nutzen. Als Beispiele seien hier ein Mailprovider oder ein Forum genannt. Damit der Webservice weiß, um welchen Benutzer es sich handelt, ist eine Identifizierung von Nöten. Auf der anderen Seite möchte auch der Benutzer nicht, dass jeder seine Daten einsehen kann, weswegen die Identifizierung mit einem nur ihm bekannten Geheimnis verbunden sein sollte. Das meist eingesetzte System im Internet dafür ist das Benutzername - Passwort System. Um so mehr Webservices ein Benutzer nutzt, um so mehr Benutzername/Passwort-Kombinationen benötigt er. Alle Kombinationen und der dazugehörige Webservice müssen vom Benutzer in irgendeiner Weise aufbewahrt werden. Dies kann durch Merken bei wenigen Kombinationen, durch manuelles Aufschreiben oder einen Passwortmanager passieren. 1.1 Single-Sign-On Systeme Single-Sign-On Systeme (im Folgenden: SSO) gehen einen anderen Weg. Hier wird versucht, das Login zu zentralisieren. Ein Benutzer soll sich nicht mehr bei jedem Webservice mit seiner Benutzername/Passwort- Kombination anmelden, sondern nur einmal bei einer SSO-Autorität. Diese Autorität übernimmt dann das Login bei allen anderen Webservices, die dieses Verfahren unterstützen. Als Beispiel sei hier das Google-Login genannt. Einmal bei Google angemeldet, gilt diese Anmeldung in allen Bereichen, wie , Kalender etc. aber auch bei völlig anderen Seiten wie Youtube. 1.2 Identity Systeme Identity-Systeme sind eine Unterart von Single-Sign-On Systemen. Ein Identity-System unterscheidet sich von einem SSO System besonders in einem Punkt. Anstatt das Login für den Benutzer zu übernehmen, stellt eine dritte vertrauenswürdige Instanz lediglich die Identität des Benutzers sicher fest. Mit dieser bestätigten Identität kann der Benutzer sich dann bei den Webservices anmelden. Damit reduziert er die Menge an Benutzername/Passwort Kombinationen. Der Vorteil gegenüber einem SSO System liegt besonders darin, dass Identity-Systeme flexibler sind. Da ausschließlich die Identität sichergestellt wird, kann jeder Webservice weitere Sicherheitsmaßnahmen einbauen. Es spielt dabei keine Rolle, ob diese durch ein weiteres Passwort, biometrisch oder ein Zertifikat verwirklicht werden. Ein solches Identity System soll im Folgenden betrachtet werden. Bachelor-Seminar: BrowserID Februar 2012

4 1 Identifizierung bei einem Webservice Mozilla BrowserID Mozilla BrowserID stellt ein solches Identity-System dar. Es soll als universeller Loginmanager genutzt werden, so dass sich ein Benutzer mit nur einem Klick bei einem Webservice anmelden kann. BrowserID wurde 2011 von Mozilla offiziell vorgestellt und erfährt noch keine breite Unterstützung. In dieser Seminararbeit soll die Funktionsweise und die dahinter liegenden Mechanismen von BrowserID untersucht werden. Was BrowserID kann, wird ebenso untersucht wie die Sicherheit des neuen Systems. Angemerkt sei, dass BrowserID noch nicht vollständig fertig ist. Es wird noch über eine Reihe Veränderungen diskutiert, z.b. was die verwendeten kryptografischen Verfahren angeht oder den Umgang mit Phishing. Bachelor-Seminar: BrowserID Februar 2012

5 2 BrowserID 2.1 Was ist BrowserID? BrowserID kann die Identität eines Benutzers bei einem Webservice bestätigen. Durch diese Bestätigung erhält der Benutzer Zugriff auf den Webservice. Im Normalfall sind keine weiteren Sicherheitsmechanismen vorgesehen, obwohl diese optional in jeglicher Weise genutzt werden können. Mozillas BrowserID macht sich zunutze, dass Webservices oft die adresse eines Benutzers zu dessen Identifizierung nutzten. BrowserID übernimmt dieses Konzept und stellt die adresse als Identifikationsmerkmal in den Mittelpunkt des Systems. Der Benutzer muss sich einmal seine adresse als zu ihm gehörig bestätigen lassen, danach kann er diese als Identifikation mit den Webservices, die BrowserID implementiert haben, nutzen. Diese Arbeit beruht auf den Quellen [lloyd] und [ars] welche in diesem Dokument durchgehend verwendet wurden. Abbildung 1: Login mit BrowserID [brwid] Bachelor-Seminar: BrowserID Februar 2012

6 2.1.1 Voraussetzungen, um BrowserID zu nutzen BrowserID läuft vollständig in JavaScript ab. Dadurch kann das System auf allen modernen Browsern genutzt werden. Es spielt dabei keine Rolle, ob es sich um einen PC, Smartphone oder ein sonstiges Gerät handelt. Wichtig ist nur die JavaScript Unterstützung im Browser. Von Mozilla geplant ist eine Integration in den Browser selbst. In diesem Fall würde dann sogar reines HTML5 ausreichen, um mit BrowserID zu arbeiten. Da diese Implementierung bisher noch nicht existiert, liegt der Fokus dieser Arbeit auf der JavaScript Implementierung. Auf der Serverseite reicht ebenfalls ein Script in beliebiger Sprache, um mit BrowserID zu arbeiten. Allerdings muss der Server SSL/TLS unterstützen, da die Vertraulichkeit der übertragenen Daten nicht durch BrowserID gesichert ist. 2.2 Identitätsbestätigung durch BrowserID BrowserID beruht auf benutzerseitigen Zertifikaten. Eine vertrauenswürdige Instanz erstellt dem Benutzer ein Zertifikat über den Besitz einer adresse, wenn dieser beweisen konnte, dass die Adresse wirklich ihm gehört. Wie das funktioniert, wird im Folgenden gezeigt Erstellen eines BrowserID Accounts Der zentrale Punkt, um an ein Zertifikat über den Besitz einer adresse zu kommen, ist zu beweisen, dass diese einem auch gehört. Dazu gibt es zwei Möglichkeiten, wobei die erste, die von Mozilla präferierte ist. Die zweite Möglichkeit stellt lediglich eine Zwischenlösung dar. Beide Möglichkeiten werden im Folgenden vorgestellt Identitätsbeweis - Primary Authority Im Optimalfall unterstützt der provider (Primary Authority) des Benutzers BrowserID. Wenn dies der Fall ist, beweist die Tatsache, dass der Benutzer in der Lage ist, sich mit seiner adresse beim provider einzuloggen, dass die adresse ihm auch gehört. Ist dies so, kann der E- Mailprovider dem Benutzer ein Zertifikat über den Besitz der adresse ausstellen. Dieses Zertifikat speichert der Benutzer in seinem Browser. Angemerkt sei hier, dass nichts dagegen spricht, mehrere Zertifikate für eine adresse zu besitzen. Auf diese Weise muss ein Zertifikat nicht von Browser A nach Browser B übertragen werden, sondern es wird einfach ein Neues erstellt. Zum Erlangen eines Zertifikats werden folgende Schritte benötigt: Bachelor-Seminar: BrowserID Februar 2012

7 1. Login beim provider (Beweis über Besitz der adresse). 2. Der Benutzer erstellt ein Key-Pair (Public-Key und Private-Key). 3. Der Public-Key wird an den provider gesendet. 4. Der provider erstellt ein Zertifikat über den Public-Key und die adresse und danach signiert er dieses mit seinem eigenen Private-Key. 5. Der provider sendet das Zertifikat an den Benutzer, welcher dieses im Browser speichert. Abbildung 2: Erlangen eines Zertifikats, Primary Authority Identitätsbeweis - Secondary Authority Sollte der provider des Benutzers kein BrowserID unterstützen, kann kein Zertifikat über den Besitz der adresse von diesem ausgestellt werden. In diesem Fall wird die Verifizierung der E- Mailadresse über eine dritte vertrauenswürdige Instanz (Secondary Authority) vollzogen. Dazu sind folgende Schritte notwendig: 1. Der Benutzer gibt eine seiner adressen bei der Secondary Authority an. 2. Die Secondary Authority speichert ein Cookie im Browser des Benutzers. 3. Danach sendet die Secondary Authority eine an die angegebene adresse, welche einen neu generierten Link enthält. 4. Der Benutzer erhält diese . Da er in der Lage ist, die abzurufen, muss er auch Besitzer der adresse sein. 5. Dies teilt der Benutzer der Secondary Authority mit, indem er den Link in der öffnet und so den Cookie sendet. 6. Jetzt erstellt der Benutzer sich ein Key Pair aus Public und Private-Key. 7. Den Public-Key sendet er an die Secondary Authority. Bachelor-Seminar: BrowserID Februar 2012

8 8. Die Secondary Authority erstellt ein Zertifikat über den Public-Key und die adresse und signiert dieses mit ihrem eigenen Private-Key. 9. Das Zertifikat wird an den Benutzer gesendet, welcher dieses in seinem Browser speichert. Abbildung 3: Erlangen eines Zertifikats, Option Anmelden bei einem Webservice Wenn der Benutzer sich mit seiner verifizierten adresse bei einem Webservice anmelden will, so muss er bloß auf den Sign-In Button klicken und eine seiner adressen, für die er ein gültiges Zertifikat besitzt auswählen. Im Hintergrund laufen dabei folgende Schritte ab: 1. Benutzer besucht gewünschte Webseite. 2. Der Webservice (Relying Party) fragt nach der adresse. 3. Der Benutzer erstellt eine Assertion, mit der er behauptet, Inhaber der adresse zu sein. Die Assertion unterschreibt der Benutzer mit seinem Private-Key. 4. Assertion und Zertifikat sendet der Benutzer an den Webservice. 5. Der Webservice extrahiert den Zertifikatsaussteller aus der Assertion und fragt diesen nach seinem Public-Key. 6. Der Zertifikatsaussteller (Primary/Secondary Authority) sendet ihren Public-Key an den Webservice. 7. Der Webservice überprüft mit dem erhaltenen Public-Key die Korrektheit des vom Benutzer erhaltenen Zertifikats und damit der Assertion. Je nach Ausgang der Überprüfung kann der Benutzer zugelassen werden oder nicht. Bachelor-Seminar: BrowserID Februar 2012

9 Abbildung 4: Anmeldung bei einem Webservice mit BrowserID Hier sei nochmal angemerkt, dass der Benutzer mehrere adressen für BrowserID benutzen kann. Auf diese Weise kann sich der Benutzer mit unterschiedlichen, ihm zuzuordnenden Identitäten bei einem Webservice anmelden. Der Webservice erhält dabei als Information nur die adresse und keine weiteren persönlichen Daten über den Benutzer. 2.4 Protokollteilnehmer In diesem Teil der Seminararbeit werden die Protokollteilnehmer genauer betrachtet. Es werden die Funktionen und Anforderungen an diese dargestellt User Der Benutzer (User) stellt die initiierende Partei in einem Protokollverlauf dar. Seine Aufgabe ist es, sich mit seiner adresse bei einer Primary oder Secondary Authority zu melden und den Besitz der adresse zu beweisen. Zudem erstellt er ein Key Pair, von welchem der Public-Key zusammen mit der adresse von der Authority signiert wird. Der Benutzer kann mehrere adressen mit jeweils mehreren dazugehörigen Zertifikaten besitzen. Dies ist wichtig, da sonst ein Austausch der Zertifikate zwischen Browser, z.b. auf dem PC und dem Handy, nötig wäre. Zu den Aufgaben des Benutzer gehört es bei einer Anmeldung bei einem Webservice (Relying Party), eine adresse mit gültigem Zertifikat zu wählen und diese an den Webservice zu senden. Bachelor-Seminar: BrowserID Februar 2012

10 2.4.2 Primary Authority Die Aufgabe der Primary Authority ist es, den Besitz der adresse eines Benutzer sicher festzustellen. Da die Primary Authority i.d.r. der provider ist, ist durch ein Einloggen des Benutzers bei dem service der Besitz der adresse bewiesen. Wenn sichergestellt ist, dass die E- Mailadresse dem Benutzer gehört, so wird diesem sein Public-Key zusammen mit der adresse unterschrieben. Dieses Zertifikat wird an den Benutzer gesendet, damit dieser es in seinem Browser speichern kann. Wenn ein Benutzer sich bei einer Relying Party damit anmeldet, so ist es die Aufgabe der Primary Authority, der Relying Party den eigenen Public-Key zur Verfügung zu stellen, damit diese die Korrektheit des Benutzerzertifikats prüfen kann. Wenn der Benutzer sich bei einer Relying Party anmeldet, erhält die Primary Authority keine weiteren Informationen über den Benutzer. Auf diese Weise ist ausgeschlossen, dass bei einer Primary Authority gespeichert wird, wann welcher Benutzer sich wo und mit welcher adresse eingeloggt hat Secondary Authority Die Aufgaben der Secondary Authority decken sich mit der einer Primary Authority. Der Unterschied besteht lediglich im Kontext des Beweises einer Zugehörigkeit einer adresse zu einem Benutzer. Bei der Secondary Authority wird davon ausgegangen, dass eine Registrierung über eine Primary Authority nicht möglich oder nicht gewollt war. In diesem Fall verifiziert die Secondary Authority die adresse und stellt das Zertifikat aus Relying Party Die Relying Party ist i.d.r. der Webservice bei dem sich der Benutzer mit BrowserID anmelden möchte. Die Relying Party stellt mit JavaScript die Möglichkeit zum Einloggen per BrowserID zur Verfügung sowie eine Auswahlmöglichkeit an adressen. Wenn der Benutzer eine Assertion an die Relying Party gesendet hat, extrahiert diese den Zertifikatsaussteller, also eine Primay oder Secondary Authority und fragt diese nach ihrem Public-Key mit dem das Benutzerzertifikat unterschrieben wurde. Danach verifiziert die Relying Party die Korrektheit der Assertion. Ist diese gegeben, ist der Benutzer identifiziert. Es steht der Relying Party frei, BrowserID mit weiteren Loginmöglichkeiten zu kombinieren , auf Seite 7 Bachelor-Seminar: BrowserID Februar 2012

11 2.5 Datenformate Da BrowserID eine JavaScript-Implementierung ist, ist es sinnvoll, ein mit JavaScript einfach zu bearbeitendes Format zu wählen. Mozilla hat sich an dieser Stelle für JSON (JavaScript Object Notation) entschieden. Eine besondere Form von JSON ist JWT (JSON Web Token), welches einen Standard für signierte JSON Objekte darstellt. Dies ermöglicht flexible Funktionalität. So kann BrowserID in der Zukunft erweitert werden, da nur das JSON Objekt erweitert werden muss. Aufgrund seiner kleinen Größe ist das JSON Objekt sparsam bei der Speicherausnutzung und der zu übertragenden Datenmenge Assertion Die Assertion stellt die Behauptung dar, dass eine adresse dem Benutzer gehört. Die Assertion wird von dem Benutzer an die Relying Party gesendet, welche diese auf Korrektheit überprüft. Sie besteht aus folgenden Teilen: 1. Audience: Gibt die Relying Party an, für die die Assertion bestimmt ist wie z.b valid until: Gibt eine Gültigkeitsdauer der Assertion an. 3. issuer: Der Aussteller des Zertifikats. Dieser ist wichtig, da die Relying Party sonst nicht weiß, wie sie die Assertion verifizieren soll. Der issuer ist nur nötig, wenn der Zertifikatsausteller eine Secondary Authority ist, da bei einer Primary Authority von der adresse auf den Aussteller geschlossen werden kann. Wäre die adresse z.b. so wäre der Zertifikatsausteller example.com, wenn nicht explizit durch einen issuer anders angegeben Zertifikat Das Zertifikat wird vom Benutzer verwendet, um der Relying Party eine Möglichkeit zu geben, die vom Benutzer empfangene Assertion zu verifizieren. Das Zertifikat selbst ist entweder von einer Primary oder Secondary Authority signiert. Es beinhaltet: 1. Die adresse des Benutzers. 2. valid-until: Die Gültigkeitsdauer des Zertifikats. 3. public-key: Der öffentliche Schlüssel des Benutzers, welcher zur Verifikation der Assertion benötigt Bachelor-Seminar: BrowserID Februar 2012

12 wird. Bachelor-Seminar: BrowserID Februar 2012

13 2.5.3 JWT Beispiel An dieser Stelle sei ein JWT-Beispielobjekt gegeben. So kann eine Assertion mit dem dazugehörigen Zertifikat aussehen. { "assertion": { "audience:" "relyingparty.com", "valid-until" , }, "certificate": { " " "benutzer@example.com", "public-key" "<Benutzers Pub-Key>", "valid-until" " ", } } Der obere Teil des JWT-Objekts ist mit dem Public-Key des Benutzers unterschrieben, um sicherzustellen, dass die Assertion auch von dem Benutzer kommt, der diese adresse besitzt. Der untere Teil ist von der Primary oder Secondary Authority unterschrieben, um die Authentizität des Public-Keys und dessen Zugehörigkeit zur adresse sicherzustellen. 2.6 Sicherheit von BrowserID Der Kern von BrowserID ist der Identitätsbeweis. Dies wird wie z.b. bei dem weit verbreiteten SSL/TLS, mit asymmetrischer Kryptografie geregelt. Der Unterschied zu SSL/TLS ist, dass sich nicht der Server dem Client gegenüber authentifiziert, sondern der Client gegenüber dem Server. (Auch dieser Weg ist bei SSL/TLS möglich, wird aber bei Webservices wenig genutzt). Mozilla möchte mit BrowserID erreichen, dass eine Relying Party der Assertion eines Benutzer vertrauen kann und somit sichergestellt ist, dass dieser der Besitzer der adresse ist, mit der er sich einloggen möchte. Wir können festhalten, dass die Relying Party dem Benutzer die Behauptung, dies sei seine adresse, glaubt, da die Behauptung mit dem Private-Key des Benutzers unterschrieben ist. Die Vertrauenswürdigkeit des angegebenen Public-Keys zur Verifizierung der Assertion wird über die Signatur einer Primary oder Secondary Authority sichergestellt. Die Relying Party muss also nicht dem Benutzer direkt vertrauen, sondern vertraut darauf, dass die Authority den Besitz der Bachelor-Seminar: BrowserID Februar 2012

14 adresse festgestellt hat Verfügbarkeit Wenn der Benutzer im Besitz einer von einer Primary oder Secondary Authority verifizierten E- Mailadresse ist und das dazugehörige Zertifikat mit Key Pair sicher lokal gespeichert hat, sollte auch die Verfügbarkeit von BrowserID auf Clientseite sichergestellt sein. Sollte der Benutzer an einem anderen Gerät oder Browser arbeiten, oder sein Zertifikat ist abgelaufen, so lässt er sich einfach ein Neues ausstellen. Serverseitig muss die Relying Party die Assertion des Benutzers überprüfen. Dafür wird bei der zum Zertifikat gehörigen Authority nach deren Public-Key gefragt. Ohne den Public-Key der Authority kann die Gültigkeit des Benutzerzertifikats nicht verifiziert werden. Sollte also der Public Key einer Authority nicht erreichbar sein, kann kein Login mit BrowserID erfolgen. Mögliche Lösungen wären z.b., dass die Relying Party die Public-Keys der Authorities zwischenspeichert, um nicht bei jedem BrowserID Loginversuch erneut danach fragen zu müssen. Eine andere Lösung wäre, dass der Bentuzer mehrere Zertifikate von unterschiedlichen Authorities besitzt. In diesem Fall würde man solange durchprobieren, bis zu einem Zertifikat der Public-Key des Ausstellers gefunden wurde. Welche Lösung sich für das Problem der Erreichbarkeit der Authority durchsetzen wird, ist aufgrund der noch geringen Verbreitung von BrowserID noch nicht abzusehen. Mozilla selber hat bisher keine Lösung für das Problem angegeben Verbindungssicherheit Wie bereits weiter oben beschrieben, basiert BrowserID auf asymmetrischer Kryptografie. Jedoch wird diese nur zum Signieren, also zur Sicherstellung der Authentizität und Integrität, genutzt, jedoch nicht zur Verschlüsselung der Nachrichten im Protokollverlauf. Die Assertion und das dazugehörige Zertifikat werden in keiner Weise durch BrowserID geschützt. Da ein Angreifer die Assertion einfach abfangen könnte und diese innerhalb der Gültigkeitsdauer selber zum Einloggen nutzen könnte, muss dies per SSL/TLS unterbunden werden. Durch die audience in der Assertion, also die Angabe an welche Relying Party diese gerichtet ist, wäre eine Umleitung an eine andere Relying Party auch dann nicht möglich, wenn die Verbindung nicht mit SSL/TLS gesichert ist, oder die Verbindung durch falsch ausgestellte SSL-Zertifikate unsicher ist. Wie gezeigt, bietet BrowserID selber keinen Schutz gegen das Abhören der übertragenen Daten. Vielmehr basiert die Verbindungssicherheit auf SSL/TLS. Da dieses von den gängigen Browsern unterstützt wird, ist keine weitere Implementierungsarbeit für die Verschlüsselung Bachelor-Seminar: BrowserID Februar 2012

15 Abbildung 5: Weiterleiten einer Assertion Abbildung 6: Die Übertragung wird durch SSL/TLS gesichert der Verbindung nötig. Dies ist wichtig, wenn BrowserID sich schnell verbreiten soll Zertifikate Unter der Annahme, dass die verwendeten kryptografischen Verfahren sicher sind und die Assertion nicht gefälscht werden kann, bleibt noch die Frage des Zertifikatmanagements offen. Zwar besitzen die Zertifikate, die ein Benutzer von der Primary oder Secondary Authority erhalten hat, ein valid-until Feld, jedoch scheint es bisher keine Möglichkeit zu geben, ein Zertifikat vor Ablauf der Gültigkeit für nichtig zu erklären. Man kann zwar argumentieren, dass es sich bloß um Cientzertifikate handelt, bei denen im Gegensatz zu einem SSL-Serverzertifikat kaum ein Risiko für Missbrauch besteht, aber gerade dadurch, dass BrowserID für jeden vom Benutzer genutzten Browser neue Zertifikate erstellt, ergibt sich ein Problem. Ein Benutzer nutzt z.b. BrowserID auf seinem heimischen PC und auch von seinem Smartphone aus. Der Browser im PC und der Browser im Smartphone besitzen unterschiedliche Zertifikate für dieselbe Identität. Verliert der Benutzer sein Smartphone, so könnte der Finder sich mit den Zertifikaten und dem Private-Key des Benutzer bei allen Relying Parties anmelden, die BrowserID nutzen und bei denen der Benutzer einen Account hat. Der Benutzer hat keine Möglichkeit, die auf dem Smartphone gespeicherten Zertifikate zurückzuziehen. Die Zertifikate auf seinem PC zu löschen, bringt in diesem Fall auch nichts, da wie oben bereits gesagt, die Zertifikate der beiden Browser unterschiedlich Bachelor-Seminar: BrowserID Februar 2012

16 sind. Ein weiteres denkbares Szenario wäre die Nutzung von BrowserID in einem Internetcafe oder der Universität. In diesem Fall müsste es eine Möglichkeit geben, ein Zertifikat nur für eine temporäre Browser-Session zu erstellen. Bisher sind von Mozilla keine Möglichkeiten vorgeschlagen worden, um Zertifikate für ungültig zu erklären. Eine Möglichkeit wäre die Gültigkeitsdauer der Zertifikate sehr kurz zu wählen. Jedoch muss dann oft ein Neues erstellt werden, was wieder die Useability von BrowserID schmälert Secondary Authorities Bei einer Primary Authority, also dem provider des Benutzer, ist sichergestellt, dass der Benutzer dem provider vertraut, da er dort sonst keine adresse beantragt hätte. Zudem kann der Besitz der adress durch ein einfaches Einloggen bei dem provider bewiesen werden. Eine Relying Party kann bei einem durch eine Primary Authority ausgestellten Zertifikat diesem also mit großer Wahrscheinlichkeit vertrauen. Bei Secondary Authorities ist dies anders. Zwar ist von Mozilla geplant, dass alle großen provider ihren Dienst implementieren, aber gerade in der Anfangszeit werden die meisten Anmeldungen bei BrowserID über Secondary Authorities geregelt. 2 Wichtig ist, dass die Secondary Authority ein Zertifikat für eine adresse erstellt, deren Provider sie selber nicht ist. Da von Mozilla BrowserID als ein dezentrales System gedacht ist, kann theoretisch jeder eine Secondary Authority erstellen. Der wichtige Schritt bei der Erstellung des Zertifikats ist der Beweis über den Besitz der adresse. Wenn eine Secondary Authority aber genau diesen weglässt, können gültige Zertifikate für jede beliebige adresse ausgestellt werden und das gesamte System bietet keinerlei sichere Identifikation. Wenn eine solche Secondary Authority existieren würde, könnte ein Angreifer vollen Zugriff auf alle Webservices, die von einem Benutzer genutzt werden, erlangen, solange er dessen adresse kennt. Um dieses Problem zu umgehen, müssen die Relying Parties den Secondary Authorities explizit vertrauen. Das heißt, wenn die Relying Party den issuer, also die Secondary Authority, aus der Assertion extrahiert, muss diese mit einer Liste von vertrauenswürdigen Secondary Authorities abgeglichen werden. Dies stellt insofern kein großes Problem dar, da die Secondary Authorities nur als Übergangslösung gedacht sind. Es wird also nicht nötig sein, eine Liste mit vertrauenswürdigen Secondary Authorities zu führen, die immer länger und länger wird. Von Mozilla angedacht ist, dass sich eine Hand voll Secondary Authorities etablieren, die nur dann in Anspruch genommen werden, wenn die provider noch keine Implementierung als Primary Authority haben. 2 Für die Funktionsweise der Secondary Authority siehe 2.4.3, auf Seite 10 Bachelor-Seminar: BrowserID Februar 2012

17 Abbildung 7: Zertifikate ohne adressenverifikation Web-Angriffe Bisher sind die Sicherheitsmechanismen von BrowserID beleuchtet worden. Es wurde aber noch nicht darauf eingegangen, wie sicher BrowserID durch die vorgestellten Mechanismen gegen die üblichen Angriffe im Web ist. Wichtig ist, dass BrowserID lediglich die Identität eines Benutzer fest stellt. Es bietet keinen Schutz gegen den Diebstahl von Authentification Cookies durch XSS oder das Absenden falscher Requests durch CSRF. Es müssen dieselben Sicherheitsvorkehrungen bei der Implementierung eines Anmeldeverfahrens bei einem Webservice integriert werden wie bei einem gewöhnlichen Einloggen per Username - Password. Sollte einmal in eine Authority eingebrochen werden, spielt dies keine große Rolle für die Sicherheit von BrowserID, da keine Daten über den Benutzer dort gespeichert sind. Zu bemerken ist, dass BrowserID einen gewissen Schutz vor Phishing-Angriffen bietet. Wenn z.b. der Benutzer auf eine gefälschte Website gelockt wird und er sich bei der Originalseite mit BrowserID einloggt, so kann er bei der Phishing-Seite nicht seinen Benutzername und sein Passwort verraten, da diese bei BrowserID nicht von Nöten sind. Der Angreifer würde maximal eine Assertion erhalten, mit der er überprüfen kann, ob die adresse verifiziert wurde. Zugriff auf Dienste bekommt der Angreifer nicht. Bachelor-Seminar: BrowserID Februar 2012

18 3 Zusammenfassung 3 Zusammenfassung BrowserID bieten einen komfortablen Weg, um sich bei einem Webservice zu identifizieren. Man benötigt nur noch ein Passwort, welches beim erstmaligen Nutzen von BrowserID die Key Chain öffnet, um an die Private-Keys zum signieren der Assertions zu gelangen. Die Sicherheit baut auf seit langem eingesetzten Techniken wie asymmetrischer Kryptografie und SSL/TLS auf. Einer Nutzung auf den unterschiedlichsten Geräten wie PCs, Smartphones, Tablets etc. steht dank der Tatsache, dass BrowserID komplett mit JavaScript funktioniert, nichts im Weg. Sinnvoll ist BrowserID allerdings nur bei hoher Verbreitung, d.h., wenn viele Webservices dieses anbieten. Dazu kommt, dass die provider bereit seien müssen, die Rolle der Primary Authority zu übernehmen. Zudem haben die großen Webservices wie Google, Facebook oder Twitter bereits eigene Verfahren entwickelt und eine zusätzliche Konkurrenz entsteht durch Verfahren mit demselben Ziel, wie z.b. OpenID, WebID etc. Es ist also durchaus möglich, dass BrowserID bereits an der Verbreitung scheitert. Wenn man die Funktionsweise von BrowserID einmal auf das Wesentliche reduziert, bleibt ein Dienst, der, wenn man mit seinem Masterpasswort einmal die Key Chain geöffnet hat, um an die Private-Keys zu gelangen, das Einloggen mit einem Klick ermöglicht. Genau diese Möglichkeit bieten aber Passwortmanager seit langem. Jeder moderne Browser unterstützt das automatische Einfügen von Benutzername und Passwort bei der Anmeldung bei einem Webservice. Zusammenfassend kann man über BrowserID sagen, dass es sich um ein solides Identifizierungsverfahren handelt, es jedoch keine großen Vor- oder Nachteile den heute schon verbreiteten Verfahren gegenüber hat. Bachelor-Seminar: BrowserID Februar 2012

19 4 Quellenangaben 4 Quellenangaben [lloy], How BrowserID works, November 2011 [ars], Arstechica, November 2011 [brwid], BrowserID, November 2011 Bachelor-Seminar: BrowserID Februar 2012