OSBAR

Der Open Source Business Award (auch OSBAR) wird von der Open Source Business Alliance durchgeführt. Dabei werden Open Source Projekt und auch Ideen prämiert, die innovativ sind und einen entscheidenden Mehrwert für Unternehmen und Institutionen der öffentlichen Hand bieten.

privacyIDEA

Wir glauben, dass das Open Source Projekt privacyIDEA dies voll erfüllt. Gegenüber herkömmlichen OTP-Systemen setzt es viele, neue Ideen um und ermöglich den Anwendern so, individuelle und elegante Lösungen in ihrer Infrastruktur zu bauen.

Daher hat die NetKnights GmbH das Projekt privacyIDEA beim Open Source Business Award eingereicht. Hier können Sie die Einreichung lesen: privacyIDEA_OSBAR_2016.

privacyIDEA wird in der kommenden Version um ein Event Handler Framework erweitert.

Richtlinien für Zwei-Faktor-Authentifizierung

Das Zwei-Faktor-Authentifizierungssystem privacyIDEA lässt sich bereits über Richtlinien (Policies) detailliert konfigurieren und das Verhalten abhängig von vielen Rahmenbedingungen beeinflussen. So lassen sich mit Hilfe der Richtlinien unterschiedliche Szenarien abbilden und zu nahezu allen Herausforderungen eine Lösungen finden. Richtlinien verändern das Authentifizierungs- und Autorisierungsverhalten. Der Administrator kann beispielsweise verschiedene Sicherheitsstufen abbilden oder einfache Migrationen durchführen.

Event-Handler

Mit Hilfe der neuen Event-Handler eröffnen sich noch mehr Möglichkeiten. Die Richtlinien beeinflussen und verändern das Verhalten von privacyIDEA an sich. Der Event-Handler hingegen ändert nichts an dem Verhalten, sondern startet, abhängig von eintretenden Ereignissen, zusätzliche Aktionen, ohne das eigentliche Ereignis zu verändern.

event-handler-privacyidea

So wird in dem obigen Beispiel an das Ereignis „token_init“ (Ein Token wird für einen Benutzer ausgerollt) die Aktion „sendmail“ gehängt.

Um die Logik kümmert sich das Event-Handler-Modul „UserNotification“. Das Interessante ist nun, dass der Administrator ganz flexibel die entsprechende Aktion an jedes beliebige Ereignis hängen kann.

Weitere Event-Handler-Module

Als erstes Event-Handler-Modul wird „UserNotification“ ausgeliefert. Weitere Module sind denkbar und können schnell folgen. So könnte ein Modul „Enrollment“ für einen Benutzer einen speziellen Token-Typen ausstellen — als Reaktion auf ein beliebiges Ereignis.

Somit eröffnen sich ungeahnte Möglichkeiten, neue, kreative Konfigurationen und Workflows abzubilden. Einmal mehr beweist privacyIDEA, dass es ein modernes, innovatives und richtungsweisendes Authentifizierungssystem ist.

Abonnieren Sie unseren Newsletter, um immer auf dem Laufenden zu sein.

Leichte Migration eines bestehenden OTP-Systems zu privacyIDEA

Oftmals entscheiden sich Kunden, ihr bestehendes, proprietäre OTP-System zur Zwei-Faktor-Authentifizierung abzulösen. Dies hat verschiedene Gründe. Das bestehende System ist zu alt und es gibt keine Updates mehr. Gleichzeitig wird es zu unflexibel. Die für das System verfügbaren Token erfüllen nicht mehr die Anforderungen der heutigen Zeit. Unternehmen wachsen zusammen und jedes Unternehmen bringt seine eigene, proprietäre Lösung mit. Manchmal ist das bestehende System auch einfach zu teuer oder im Zuge der Vertrauens- und Überwachungsthematik möchte man lieber ein Open Source System einsetzen.

Dies sind Gründe, wieso sich Kunden für die Nutzung von privacyIDEA entscheiden.

privacyIDEA bietet schon heute verschiedene Möglichkeiten — bspw. mit den RADIUS Token, eine solche Migration sanft durchzuführen. Doch mit der Version 2.11 wird eine solche Migration nochmal leichter. privacyIDEA 2.11 wird am 18. März veröffentlicht. Wenn Sie auf dem Laufenden bleiben wollen, abonnieren Sie bitte hier unseren Newsletter.

Zentral definierte RADIUS-Server

In privacyIDEA 2.11 ist es möglich, an zentraler Stelle mehrere RADIUS-Sever zu konfigurieren. Dies ist vergleichbar mit der letztens eingeführten Möglichkeit, zentral SMTP-Server zu konfigurieren.

Zentral definierte RADIUS-Server

Zentral definierte RADIUS-Server „RSA SecurID“.

Diese RADIUS-Server können für den RADIUS-Token oder auch in den Richtlinien verwendet werden.

Bisher (bis einschließlich privacyIDEA 2.10) muss für jeden Benutzer in privacyIDEA ein RADIUS-Token ausgestellt werden. Dieser RADIUS-Token verweist auf den alten RADIUS-Server des abzulösenden OTP-Systems. Solange der Benutzer also noch keinen OTP-Token innerhalb von privacyIDEA hat, kann er sich noch immer mit dem alten Token authentisieren.

Eine Richtlinie für alle Benutzer

Ab Version 2.11 können die zentral definierten RADIUS-Server in den privacyIDEA-Richtlinien verwendet werden.

policy-radius-passthru

Der zentral definierte RADIUS-Server „RSA SecurID“ wird in der passthru-Policy verwendet.

Hierzu wurde die bereits existierende passthru-Richtlinie erweitert. Die passthru-Richtlinie greift, wenn ein Benutzer innerhalb von privacyIDEA noch keinen Token zugewiesen bekommt. Die Authentifizierungsanfrage wird dann an das LDAP oder AD weitergereicht oder – nun neu in 2.11 – an einen konfigurierten RADIUS-Server.

Das bedeutet, dass in einem sanften Migrationsszenario von Ihrem alten OTP-System hin zu privacyIDEA nur noch eine einzige Richtlinie zu definieren ist, und Sie nach und nach allen Benutzern einen neuen Token innerhalb von privacyIDEA ausstellen können!

Migrieren!

Das hier beschriebene Szenario funktioniert problemlos für alle Systeme, die einen RADIUS-Server bereitstellen. Darunter Systeme wie Kobil, RSA SecurID, SafeNet, Vasco (in alphabetischer Reihenfolge).

Sprechen Sie uns an!

Die Entwicklungen für privacyIDEA 2.10 rund um das Thema Benutzerregistrierung laufen auf Hochtouren.

Benutzerregistrierung in privacyIDEA.

In der Version 2.10 von privacyIDEA wird es die Möglichkeit geben, dass sich neue Benutzer registrieren. Im Blog von privacyIDEA.org finden sich weitere technische Details.

Neue Szenarien mit Benutzerregistrierung

Mit der Möglichkeit, dass sich Benutzer am privacyIDEA-System selber registrieren können, ergeben sich neue Benutzungsszenarien für Zwei-Faktor Authentisierung.

Zwei-Faktor-Provider

Zwei-Faktor Authentifizierung kann nun also Benutzer angeboten werden, die vorher nicht bekannt sind. So kann bspw. ein Provider mit Hilfe einer privacyIDEA-Installation einen öffentlichen Zwei-Faktor-Dienst anbieten. Benutzer können sich somit frei an privacyIDEA registrieren, der Provider kann mit einem entsprechenden Abrechnungsmodell für den Benutzer eine monatliche Gebühr erheben. Der Benutzer kann ein Authentisierungs-Gerät aus der vom Provider vorgegebenen Liste wählen. Dies können klassische HOTP oder TOTP Token sein, Google Authenticator oder andere Apps oder U2F-Geräte wie der Yubikey oder NitroKey.

Die Authentifizierung kann der Provider über unterschiedliche Protokolle wie bspw. SAML, RADIUS oder die WebAPI anbieten.

Gast-Accounts

In Unternehmen oder Hotels können sich Gäste an einem privacyIDEA System registrieren, um einen zweiten Faktor auszurollen. Damit können sie bspw. für einen bestimmten Zeitraum Zugriff auf sensible Resourcen erhalten. Wenn sich ein externer Mitarbeiter registriert und einen zweiten Authentisierungs-Faktor im privacyIDEA erstellt hat, könnte das Unternehmen ihm mit diesem zweiten Faktor Zugriff auf schützenswerte Projektinformationen gewähren.

Neue Workflows

Auch innerhalb eines Unternehmens, einer Organisation oder einer Universität ermöglicht die Benutzerregistrierung neue Abläufe. Anstatt während des Rollout-Prozesses aktiv den Benutzern den Token zuzuweisen oder den Rolloutprozess lediglich an das Wissen des Domänenpasswortes zu binden, kann ein Mitarbeiter sich selber registrieren müssen. Durch den Registrierungsprozess wird er identifiziert und erhält seinen zweiten Faktor, den er dann bpsw. für den Remote-Zugriff mittels VPN nutzen kann.

Die Registrierung kann auf einen bestimmten Mitarbeiterkreis bspw. anhand der Email-Adresse beschränkt werden.

privacyIDEA Workshop

Über die Registrierung hinaus bietet privacyIDEA bereits eine Vielzahl an flexiblen Einsatzmöglichkeiten. Lernen Sie privacyIDEA besser kennen und sehen Sie, wie es in Ihrem Unternehmen die Anmeldeverfahren sicherer machen kann und wie Sie auf einfache Art und Weise Ihren Mitarbeitern einen zweiten Faktor ausstellen. Besuchen Sie hierzu im Januar das kostenlosen privacyIDEA-Webinar.

 

Das Video zum privacyIDEA Talk auf der T-Dose ist nun verfügbar (Englisch).

Cornelius Kölbel hielt am 28.11.2015 auf der T-Dose in Einhoven (Niederlande) einen Vortrag mit dem Titel

No Need For Gemalto – Do it yourself! Two Factor Authentication with privacyIDEA.

Hierbei wird dargelegt, wie man sich von kommerziellen, proprietären Herstellern in Bezug auf starke Authentifizierung unabhängig machen kann.

Das besondere Augenmerk ist zu richten auf:

  • Kontrolle über das Schlüsselmaterial
  • Kontrolle über den Code (Open Source)
  • Kontrolle über den Computer, auf dem die Software läuft.

Die Open Source Software privacyIDEA bietet hierfür die entsprechenden Voraussetzungen.

Dieses Video ansehen auf YouTube.

Universal 2nd Factor ist ein von der FIDO Alliance spezifiziertes Protokoll, bei dem die Anmeldung an einer Webseite um einen zweiten Faktor — konkret einen Hardware-Besitz — ergänzt wird.

Die FIDO Alliance

In der FIDO Alliance engagieren sich große Player mit einer großen Benutzeranzahl wie Google und Paypal und klassische Hardwarehersteller wir RSA, Gemalto, Feitian und Yubico. Die Masse der Benutzer bei Google und Paypal sind überwiegend denzentrale, nicht organisierte Endanwender.

Das U2F Protokoll

Security-Key-by-Yubico-in-USB-Port-on-Keychain

Yubico U2F Yubiky

Die Idee bei U2F ist, dass ein Benutzer lediglich ein Hardware-Gerät hat, mit dem er sich ausweisen kann. Dazu registriert er dieses Gerät an den Webdiensten und Portalen, die das U2F Protokoll unterstützen. Das besondere hierbei ist, dass die einzelnen Webdienste nichts voneinander wissen. D.h. der Webdienst B weiß nicht, dass das gleiche Gerät bei Webdienst A registriert wurde. Dies soll die Anonymität des Endanwenders sicherstellen und die komplette Unabhängigkeit zwichen den einzelnen Webdiensten gewährleisten.

U2F ist also ein Protokoll für eine denzentrale Authentifizierung von Endanwendern.

Die Registrierung und Authentifizierung

Um dies zu ermöglichen, muss der Benutzer an jedem Webdienst, das Gerät registrieren. Dabei wird ein asymmetrisches  Schlüsselpaar erzeugt. Der öffentliche Schlüssel wird mit weiteren Meta-Informationen bei dem Webdienst gespeichert.

Wenn nun der Benutzer sich später an dem Webdienst authentisieren möchte, kann der Webdienst eine Challenge zusammen mit den Metainformationen an das U2F-Device senden. Die Authentifizierung erfolgt als Challenge-Response-Verfahren mit dem asymmetrischen Schlüsselmaterial.

Wieviele Schlüsselpaare passen auf den Yubikey?

Unendlich viele. Wenn der Yubikey bei der Registrierung das Schlüsselpaar erzeugt, speichert er den privaten Schlüssel nicht ab. Sondern er generiert das Schlüsselpaar aus einem Masterkey, der fest auf dem Yubikey gespeichert ist.

In die Generierung fließen außerdem die Metainformationen mit ein. Allem voran die sogenannte AppId, die im wesentlichen der URL des Webdienstes entspricht. Hierzu später mehr.

D.h. wenn der Webdienst die Challenge und die Metainformationen an das U2F-Device sendet, kann der Yubikey daraus mit dem fest gespeicherten Masterkey wiederum den speziellen, privaten Schlüssel für diesen Webdienst berechnen und die Challenge korrekt beantworten.

U2F im Unterschied zu klassischen 2FA

OTP Authentifizierung

Die Authentifizierung mit Einmalpasswörtern setzt auf symmetrische Kryptographie. Außerdem wird für die Authentifizierung mit Einmalpasswörtern ein Backend benötigt, das den gemeinsamen, symmetrischen Schlüssel kennt. Will man sich mit Einmalpasswörtern an mehreren Webdiensten anmelden, so benötigt man entweder eine zentrale Authentifizierungsinstanz, die die symmtrischen Schlüssel kennt, oder man benötigt für jeden Webdienst ein eigenen OTP-Token.

Eine Weile sind verschiedene Anbieter den zweiten Ansatz gefahren. Bei allen möglichen Webdiensten konnte man sich einen Google Authenticator — speziell bei diesem Webdienst — ausrollen. Die Google Authenticator App quillt über mit Profilen unterschiedlicher Webdienste. Der Benutzer muss in der langen Liste der Profile, jeweils im richtigen Moment das richtige finden.

Mit einem U2F-Token ist das nicht nötig. Der Benutzer hat nur ein Gerät und wo er sich mit diesem Gerät überall registriert hat, ist im Endeffekt egal. Die Anzahl der registrierten Webdienste beeinträchtigt die Usability nicht.

Authentifizierung mit Smartcard

Eine Authentifizierung mit einer Smartcard arbeitet genau wie U2F mit einem asymmetrischen Schlüsselpaar. Der große Nachteil der Smartcard ist aber die Notwendigkeit eines Treibers. Nicht zuletzt ist das ein entscheidender Grund, weshalb in den vergangenen Jahren OTP ein solches Revival erlebt hat. Gerade im B2C bzw. Endanwender-Bereich ist es undenkbar, von Benutzern die Installation eines Treibers zu fordern.

Das U2F Protokoll wird mittels einer Javascript Bibliothek, die der jeweilige Webdienst einbinden muss, bereitgestellt.

Die Nutzung des USB-basierten U2F-Tokens funktioniert zur Zeit allerdings lediglich im Chrome Browser. Andere Browser sollen folgen.

U2F im Unternehmenseinsatz

U2F ist ein Protokoll, das deutlich für den Endanwender-Bereich gedacht ist. Es ist dezentral. Es schottet die einzelnen Webdienste gegeneinander ab. Der Benutzer kann bzw. muss den U2F-Token selber registrieren.

Wenn man sich die Player vom Anfang anschaut, dann macht auch dies Sinn. Die FIDO Alliance Mitglieder kommen zum größten Teil aus dem Endanwender-Markt. Ob Google, Mastercard, American Express. D.h. per se ist U2F nicht für den Unternehmenseinsatz entworfen.

Die charmante Handhabung bei der Anmeldung und der vergleichsweise niedrige Preis der Hardwaregeräte lassen uns aber trotzdem ein zweites mal über den Unternehmenseinsatz nachdenken.

Die AppId und Trusted Facets

Die oben erwähnte AppId ist im wesentlichen die URL. Anhand derer wird das für diesen Webdienst gültige Schlüsselpaar erzeugt bzw. später identifiziert. D.h. andere Webdienste mit anderen URLs müssten selber ein Schlüsselpaar registrieren. Da aber manche Anbieter wie https://google.com, https://maps.google.com, https://docs.google.com unter unterschiedlichen URLs mehrere Webdienste bereitstellen, für die der Anwender nicht jeweils wieder seinen U2F-Token registrieren soll, gibt es das Konzept der „Trusted Facets“. Hier kann definiert werden, dass ein einmal registrierter U2F-Token für spezielle Subdomains bzw. Hosts innerhalb der gleichen Domain verwendet werden darf.

D.h. der U2F-Token, der einmal für https://google.com registriert wurde kann außerdem auf https://maps.google.com und https://docs.google.com ohne erneute Registrierung verwendet werden.

Im Unternehmenseinsatz kommt man um die Nutzung der „Trusted Facets“ nicht umhin. Denn kein Unternehmen erwartet von seinen Benutzern, dass er sein Authentifizierungs-Device an https://crm.example.com, https://portal.example.com und https://vpn.example.com registrieren soll. Mit den „Trusted Factes“ lässt sich eine einmalige Registrierung realisieren.

Grenzen der Trusted Facets

Das Leben im Unternehmen gestaltet sich aber oft nicht so geradlinig. Innerhalb des Unternehmensnetzwerks sind manche Resourcen evtl. über andere Domainnamen als extern erreichbar. Manche Unternehmen verwenden intern bspw. eine Domain wie example.intranet oder example-intern.com, währen sie extern example.com verwenden.

Das CRM, das innerhalb des Unternehemsnetzwerk steht, ist also über https://crm.example-intern.com erreichbar, während der VPN-Zugang über https://vpn.example.com läuft. Die Trusted Facets erlauben aber nicht, eine andere Domain als vertrauenswürdig anzugeben. D.h. mit einem U2F-Token, der an https://example.com registriert wurde, kann man sich nicht an https://…example-intern.com anmelden. In dieser Domäne wäre eine erneute Registrierung nötig.

Zentrales Rollout

privacyIDEA-200pxWeiterhin will man im Unternehmensumfeld die Verteilung von Authentifizierungsgeräten zentral kontrollieren und nicht unbegrenzt und unkontrolliert dem Benutzer überlassen. Hierzu unterstützt ein Management-System wie privacyIDEA die Registrierung von U2F-Token nicht nur durch den Anwender, sondern auch durch den Administrator bzw. den Helpdesk. So können U2F-Geräte zentral und kontrolliert für die Mitarbeiter im Unternehmen ausgerollt bzw. registriert werden.

Der Masterkey

Schließlich gibt es bei den U2F-Geräten weiterhin einen Punkt, über den man sich im Klaren sein muss. Das Schlüsselmaterial. Zwar wird bei der Registrierung das asymmetrische Schlüsselpaar für den jeweiligen Webdienst erzeugt. Allerdings passiert dies auf Basis des Masterkeys. Dieser wurde vom Hersteller in einer konktrollierten Umgebung auf dem U2F-Token erzeugt. Es ist nicht vorgesehen, den Masterkey selber zu erzeugen. An anderer Stellen hatten wir bereits über die Risiken, das eigene Schlüsselmaterial nicht selber zu erzeugen, berichtet.

Die Argumentationslinie bei U2F ist hierbei folgende. Das Gerät schickt bei der Registrierung ein sogenanntes „Attestation Certificate“ — ein Beglaubigungszertifikat. Dieses Zertifikat soll gegenüber dem Registrar nachweisen, dass es sich um ein bestimmtes Gerät einer gewissen Klasse handelt. Somit könnte der Registrar sicherstellen, dass bspw. nur Geräte des Herstellers A registriert werden dürfen, weil diese vermeindlich einen höheren Sicherheitsstandard haben. D.h. durch das Beglaubigungszertifikat ist somit auch nachgewiesen, dass dies ein Gerät des Herstellers A ist und dieses Gerät nach gewissen Sicherheitsstandards erzeugt und initialisiert worden war. Könnte nun ein Anwender oder Unternehmen ein U2F-Token selber initialisieren, so wäre das Beglaubigungzertifikat nutzlos, da für den Registrar nicht mehr ersichtlich wäre, mit welchen Sicherheitsstandards der Token initialisiert wurde.

Hier muss jeder für sich abwägen, ob der Einsatz von vorinitialisierten U2F-Token im Unternehemsumfeld eine Option ist. Yubikeys im OTP- oder Challenge-Response-Modus lassen sich mit privacyIDEA initialieren, so dass Sie die Wahl zwischen U2F, OTP und Challenge Response haben.

 

 

Die Open Source Busines Alliance vergibt dieses Jahr wieder den Open Source Busines Award – OSBAR. Diesmal sitze ich in der Jury und darf die verschiedenen eingesandten Projekte bewerten.

In den letzten Tagen gab es für mich eine interessante Projekteinreichung, die ich hier kurz vorstellen möchte.

Mein Hintergrund

Seit vielen Jahren erbringe ich IT-Dienstleistungen. Hierzu wurden viele Fremdprodukte und in letzter Zeit vermehrt Eigenprodukte beim Kunden genutzt, um die passende Lösung für den Kunden zusammenzustellen.

Auch als Reseller und IT-Dienstleister stellte ich bald fest, dass es wichtig ist, den Überblick über die Software beim Kunden zu behalten. Dabei war es eben nicht nur wichtig, zu wissen, welche Software beim Kunden im Einsatz ist. Sondern ebenso, wieviele Lizenzen oder Subskriptionen einer Software der Kunde hat. Wann laufen diese Subskriptionen aus? Als Reseller ist dies wichtig, um dem Kunden zeitnah entsprechende Verlängerungen anbieten zu können. Der Endkunde profitiert ebenfalls davon, einen Überblick über die Anzahl und Laufzeiten seiner Subskriptionen und Lizenzen zu haben. So kann er zu jeder Zeit optimal den Support des Herstellers in Anspruch nehmen oder sich von überflüssigen Lizenzen und Subskriptionen trennen.

Doch in all den Jahren begegnete mir nur ein proprietärer Hersteller, der für Reseller und Endkunden ein entsprechendes Portal bereitstellte, das mehr oder weniger gut dem Reseller und Kunde ermöglichte, Subskriptionen einzusehen und zu verwalten.

Für mich war das jeher unverständlich, denn der Hersteller muss diese Subskriptionen intern doch auch verwalten! Oder betreibt er hierzu eine Excel-Tabelle oder gar Google Docs?

In meiner Zeit als Produktmanager entwickelte ich ein entsprechendes Portal, mit dem wir firmenintern die Subskriptionen verwalteten. Es unterstütze auch die Sicht der Kunden, des Resellers und des Distributors. Doch leider wurde diese Software nie veröffentlicht.

Umso mehr freue ich mich, dass die SerNet GmbH dieses Thema aufgegriffen hat.

OPOSSO

Die SerNet GmbH entwickelt nun ein solches „Subscription Management System“ mit dem Namen „OPOSSO“ und dem Ziel, dieses als Open Source öffentlich verfügbar zu machen. OPOSSO wurde beim Open Source Business Award eingereicht. Derzeit ist das System noch nicht als Download verfügbar, da es sich bei der SerNet noch in Entwicklung befindet und sich die Entwickler noch nicht entschieden haben, es zu veröffentlichen. Allerdings kann man sich unter oposso.samba.plus ein erstes Bild davon machen, was uns erwartet.

Die SerNet GmbH ist bzw. Mitarbeiter der SerNet sind federführend in der Samba-Entwicklung. Außerdem hat die SerNet mit Verinice ein Information-Secucity-Management-System als Open Source am Start.

Wir dürfen also gespannt sein, was uns erwartet!

Open Source Business Award

Open_2015_Logo_Farbe_RGB

Administrative Aufgaben stellen vor allem auch für kleine Unternehmen, oft schwere Herausforderungen dar. Man konzentriert sich gerne auf das Kerngeschäft: Die Entwicklung der eigenen Produkte. Da stellt die Verwaltung der Subskriptionen eine selten geliebte Herausforderung dar. Größere Unternehmen haben aufgrund der Menge der Kunden und Subskriptionen vielmehr das Problem, in diesem Verwaltungsakt nicht die Übersicht zu verlieren.

Kunden können sich freuen, zentral eine klare Aussage über den Zustand ihrer Subskriptionen zu erhalten.

Somit kann ein entsprechende Open Source Software zur Verwaltung diese Subskriptionen für Hersteller und Kunden gleichermaßen sehr hilfreich sein.

Am 2.12.2015 wird auf der Open!2015 der Open Source Business Award verliehen. Ob OPOSSO einen Platz belegt haben wird, wird sich dort erweisen.

Ja was nun – Zwei-Faktor-Authentisierung oder Zwei-Faktor-Authentifizierung?

Im Deutschen gibt es zwei Begriffe. Die Authentisierung und die Authentifizierung. Im normalen Umfeld mag das noch klar sein. Die Authentisierung ist die Sichtweise des Benutzers. Der Benutzer authentisiert sich an einem System. Die Authentifizierung ist die Sichtweise des Systems selber. Das System authentifiziert den Benutzer.

Wenn sich ein Benutzer anmeldet, muss der Server definitiv viel mehr tun als der Benutzer. Seine Aufgabe ist viel komplexer. Es muss erst einmal nachschauen, ob der Benutzer existiert und dann auch noch, ob die Credentials, die der Benutzer gesendet hat, valide sind. Hieraus ergibt sich eine kleine Eselsbrücke. Der Server macht die Authentifizierung. Denn das Wort Authentifizierung ist auch viel komplexer als Authentisierung. Schließlich hat der Server mehr zu tun und deswegen das Wort auch zwei Buchstaben (fi) mehr.

Doch wie ist das, wenn man zwei Faktoren hat?

Die „Two-Factor-Authentication“im Computerbereich mit einem Hardware-Faktor hat RSA im Jahr 1986 ins Leben gerufen. Dumme Sache nur, dass die englische Sprache nicht zwischen Authentisieren und Authentifizieren unterscheidet. Dort heißt es eben nur to authenticate und authentication.

Bundesamt für Sicherheit in der Informationstechnik

Das BSI selber spricht im Grundschutzkatalog von von Zwei-Faktor-Authentisierung bei Maßnahme 4.392 und Maßnahme 4.133. Allerdings scheint im ganzen Maßnahmenkatalog auch nicht das Wort Authentifizierung zu fallen.

Wikipedia

Die Einträge bei Wikipedia laufen unter Zwei-Faktor-Authentifizieung.

Heise

Ebenso wird das Schlagwort Zweifaktor-Authentifizierung als Thema bei Heise geführt.

Der Duden

Der Duden (20. Auflage, 1991) kennt die Worte authentifizieren und authentisieren.

authentifizieren: Die Echtheit bezeugen, beglaubigen.

authentisieren: Gehoben für glaubwürdig/rechtsgültig machen

Keep it simple and the customer happy

Unabhängig davon, dass es scheinbar offiziell Zwei-Faktor-Authentifizierung heißt, wähle ich persönlich oft die einfachere Bezeichnung Zwei-Faktor-Authentisierung. Damit stelle ich die Person als den Handelnden und nicht das authentifizierende Geräte in den Mittelpunkt. Außerdem erscheint mir das Wort leichter zu merken und auszusprechen zu sein.

Neulich wies mich ein Bekannter darauf hin, dass es doch zwei Faktoren sein. Grammitikalisch korrekt müsste es also Zwei-Faktoren-Authentifizierung heißen. Oder aber Zweit-Faktor-Authentifizierung.

Doch das nehme ich gar nicht in den Mund. Denn hätte ich meine Kunden mit komplizierten Worten verwirren wollen, wäre ich Arzt geworden.

 

Und mal wieder ging ein Beitrag durch die Presse, dass weitere Schlupflöcher für eine klassische Erklärung von verschränkten Photonpaaren in der Wiener Hofburg gestopft wurden.

Doch was hat es mit der Quantenkryptographie eigentlich auf sich? Und dabei bietet die Schweizer Firma ID Quantique dazu schon seit Jahren Produkte an!

Zentralbild Prof. Dr. phil Werner Kar. Heisenberg, Physiker, geboren 5.12.1901 in Würzburg, Professor für theoretische Physik, Direktor des Max-Planck-Instituts für Physik in Göttingen, Nobelpreis für Physik 1932 (Aufnahme 1933) 39049-33

Werner Heisenberg, Vater der Quantenmechanik (1933) [Bundesarchiv, Bild183-R57262 / CC-BY-SA 3.0]

Management Abstract

„Quantenkryptographie“ ist ein irreführender Name, da hier nicht wirklich die Verschlüsselung selber Thema ist. D.h. mit Quantenkryptographie kann man keine Email und vor allem keine Festplatte verschlüsseln. Der Prozess, der weithin mit „Quantenkryptigraphie“ bezeichnet wird, dient lediglich dazu, zwischen zwei Kommunikationspartnern, „sicher“ einen Schlüssel auszutauschen, um diesen Schlüssel dann zu verwenden, um den eigentlichen Nachrichtentext mit klassischen Algorithmen zu verschlüsseln. „Sicher“ heißt dabei auch nicht, dass ein Angreifer nicht mithören kann, sondern, dass die Kommunikationspartner wissen, ob ein Angreifer mitgehört hat oder nicht und daher wissen, ob der ausgehandelte Schlüssel vertrauenswürdig ist.

Quantenkryptographie löst also das Problem des Man-In-The-Middle-Angriffs beim Schlüsselaustausch.

Quantenkryptographie Hintergründe

Erwin_Schrödinger_(1933)

Erwin Schrödinger (1933) brachte uns die Katze

Disclaimer: Dieser Beitrag beansprucht nicht für sich wissenschaftlich korrekte Detailausführung, sondern ein grobes Verständnis für die Zusammenhänge zu vermitteln.

Die Quantenkryptographie arbeitet in der Welt der Quantenmechanik. Dies sind Effekte auf atomarer Ebene. Da wir – anders als die Newtonsche Mechanik – die Quantenmechanik in unserem Alltag nicht beobachten, haben wir hierzu keine persönlichen Erfahrungswerte. Uns fehlt Intuition. So wirkt sie auf uns merkwürdige, bisweilen unlogisch und ist schwer begreifbar.

In der Quantenmechanik gilt, dass der Zustand eines Objekts durch die Messung verändert bzw. erst bestimmt wird. Für die dicke meines Haares klingt das merkwürdig. Doch für die Quantenmechanik ist ein Haar immer noch die makroskopische Welt. Unheimlich dick. Und daher greift die Quantenmechanik erst bei ganz winzigen Größen. Bpsw. bei einem winzigen Lichtteilchen.

Erwin Schrödinger gab dazu das Gedankenexperiment mit der Katze in dem Kasten ab, bei dem die Katze erst tot oder lebendig ist, wenn wir den Deckel aufmachen. D.h. die Messung legt erst den Zustand fest, in dem sich die Katze befindet.

Messung von Lichtquanten

Die Messung von Lichtquanten haben einen angenehmen Vorteil, weil es hierzu eine gute Parallele in unserer makroskopischen Welt gibt – nämlich die Polarisation des Lichtes als elektromagnetische Welle. Dies ist vielleicht eingängiger, als den Lebenszustand einer Katze zu messen.

Wenn vor unpolarisiertes Licht mit verschiedenen Schwingungsebenen ein linearer Polarisationsfilter gehalten wird, erhält man danach linear polarisiertes Licht.

quantenkrypto-1

Mit Hilfe eines Polarisationsfilters kann die Schwingungsebene des Lichtes auf eine einzige Ebene festgelegt werden.

Wenn man nun vor das linear polarisierte Licht wiederum einen um 90 Grad gedrehten Polarisationsfilter hält, so wird das Licht ausgelöscht.

quantekrypto-2

Ein Polarisationsfilter kann makroskopisches, polarisiertes Licht auslöschen.

Auf Lichtquantenebene ist der sogenannte Spin polarisiert. Auch dieser Spin ist messbar – vergleichsweise der Schwingungsebene. Wir unterscheiden hier vertikalen und Diagonalen Spin.

quantenkrypto-3

Die Messung von Lichtquanten mit polarisiertem Spin kann zu nicht vorhersagbaren Ergebnissen führen.

Um den Spin eines polarisierten Lichtquantes zu bestimmen, muss er gemessen werden. Doch dabei läuft man Gefahr – genau wie bei dem obigen Beispiel – das Lichtquant zu „vernichten“ oder in einen neuen Polarisationszustand zu zwingen. Man kann mit Sicherheit nicht sagen, wie das Lichtquant vorher tatsächlich gewesen ist. Es gilt:

  • Wird vor ein Lichtquant mit „vertikal“ polarisierten Spin ein vertikaler Filter gehalten, so kommt das Lichtquant immer durch. Wie nehmen das als binäre 1.
  • Wird vor ein Lichtquant mit „horizontal“ polarisierten Spin ein vertikaler Filter gehalten, so kommt das Lichtquant niemals durch. Wir nehmen das als binäre 0.
  • Wird aber vor ein Lichtquant mit „diagonal“ polarisierten Spin ein vertikaler Filter gehalten, so kommt das Lichtquant entweder durch als vertikal polarisiertes Lichtquant (binäre 1) oder nicht (binäre 0). D.h. man misst eine 1 oder eine 0 und weiß aber nicht, dass man auch das andere hätte messen könne. Das nebenstehende Bild veranschaulicht dies. In dem Bild zeigt eine 0,5, dass man entweder 1 oder 0 gemessen haben kann.

 

Quantenkryptographie Beispiel

In diesem Beispiel polarisiert Alice Lichtquanten aus einer unpolarisierten Lichtquelle wie einer LED. D.h. sie erzeugt einen Strom aus polarisierten Lichtquanten. Sie selber wendet die Filter an und kennt somit die Filteranordnung und die Polarisierung. Diesen Strom sendet sie an Bob.

quantenkrypto-5

Ein ungestörter Schlüsseltausch zwischen Alice und Bob.

Bob muss sich selber frei überlegen, welche Filter er pro Lichtquant anwendet.

Alice teilt ihm mit, welche seiner Wahl richtig war. Nämlich der erste, der fünfte und der siebte Filter.

So nehmen Alice und Bob die erste, fünfte und siebte Stelle und erhalten beide den gleichen 3 bit langen Verschlüsselungskey.

Sie können sicher sein, dass nur sie beide diesen Verschlüsselungskey kennen.

Man in the middle

Nun hört Eve diese Kommunikation ab. Doch schon die Bezeichnung ist falsch. In der Quantenkryptographie kann man nicht einem vorbeiziehendem Strom zuhören. Um ihn zu sehen (oder zu hören) muss er gemessen und wieder neu ausgesendet werden. Und genau hier entsteht das Problem, weil Eve mit den Messungen die Polarisationszustände der Lichtquanten verändern wird.

quantenkrypto-0006

Der Schlüsseltausch wird von Eve gestört. Der Schlüssel wird durch Eve ungewollt verändert.

Auch Eve muss sich für eine Filteranordnung entscheiden mit der sie misst. Und genau hier entsteht das Problem.

Das fünfte Bit wurde von Alice vertikal polarisiert gesendet. Eve hat sich für einen diagonalen Filter entschieden. D.h. Eve kann eine 0 (\) messen – es kann aber auch sein, dass sie eine 1 (/) gemessen hat. Dies ist nicht ihre Entscheidung, sondern quantenmechanischer Zufall. In diesem Universum hat Eve nun eine 1 (/) gemessen, weswegen sie nun auch eine 1 (/) weitersendet. Da Bob das fünfte Bit mit einem diagonalen Filter miss, kann auch bei Bob eine 0 oder 1 gemessen werden.

Dadurch dass Eve messend und somit verändert in den Strom der Lichtquanten eingreift, schüttelt sie die Informationen durcheinander. In diesem Beispiel des 3-Bit-Schlüssels hat sie mit 75% Wahrscheinlichkeit den Schlüssel zerstört.

Alice wird mit ihrem originalen Schlüssel 101 etwas verschlüsseln was Bob mit dem Schlüssel 100 nicht entschlüsseln kann. Somit merken sie, dass die Verbindung abgehört wurde. Das Datenleck muss gefunden werden und der Schlüsseltausch kann neu beginnen.

funkmast

Gute Netzabdeckung, ein großes Angebot von preiswerten Smartphones und der Trend „bring your own device“ führten zu einem Paradigmenwechsel beim Thema Mehr-Faktor-Authentisierung.

Während vor einigen Jahre Mehr-Faktor- oder Zwei-Faktor-Authentisierung nur von großen Unternehmen angegangen wurde und solchen die einen hohen Schutzbedarf haben, wurde nun doch erkannt, dass Daten zu schützen, die Aufgabe eines jeden Geschäftsführers ist.

Gleichzeitig wird immer öfters auf die einfachereren und preiswerteren Varianten mit einem Smartphone-App, Email oder SMS zurückgegriffen. Doch muss man sich klarmachen, wieviel Sicherheit bei dem Einsatz solch schwacher Faktoren noch übrig bleibt.

Der Google Authenticator

Der Google Authenticator war eine der ersten Apps, die die OTP-Funktionalität bisheriger Hardware-Token in Software auf einem Smartphone abbildete. Der Google Authenticator unterstützt HOTP und TOTP Algorithmen. Alternative Apps sind FreeOTP (TOTP) oder HDE OTP (TOTP).

Die Nutztung des Smartphones als Authentisierungsdevice hat durchaus seine Berechtigung. Denn ein wichtiger Aspekt eines Besitztums zur Anmeldung ist, dass der Benutzer diesen mit sich trägt und nicht auf dem Schreibtisch liegen oder im Computer stecken lässt.

Das Seed (1)

Die OTP Algorithmen HOTP und TOTP arbeiten auf der Basis eines symmetrischen geheimen Schlüssels oder auch Seed, anhand dessen die Einmalpassworte berechnet werden. Das bedeutet aber auch, dass dieses Seed sicher geschützet werden muss. Ob dieses im Smartphone jeweils immer gegeben ist, darf – da das Smartphone auch nur ein leistungsstarker Computer mit veralteter Software und schlechtem Virenschutz ist – berechtigter Weise bezweifelt werden.

Das Seed (2)

Doch ein viel einfacherer Missbrauch ergibt sich aus dem bequemen Konzept zur Initialisierung der Smartphone App.

QrCode-TOTP

Dies geschieht über den QRCode, in dem das oben genannte Seed im Klartext enthalten ist. Der hier gezeigte QRCode enthält den folgenden Inhalt:

otpauth://totp/TOTP00017410?secret=O6LVCAVTS2IJ25NKXKOOGCNTJIOFNUXA&counter=1&digits=6&issuer=privacyIDEA

Dabei ist O6LVCAVTS2IJ25NKXKOOGCNTJIOFNUXA der geheime Schlüssel in sogenannter „Base32“ Schreibweise. Das mag für das menschliche Auge zwar merkwürdig und kompliziert aussehen, ist für den Computer oder das Smartphone aber tatsächlich Klartext.

Da dies ein zeibasierter OTP Token ist, wird jedes Gerät, das diesen QRCode scannt, immer den gleichen OTP-Wert anzeigen.

Ein Selbstversuch

Ich lade ein zum Selbstversuch: Haben Sie zwei Smartphones zur Hand? Installieren Sie auf beiden Smartphones den Google Authenitcator, HDE OTP oder FreeOTP. Einzige Voraussetzung für das Gelingen dieses Versuchs ist es, dass die Uhren der beiden Smartphones genau gehen.

Versuch 1

Scannen Sie den QRCode mit Ihrem Smartphone A und mit ihrem Smartphone B.

Starten Sie den Google Authenticator und beobachten Sie, dass auf beiden Smartphones jeweils das gleiche Einmalpasswort angezeigt wird. Zwei Mal das gleiche Einmalpasswort? Da stimmt doch was mit der Namensgebung nicht!

Versuch 2

Dieser Versuch verdeutlicht das Problem noch etwas mehr. Löschen Sie den Token von Smartphone B. Drucken Sie diese Seite mit dem QRCode aus und legen sie sie eine Woche in die Schublade.

Nach einer Woche gehen Sie zur Schublade und Scannen mit Smartphone B den QRCode. Smartphone B wird sofort die gleichen Einmalpassworte wie das Smartphone A anzeigen.

Das Problem im Unternehmen

Aufgrund der Struktur des TOTP-Algorithmus und des Rollout-Prinzips des Google Authenticators können Sie identische Kopien des Tokens erstellen. Auch noch nach Wochen und Monaten.

Ein Unternehmen, das die Passwortweitergabe unter Mitarbeitern verhindern will, darf sich bei der Einführung einer Zwei-Faktor-Lösung nicht blind auf diesen Algorithmus verlassen. Denn derselbe QRCode kann von allen Kollegen gescannt werden, so dass jeder Mitarbeiter den Token des anderen Kollegens hat. Schon wieder ist es dem Unternehmen nicht möglich, sicherzustellen, welcher Mitarbeiter denn nun wirklich hinter dem Account steckt. Die Idee des zweiten Faktors ist ausgehebelt.

Eine mögliche Lösung

Das Problem liegt hier im Rollout-Prozess, bei dem der geheime Schlüssel im Klartext übertragen wird. Ein besseres Rollout-Konzept weist der TiQR-Token auf. Dabei erzeugt das Smartphone den Schlüssel und scannt einen QRCode, in dem aber nur ein Registrierungslink enthalten ist, wohin der Schlüssel (über einen verschlüsselten Kanal) gesendet werden muss.

Doch dieser Rollout-Prozess erfordert auch eine aufwändigere Infrastruktur. Das Smartphone muss online sein und für den Registrierungslink muss ein verstrauenswürdiges Zertifikat vorhanden sein.

Gerade die Leichtigkeit des Rollouts im Falle des Google Authenticators haben gewiss zu seinem Erfolg beigetragen. Doch es bleibt nicht aus, dass man bei der Einführung einer Zwei-Faktor-Lösung sich Gedanken machen muss, wie die diversen Prozesse am besten umzusetzen sind. Schwächen in der Sicherheit sind nur dann tragbar, wenn man sich bewusst für diese entschieden hat und das Restrisiko akzeptieren und damit leben kann.