Ein Papier zum Projekt.<\/p>\n
SSL\/TLS is the most widely used encryption system in web communications, but far from being as intensively used as necessary to guarantee privacy.The X.509 certificate system should supply security and authentication, but has a lot of severe disadvantages inhibiting a broad use. In our project we try to upgrade X.509 to something we call „electronic identity“ with the objective to set up a common encryption scheme for all kind of communication in the internet.<\/span><\/span><\/p>\n Elektronische Identit\u00e4t<\/b><\/span><\/span><\/p>\n \n Gilbert Brands, Bernd Roellgen<\/p>\n Version 1.0 , 10. Juni 2016<\/p>\n Eine sichere elektronische Kommunikation erfordert eine End-2-end-Verschl\u00fcsselung und eine M\u00f6glichkeit, den Kommunikationspartner identifizieren zu k\u00f6nnen. SSL\/TLS mit X.509-Zertifikaten erm\u00f6glicht die Aushandlung geheimer Sitzungsschl\u00fcssel und ist f\u00fcr alle Kommunikationsarten einsetzbar. Das X.509-Modell weist bei zunehmender Verbreitung allerdings einige Merkmale auf, die der erforderlichen globalen Anwendbarkeit im Weg stehen. Wir erweitern das X.509-Zertifikatmodell zur \u201eElektronischen Identit\u00e4t\u201c, um diese M\u00e4ngel zu beseitigen. In diesem Artikel werden Aufbau und Handhabung der elektronischen Identit\u00e4t beschrieben.<\/span><\/p>\n Wir gehen davon aus, dass der Leser mit dem Grundprinzip des X.509-Zertifikatwesen vertraut ist. X.509 \u2013 Zertifikate in der Version 3 (aktuelle Definition siehe https:\/\/tools.ietf.org\/html\/rfc5280<\/a>) enthalten Angaben zum Aussteller, Inhaber, die \u00f6ffentlichen Schl\u00fcssel des Inhabers und Informationen zum Verwendungsbereich. Die aktuelle Definition eines X.509v3-Zertifikats in der ASN.1-Notation (RFC 5280) ist:<\/span><\/p>\n Certificate ::= SEQUENCE {<\/b><\/span><\/span><\/p>\n tbsCertificate TBSCertificate,<\/b><\/span><\/span><\/p>\n signatureAlgorithm AlgorithmIdentifier,<\/b><\/span><\/span><\/p>\n signatureValue BIT STRING }<\/b><\/span><\/span><\/p>\n TBSCertificate ::= SEQUENCE {<\/b><\/span><\/span><\/p>\n version [0] EXPLICIT Version DEFAULT v1,<\/b><\/span><\/span><\/p>\n serialNumber CertificateSerialNumber,<\/b><\/span><\/span><\/p>\n signature AlgorithmIdentifier,<\/b><\/span><\/span><\/p>\n issuer Name,<\/b><\/span><\/span><\/p>\n validity Validity,<\/b><\/span><\/span><\/p>\n subject Name,<\/b><\/span><\/span><\/p>\n subjectPublicKeyInfo SubjectPublicKeyInfo,<\/b><\/span><\/span><\/p>\n issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,<\/b><\/span><\/span><\/p>\n — If present, version MUST be v2 or v3<\/b><\/span><\/span><\/p>\n subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,<\/b><\/span><\/span><\/p>\n — If present, version MUST be v2 or v3<\/b><\/span><\/span><\/p>\n extensions [3] EXPLICIT Extensions OPTIONAL<\/b><\/span><\/span><\/p>\n — If present, version MUST be v3<\/b><\/span><\/span><\/p>\n }<\/b><\/span><\/span><\/p>\n Version ::= INTEGER { v1(0), v2(1), v3(2) }<\/b><\/span><\/span><\/p>\n CertificateSerialNumber ::= INTEGER<\/b><\/span><\/span><\/p>\n Validity ::= SEQUENCE {<\/b><\/span><\/span><\/p>\n notBefore Time,<\/b><\/span><\/span><\/p>\n notAfter Time }<\/b><\/span><\/span><\/p>\n Time ::= CHOICE {<\/b><\/span><\/span><\/p>\n utcTime UTCTime,<\/b><\/span><\/span><\/p>\n generalTime GeneralizedTime }<\/b><\/span><\/span><\/p>\n UniqueIdentifier ::= BIT STRING<\/b><\/span><\/span><\/p>\n SubjectPublicKeyInfo ::= SEQUENCE {<\/b><\/span><\/span><\/p>\n algorithm AlgorithmIdentifier,<\/b><\/span><\/span><\/p>\n subjectPublicKey BIT STRING }<\/b><\/span><\/span><\/p>\n Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension<\/b><\/span><\/span><\/p>\n Extension ::= SEQUENCE {<\/b><\/span><\/span><\/p>\n extnID OBJECT IDENTIFIER,<\/b><\/span><\/span><\/p>\n critical BOOLEAN DEFAULT FALSE,<\/b><\/span><\/span><\/p>\n extnValue OCTET STRING<\/b><\/span><\/span><\/p>\n — contains the DER encoding of an ASN.1 value<\/b><\/span><\/span><\/p>\n — corresponding to the extension type identified<\/b><\/span><\/span><\/p>\n — by extnID<\/b><\/span><\/span><\/p>\n }<\/b><\/span><\/span><\/p>\n Ein Inhaber-Zertifikat wird vom Aussteller, einer \u201eCertificate Authority (CA)\u201c, signiert und ist damit nicht f\u00e4lschbar. Die CA garantiert, dass der Inhaber die angegebene Identit\u00e4t besitzt und keine F\u00e4lschung eines Angreifers vorliegt. Der Nutzer soll der CA-Signatur in diesem Sinn vertrauen. Die CA kann zus\u00e4tzlich Listen \u00fcber vorzeitig ung\u00fcltig gewordene Zertifikate oder deren aktuellen Arbeitsstatus f\u00fchren und soll damit ebenfalls zur Sicherheit beitragen.<\/p>\n Im Prinzip f\u00fcr alle Arten der Kommunikation zur Schl\u00fcsselaushandlung\/Verschl\u00fcsselung grunds\u00e4tzlich geeignet, <\/span>weist das Arbeitsprinzip entscheidende Schw\u00e4chen auf, die bereits auf der Anwendungsschiene HTTP \u2192 E-Mail zum Versagen f\u00fchren.<\/p>\n Die CA-Zertifikate m\u00fcssen zur \u00dcberpr\u00fcfung eines Zertifikats auf dem Nutzerrechner vorhanden sein und sind in der Regel heute vorinstalliert. Gegen 50 oder mehr CA mit teilweise bis zu 50 verschiedenen Stammzertifikaten, die jeweils Unterschiedliches garantieren sollen, sind jedoch selbst f\u00fcr Fachleute nicht mehr \u00fcberschaubar.<\/p>\n<\/li>\n Grunds\u00e4tzlich ist es m\u00f6glich, mit eigenen CA\/Zertifikaten zu arbeiten; viele Anwendungen lassen das jedoch selbst bei korrektem Vorgehen nicht oder nur eingeschr\u00e4nkt zu und \u201ewarnen\u201c den Nutzer in \u00fcbertriebenem Ma\u00dfe vor einer Gef\u00e4hrdung, die sich angesichts der Undurchschaubarkeit der Zertifikate nur graduell von der vom etablierten CA-Wesen ausgehenden Gef\u00e4hrdung unterscheidet.<\/span><\/p>\n<\/li>\n CA verlangen f\u00fcr ihre Dienste \u00fcberproportional hohe Geb\u00fchren und wiederkehrenden Aufwand, was insbesondere den Einsatz der Verschl\u00fcsselung im Privatsektor wirkungsvoll verhindert.<\/p>\n<\/li>\n Der Nutzer wird im X.509-System nahezu vollst\u00e4ndig seiner Eigenverantwortung beraubt. Er hat im Grunde keine M\u00f6glichkeit, selbst die Schutzmechanismen festzulegen und deren Einhaltung zu kontrollieren. Diese Entm\u00fcndigung,<\/span> zusammen mit den Kosten, <\/span>d\u00fcrfte vielen potentiellen privaten Nutzern den Rest an Motivation nehmen, sich \u00fcberhaupt mit der Sicherheitsfrage auseinander zu setzen.<\/p>\n<\/li>\n<\/ul>\n SSL\/TLS-Anwendungen nutzen mehrere Komponenten:<\/p>\n Eine Verschl\u00fcsselungsbibliothek stellt die notwendigen Komponenten zur Pr\u00fcfung von Zertifikaten oder zur Vereinbarung von Schl\u00fcsseln \/ zur Verschl\u00fcsselung zur Verf\u00fcgung. H\u00e4ufig genutzte Bibliotheken sind OpenSSL oder Botan-SSL. Die Bibliotheken arbeiten in der Regel neutral, d.h. sie werten die Informationen nach den definierten Regeln aus und geben die Ergebnisse zur weiteren Auswertung an die Hauptinstanz weiter.<\/p>\n<\/li>\n Die Hauptinstanz stellt die Schnittstelle zum Nutzer dar. Ergebnisse der Auswertung der Bibliothek werden hier weiter verarbeitet und dem Nutzer nach weiteren Regeln pr\u00e4sentiert.<\/p>\n<\/li>\n Applets erlauben in geringem Umfang eine Einflussnahme des Nutzers (Best\u00e4tigung von Ausnahmen, Installation von CA und eigenen Zertifikaten), sind jedoch oft wenig nutzerfreundlich, versteckt oder f\u00fchren manche Nutzervorgaben trotz Best\u00e4tigung nicht aus.<\/p>\n<\/li>\n<\/ul>\n Die breite Verf\u00fcgbarkeit von SSL\/TLS und das an sich sehr gute Hintergrundkonzept bieten an, auf dem Konzept aufzubauen und auf die Definition von etwas vollst\u00e4ndig Neuem zu verzichten. Das EI-Konzept nutzt daher konsequent die vorhandene Technik (siehe 1.3 ):<\/p>\n Bibliotheken werden unge\u00e4ndert genutzt. Optionen zur Hinzunahme weiterer Algorithmen (z.B. der quantencomputersichere RVB-Algorithmus) entstehen jedoch zus\u00e4tzlich.<\/p>\n<\/li>\n Hauptinstanzen werden \u201eas is\u201c genutzt – <\/span>in der Erwartung, dass gewisse anf\u00e4ngliche M\u00e4ngel in der Nutzerfreundlichkeit bei Akzeptanz des EI-Konzepts verschwinden.<\/p>\n<\/li>\n Eigenen Applets werden verwendet, um die Nutzerfreundlichkeit zu vergr\u00f6\u00dfern und die Besonderheiten des EI-Konzeptes umzusetzen.<\/p>\n<\/li>\n<\/ul>\n X.509 und EI sind daher gemeinsam einsetzbar, der Softwareaufwand ist minimal und beschr\u00e4nkt sich auf wenige zus\u00e4tzliche Komponenten.<\/p>\n Das EI-Konzept greift die erkannten M\u00e4ngel des urspr\u00fcnglich f\u00fcr das Onlineshopping konzipierten X.509-Schemas auf, die einem Einsatz f\u00fcr globale Verschl\u00fcss<\/span>elung derzeit im Weg stehen. Das wesentliche Prinzip besteht darin, dem Nutzer die Kontrolle \u00fcber seine Sicherheit selbst in die Hand zu geben und die Kosten zu beseitigen, d.h.<\/p>\n Es existiert keine zentrale Signaturinstanz<\/b>, d.h. es wird nichts garantiert bzw. der Nutzer ist nicht gehalten\/gezwungen, Instanzen\/Signaturen zu vertrauen, die er nicht versteht.<\/p>\n<\/li>\n Es existiert eine nutzerindividuelle Vertrauensdatenbank<\/b>, d.h. die Kontrolle und auch die Verantwortung liegt komplett beim Nutzer, der selbst bestimmt, welcher EI er vertraut.<\/p>\n<\/li>\n<\/ul>\n Ziele des EI-Schemas sind<\/p>\n die grunds\u00e4tzliche Verschl\u00fcsselung jeglichen Informationsaustausches, d.h. HTTP, E-Mail, Telefonie, Instant Messaging, Ger\u00e4tekommunikation, \u2026<\/p>\n<\/li>\n die skalierbare Authentifizierung des Kommunikationspartners durch automatisierte Verfahren oder unter Mitwirkung des Nutzers f\u00fcr Sicherheitsbereiche,<\/p>\n<\/li>\n die Beschr\u00e4nkung der Kommunikation in Sicherheitsbereichen auf definierte Gruppen von Ger\u00e4ten,<\/p>\n<\/li>\n dem grundlegenden Unterschied zwischen den Bed\u00fcrfnissen der Anwender beim Onlineshopping und dem Sicherheitsbed\u00fcrfnis der Anwender beim F\u00fchren privater Kommunikation Rechnung zu tragen.<\/span><\/p>\n<\/li>\n<\/ul>\n Dies kann nat\u00fcrlich nur erreicht werden, wenn die Nutzerverantwortung mit einer einfachen und \u00fcbersichtlichen Bedienung verbunden ist. Diese ist gegeben, wenn<\/p>\n aufw\u00e4ndigere Arbeitsschritte einmalig im Rahmen einer Inbetriebnahme und gef\u00fchrt erfolgen. Nutzer sind es gewohnt, bei der Inbetriebnahme von Ger\u00e4ten bestimmte Inbetriebnahmeschritte auszuf\u00fchren, so dass einige zus\u00e4tzliche Schritte f\u00fcr das EI-Konzept sich nicht akzeptanzmindernd auswirken.<\/p>\n<\/li>\n die laufende Funktion weitgehend automatisiert ist und den Nutzer nicht mit h\u00e4ufigen Aktionen bel\u00e4stigt. St\u00e4ndig notwendige Zusatzaktionen f\u00fchren in der Regel zum Abschalten der Funktionalit\u00e4t, gelegentliches Nachfragen erinnert den Nutzer an seine Eigenverantwortlichkeit und wird akzeptiert.<\/p>\n<\/li>\n klare und einfache Steuerungselemente vorhanden sind, die immer im Blickfeld des Nutzers liegen, ihn im laufenden Betrieb an seine Eigenverantwortlichkeit erinnern und durch ihre Pr\u00e4senz verhindern, dass die Funktionalit\u00e4t in Vergessenheit ger\u00e4t.<\/p>\n<\/li>\n einfache und umfassende M\u00f6glichkeiten vorhanden sind, die eigenen Sicherheitsanforderungen in den Systemfunktionen zu definieren.<\/p>\n<\/li>\n<\/ul>\n Die Inhalte einer EI sind mit dem Bezug auf X.509 weitgehend vorgegeben. Eine Reihe von wichtigen Inhalten f\u00fcr das X.509-Management sind im Bereich Extensions<\/b> untergebracht. Grunds\u00e4tzlich ist dieser Bereich ein offener Datenbereich, d.h. Datenfelder, die f\u00fcr das EI-Management zus\u00e4tzlich zu den X.509-Definitionen notwendig sind, k\u00f6nnen in diesem Bereich untergebracht werden und sollten als unbekannte Optionen vom X.509-Management ignoriert werden.<\/p>\n Einige X.509-Extensions sind f\u00fcr das EI-Management nicht notwendig oder werden ggf. etwas anders interpretiert. Vom Grundsatz her sollte das Fortlassen oder Multiplizieren bestimmter Extension-Felder in den meisten F\u00e4llen auch f\u00fcr X.509 unkritisch sein.<\/p>\n Anwendungen genie\u00dfen jedoch einen gewissen Interpretationsspielraum der Regeln. Wir vereinbaren daher anwendungsabh\u00e4ngig, dass die Inhalte im Zweifelsfall an X.509 ausgerichtet werden, um eine Koexistenz zu erm\u00f6glichen. Korrekturen oder Erg\u00e4nzungen sind nach vorhandenen M\u00f6glichkeiten auszuf\u00fchren.<\/p>\n Elektronische Identit\u00e4ten besitzen kein Verfallsdatum<\/b> und sind unbegrenzt g\u00fcltig. Wird eine EI aus irgendeinem Grund unbrauchbar oder durch eine andere ersetzt, wird dies durch das EI-Management erkannt (siehe unten). Zentrale Instanzen wie eine Revocation List oder OCSP sind nicht prim\u00e4rer Bestandteil des EI-Konzeptes, k\u00f6nnen aber gleichwohl als externe Dienstleistung angeboten und ber\u00fccksichtigt werden. Weitere Details werden bei den verschiedenen Anwendungsf\u00e4llen diskutiert.<\/p>\n EI sind an Einheiten (Ger\u00e4te, Nutzer, Software) und nicht an Funktionen (Signieren, Schl\u00fcsselaushandlung) wie bei X.509 gebunden. Eine EI kann f\u00fcr jeden Zweck eingesetzt werden, kennzeichnet aber immer die Einheit, f\u00fcr die sie eingesetzt wird (zur Gew\u00e4hrleistung der Einsatzm\u00f6glichkeit f\u00fcr bestimmte Zwecke siehe Bemerkungen in 2.4 ). Jede Einheit erh\u00e4lt bei Inbetriebnahme eine EI; die Erzeugung einer EI ist Bestandteil der<\/span> Inbetriebnahmeprozedur. Da jede Einheit, die in Kommunikationsvorg\u00e4ngen beteiligt sein kann, eine EI besitzt, ist eine generelle und globale Verschl\u00fcsselungsm\u00f6glichkeit sichergestellt. Maschinen oder Nutzer werden hierdurch wiedererkennbar (Identit\u00e4tsprinzip).<\/p>\n Jede Einheit besitzt einen UniqueIdentifier<\/b> (extensions v3; ein Zufallsstring mit hinreichender L\u00e4nge, um globale Eindeutigkeit zu garantieren), der lebenslang g<\/span>\u00fcltig ist. Die Seriennummer wird f\u00fcr die Wiedererkennung und Verifizierung w\u00e4hrend der Lebensdauer verwendet (siehe 5 ).<\/p>\n Ein PC besitzt eine M<\/span>aschinen-EI, f\u00fcr den Inhaber wird bei Inbetriebnahme zus\u00e4tzlich eine Nutzer-EI erstellt oder eine bereits vorhandene Nutzer-EI verwendet.<\/span> Bestimmte Softwarekomponenten k\u00f6nnen mit eigenen EI ausgestattet sein. Auf einer funktionellen Einheit k\u00f6nnen daher mehrere unterschiedliche EI installiert sein. Welche EI f\u00fcr welchen Zweck genutzt wird, wird durch ein Regelwerk festgelegt. Implizit kann durch die Kopplung einer EI an eine Einheit ein bestimmter Nutzungszweck resultieren.<\/p>\n Ein Nutzer kann aus verschiedenen Gr\u00fcnden mehrere EI besitzen. Die korrekte Zuordnung einer EI zu einem Kommunikationsvorgang liegt in der Verantwortung des Nutzers. Das entspricht dem Prinzip, unterschiedliche Kennungen\/Kennworte f\u00fcr verschiedene Serverkonten zu verwenden und ist Nutzern methodisch vertraut.<\/p>\n Im weltweiten Netz ist Kommunikation mit jedem anderen Teilnehmer m\u00f6glich. In vielen F\u00e4llen kennen sich die Teilnehmer zun\u00e4chst nicht. F\u00fcr die Realisierung der Verschl\u00fcsselung einer Kommunikation dienen globale EI<\/b>. Globale EI sind selbstsigniert<\/b> und k\u00f6nnen mit beliebigen anderen globalen EI eine verschl\u00fcsselte Verbindung aufbauen.<\/p>\n SSL\/TLS sieht zwei Mechanismen der Verbindungsinitiierung vor:<\/p>\n Die Verschl\u00fcsselung wird nur mit Hilfe der Server-EI realisiert; die Client-EI ist nicht beteiligt. Soll der Server den Client ebenfalls erkennen, werden Login-Prozeduren mit Name\/Kennwort-Kombination oder \u2013 im Fall bereits bestehender Kontakte \u2013 Cookies eingesetzt.<\/p>\n<\/li>\n Bei der Initiierung werden beide EI ausgetauscht, so dass Server und Client den jeweiligen Partner erkennen. Name\/Kennwort entf\u00e4llt.<\/p>\n<\/li>\n<\/ol>\n Ist anwendungsabh\u00e4ngig eine Authentifizierung des Clients notwendig, wird im Rahmen des EI-Konzeptes die M\u00f6glichkeit 2 \u2013 Austausch beider EI \u2013 angestrebt. Dies f\u00fchrt zu<\/p>\n Vereinfachung der Anmeldeprozedur, weil ein Nutzer keine Name\/Kennwort-Kombination eingeben muss, sowie<\/p>\n<\/li>\n zu einer h\u00f6heren Sicherheit, weil ein Angreifer im Falle einer Man-in-the-Middle-Attacke keine nutzbaren Informationen erh\u00e4lt, die es ihm erm\u00f6glichen w\u00fcrden, sich zu einem sp\u00e4teren Zeitpunkt ohne Beteiligung des Nutzers beim Server anzumelden.<\/p>\n<\/li>\n<\/ul>\n Ein Kernproblem der Sicherheit ist die Verriegelung eines Netzbereiches gegen frem<\/span>des Eindringen. Die Anwendungsf\u00e4lle steigen mit zunehmender Vernetzung technischer Ger\u00e4te, w\u00e4hrend eine Verschl\u00fcsselung h\u00e4ufig nicht stattfindet und die Gefahr durch Fehlkonfiguration des Netzwerkmamangements steigt.<\/p>\n Lokale EI<\/b> stellen eine einfache M\u00f6glichkeit der Absicherung gegen Fremdzugriffe dar. Lokale EI sind im Gegensatz zu globalen EI durch eine andere EI fremdsigniert<\/b> und werden immer zusammen mit der EI des Signaturgebers gespeichert, so dass Kontrollen wie bei X.509-CA-Rootzertifikaten m\u00f6glich sind. Lokale EI unterliegen folgenden Einsatzregeln:<\/p>\n Lokale EI k\u00f6nnen nur mit anderen lokalen EI, die von der gleichen EI signiert sind, oder mit der signaturgebenden EI eine verschl\u00fcsselte Verbindung aufbauen. Alle anderen Verbindungen werden grunds\u00e4tzlich abgelehnt.<\/p>\n<\/li>\n Bei Einsatz lokaler EI ist beidseitiger Austausch der EI zwingend vorgesehen, um die Absicherung des Netzwerkbereiches zu garantieren.<\/p>\n<\/li>\n<\/ul>\n Mittels lokaler EI ist das Konzept der Public Key Infrastructure im industriellen und privaten Bereich problemlos realisierbar. Die Absicherung, dass nur Ger\u00e4te miteinander kommunizieren, die dazu berechtigt sind, erfolgt bereits auf Netzwerkebene und nicht erst auf Anwendungsebene (zus\u00e4tzliche Authentifizierungsma\u00dfnahmen auf der<\/span> Anwendungsebene sind dadurch nicht ausgeschlossen).<\/p>\n Auch im privaten Bereich nimmt die Automatisierung von Hausger\u00e4ten zu. Viele Ger\u00e4te sind auch aus dem Internet erreichbar, um dem Nutzer Steuerungsm\u00f6glichkeiten zu geben. Eine sichere Konfiguration ist aber oft schwierig, was die Gefahr beinhaltet, dass Angreifer die Ger\u00e4te manipulieren (Abschalten der Alarmanlage, des Eisschrankes, usw.). Bei der Inbetriebnahme generiert der Nutzer mittels seiner EI ein<\/span>e lokale Ger\u00e4te-EI. Das neue Ger\u00e4t kann nun ausschlie\u00dflich EI-gesteuert mit dem Nutzer oder mit anderen Ger\u00e4ten des Nutzers kommunizieren, ohne dass die anderen Ger\u00e4te dazu neu konfiguriert werden m\u00fcssen.<\/p>\n Mit dem EI-Konzept erh\u00e4lt jedes steuerungsf\u00e4hige Ger\u00e4t, d.h. die Kommunikation ist zwangsverschl\u00fcsselt und nicht mehr offen, wie dies heute meist der Fall ist. Im Unternehmensbereich kann das Konzept hierarchisch eingesetzt werden. Sind beispielsweise zwei Unternehmensbereich A und B separat als PKI aufzubauen, wird eine EI genutzt, zwei Zwischen-EI zu signieren, die wiederum die Ger\u00e4te der Bereiche signieren. Kommunikationen zwischen den Bereichen sind dann nur \u00fcber Instanzen, die \u00fcber die Zwischen-EI verf\u00fcgen, m\u00f6glich. Diese wiederum sind gegen die weitere \u00d6ffentlichkeit durch die Prim\u00e4r-EI abgesichert.<\/p>\n Da keine Signatur durch eine \u00fcbergeordnete Instanz vorhanden ist, kann der Nutzer nicht sicher sein, dass die Daten auf der EI tats\u00e4chlich den gew\u00fcnschten Kommunikationspartner kennzeichnen. Der Nutzer ist<\/span> selbst daf\u00fcr verantwortlich, dies<\/span> fallweise festzustellen. Er wird durch implizite Verifizierung durch das System unterst\u00fctzt.<\/p>\n Bei gelegentlich genutzten Kontakten, insbesondere bei Beschr\u00e4nkung des EI-Austausches auf die EI des Servers, ist eine echte Authentifizierung in der Regel nicht notwendig. Die meisten Anwendungen, die nach dem X.509-Schema arbeiten, fordern bei selbst signierten EI eine Best\u00e4tigung des Nutzers an, die EI anzunehmen. Gelegentliche Kontakte k\u00f6nnen daher nach dem Schema f\u00fcr implizite Authentifizierung bearbeitet werden, wobei zur Beschr\u00e4nkung der Datenbankgr\u00f6\u00dfe die EI wieder entfernt werden kann, wenn eine erneute Nutzung in einem vorgegebenen Zeitraum nicht erfolgt.<\/p>\n F\u00fcr die meisten Kontakte ist eine vollst\u00e4ndige Authentifizierung nicht oder erst zu einem sp\u00e4teren Zeitpunkt notwendig, wenn wichtige Transaktionen abgewickelt werden. Die Authentifizierung kann implizit mit steigendem Sicherheitsniveau erfolgen.<\/p>\n Dazu werden die EI in einer Nutzerdatenbank gespeichert, in der auch jeder weitere Kontakt notiert wird. \u201eKontakt\u201c in diesem Sinn ist anwendungsabh\u00e4ngig eine URL, eine IPv4\/6-Adresse, eine E-Mail-Adresse, eine Telefonnummer<\/span>, ein Instant-Messaging Alias u<\/span>sw.<\/p>\n Da eine EI nicht verifiziert wird, sind verschiedene Angriffsm\u00f6glichkeiten vorhanden. Beispielsweise kann ein Angreifer versuchen, einen Kontakt umzuleiten und als Man-in-the-Middle die Kommunikation abzugreifen. Dazu muss er allerdings eine eigene EI verwenden, da die originalen privaten Daten nicht zur Verf\u00fcgung stehen. Da die EI notiert werden, ist der Angreifer gezwungen, jeden Kontakt ohne Ausnahme in dieser Weise zu infiltrieren. Gelingt ihm das nicht, bemerkt das EI-Management das Vorlegen einer anderen EI f\u00fcr den gleichen Kontakt und gibt eine entsprechende Warnmeldung, dass m\u00f6glicherweise ein Angriff vorliegt, an die Anwendung heraus. Wenn die Kommunikation global und vollst\u00e4ndig verschl\u00fcsselt wird, ist es selbst mit extrem hohem Ressourcenaufwand kaum m\u00f6glich, solche Angriffe erfolgreich durchzuhalten.<\/p>\n Werden \u00fcber einen l\u00e4ngeren Zeitraum wiederholt Verbindungen mit einem Kontakt hergestellt, ohne dass es zu Auff\u00e4lligkeiten kommt, steigt die Vertrauensw\u00fcrdigkeit der EI.<\/p>\n Beispiel Shopkontakt: kommt es nach vielen Besuchen einer Seite zu einem Kauf, so kann man die Summe, um die es geht, in Relation zum Aufwand eines m\u00f6glichen Angriffs stellen. Kauft man nach 10 Besuchen Waren im Wert von 100 \u20ac, steht der m\u00f6gliche Gewinn f\u00fcr einen Angreifer in keinem Verh\u00e4ltnis zum Aufwand. Werden nach 5 Besuchen Waren im Wert von 50.000 \u20ac gekauft, empfiehlt es sich f\u00fcr den Nutzer, den Kontakt zus\u00e4tzlich zu verifizieren (den Aufwand sollte er aber auch im X.509-Schema bei diesen Gr\u00f6\u00dfenordnungen treiben).<\/p>\n Die Speicherung jeder fremden EI in einer Datenbank auf dem Nutzersystem gespeichert ist m\u00f6glich, da selbst die von einem Nutzer beim Surfen im Internet angesprochenen EI im IT-Ma\u00dfstab relativ begrenzt sind. Anwendungsabh\u00e4ngig kann die Speicherung auf bestimmte Umst\u00e4nde begrenzt werden (siehe 4.1 ).<\/p>\n F\u00fcr viel besuchte Webserver ist eine Speicherung jedes Kontakts unwichtig, es sei denn, der Serverbetreiber w\u00fcnscht dies aus anderen Gr\u00fcnden. Die Speicherung f\u00fcr Identifizierungszwecke kann auf das Einrichten eines Kundenkontos beim Betreiber beschr\u00e4nkt werden.<\/p>\n Die Anzahl der Kontakte, die bereits bei den ersten Datenaustauschen eine definitive Authentifizierung ben\u00f6tigen, ist relativ begrenzt. Die ausgetauschten EI k\u00f6nnen auf einem unabh\u00e4ngigen Weg verifiziert und in der Datenbank als \u201everifiziert\u201c markiert werden. In vielen F\u00e4llen beschr\u00e4nkt sich dieser Vorgang auf die Einrichtung eines Kontos bzw. Inbetriebnahmen, d.h. die definitive Authentifizierung ist kein die Nutzerfreundlichkeit einschr\u00e4nkender Vorgang.<\/p>\n Beispiel Internetbanking. Im Rahmen der Konteneinrichtung erh\u00e4lt der Kunde die notwendigen Daten, um sich in seinem Konto einzuloggen. Diese beinhalten die Verifizierung der Bank-EI. Im Gegenzug kann der Kunde zur Erleichtung des Einloggens seine EI der Bank in einem \u00e4hnlichen Verfahren bekannt machen, so dass die Name\/Kennwort-Kombination entf\u00e4llt.<\/p>\n Im Sinne des X.509-Schemas kann die Verifizierung einer EI auch als Dienstleistung durch eine Authority angeboten werden. Da die EI selbstsigniert sind, f\u00e4llt eine Signatur durch die Authority aus. Die EI k\u00f6nnen von der Authority aber durch einen gesicherten LDAP-Dienst ausgeliefert werden (bei PGP-Zertifikaten \u00fcblich und eingef\u00fchrt).<\/p>\n Die Dienstleistung kann Widerufslisten (CRL) und OCSP-Dienste (Online Certificate Status Protocol)<\/span> umfassen. Diese Dienstleistungen k\u00f6nnen mit den Standardprozeduren f\u00fcr X.509 angeboten werden.<\/p>\n Datenfelder f\u00fcr die notwendigen Informationen \u00fcber die Authority sind in den X.509-Extensions vorhanden bzw. anlegbar, ohne die Kompatibilit\u00e4t einzuschr\u00e4nken. Es ist jedoch anzumerken, dass hierdurch die Problematik der X.509-Zertifikate (welches Vertrauen verdient eine Authority) wieder eingef\u00fchrt wird.<\/p>\n In einigen Anwendungsbereichen sind auch Web-of-Trust-Dienste denkbar, d.h. eine EI wird durch andere Nutzer signiert und ein Nutzer vertraut einer EI, weil der einem der Signierer vertraut. Das Schema ist im PGP-Bereich eingef\u00fchrt und kann ggf. dort entlehnt werden.<\/p>\n Solche zus\u00e4tzlichen Mechanismen sind nur mit einigem Softwareaufwand zu realisieren, der Nutzen scheint uns dar\u00fcber hinaus gering bis kontraproduktiv, da der Nutzer wieder teilweise aus seiner Verantwortung entlassen wird. Wir gehen daher (vorl\u00e4ufig) nicht weiter auf diese Optionen ein.<\/p>\n Die Inhalte einer EI k\u00f6nnen sich bei konstantem UniqueIdentifier<\/b> aus unterschiedlichen Gr\u00fcnden \u00e4ndern:<\/p>\n \u00c4nderung wesentlicher Daten der Inhaber (z.B. Name, Anschrift, E-Mail-Adressen usw.),<\/p>\n<\/li>\n Kompatibilit\u00e4tsanpassungen an das X.509-Schema,<\/p>\n<\/li>\n Erweiterungen\/\u00c4nderung des EI-Schemas (z.B. lokale \u2194 globale EI, andere Zuweisung einer lokalen EI),<\/p>\n<\/li>\n Ber\u00fccksichtigung neuer technischer Erkenntnisse (z.B. \u00c4nderung der Algorithmen oder Schl\u00fcssel).<\/p>\n<\/li>\n<\/ul>\n Die EI erh\u00e4lt mit Ausstellung die Seriennummer 1. Bei jeder \u00c4nderung wird die Seriennummer inkrementiert. Das Feld validFrom<\/b> enth\u00e4lt das Datum der \u00c4nderung. Die alte EI-Version bleibt g\u00fcltig, da sie kein Ablaufdatum enth\u00e4lt. Der Inhaber beh\u00e4lt alle EI-Versionen in seiner Datenbank. F\u00fcr den Umgang mit den EI-Versionen gelten folgende Regeln:<\/p>\n Der Empf\u00e4nger identifiziert eine \u00fcbertragene EI anhand des Fingerprints (Hashwert; Verhindern von F\u00e4lschungen).<\/p>\n<\/li>\n Wird eine Abweichung festgestellt, muss die \u00fcbertragene EI eine h\u00f6here Seriennummer und ein sp\u00e4teres G\u00fcltigkeitsdatum aufweisen. \u00c4ltere EI werden nicht akzeptiert, eine ge\u00e4nderte EI mit gleicher Seriennummer wie die vorhandene wird als T\u00e4uschungsversuch gewertet.<\/p>\n<\/li>\n Ist die erhaltene EI neuer, sendet der Empf\u00e4nger die Seriennummer der bei ihm gespeicherten EI an den Absender. Der Absender sendet im Gegenzug alle kompletten EI ab der vom Empf\u00e4nger vorgelegten Seriennummer bis zur neuen. Der Besitz des privaten Schl\u00fcssels f\u00fcr jede EI wird Challenge-Response-Verfahren nachgewiesen.<\/p>\n<\/li>\n Bei Fehlerfreiheit des Nachweises wird die alte EI beim Empf\u00e4nger durch die neue ersetzt.<\/p>\n<\/li>\n<\/ul>\n Das Verfahren verifiziert automatisch die ge\u00e4nderte EI. Da die Kenntnis der privaten Schl\u00fcssel f\u00fcr s\u00e4mtliche EI ab der bekannten notwendig ist, kann ein Angreifer weder eine fremde EI \u00fcbernehmen noch eine DoS-Attacke zum Ung\u00fcltigwerden einer EI durchf\u00fchren.<\/p>\n Fehlerf\u00e4lle im Lifecycle einer EI sind<\/p>\n Verlust des privaten Schl\u00fcssels,<\/p>\n<\/li>\n Kompromittierung des privaten Schl\u00fcssels.<\/p>\n<\/li>\n<\/ul>\n Bei Verlust<\/b> des privaten Schl\u00fcssels kann ein erfolgreiches Upgrade auf eine neue EI-Version nach 5.1 nicht durchgef\u00fchrt werden. Die EI wird durch eine neue EI (einschlie\u00dflich neuem UniqueIdentifier<\/b>) ersetzt, die alte EI wird nicht mehr verwendet. Bestehende Vertrauensverh\u00e4ltnisse bei Kontakten sind neu aufzubauen.<\/p>\n Bei Kompromittierung<\/b> des privaten Schl\u00fcssels kann der EI-Inhaber nach 5.1 eine neue EI-Version mit ge\u00e4ndertem privaten Schl\u00fcssel generieren und durch seine Kontakte durch Verbinden mit der neuen Version upgraden.<\/p>\n Wird die neue EI-Version vom Kommunikationspartner akzeptiert, ist die Sicherheit aufgrund der Regeln nach 5.1 wiederhergestellt. Der Angreifer, der im Besitz des alten Schl\u00fcssels ist, kann damit zumindest bei diesen Kontakten nichts mehr anfangen.<\/p>\n<\/li>\n Wird die neue EI-Version vom Kommunikationspartner nicht akzeptiert, hat der Angreifer bereits selbst eine neue Version dort verifiziert. Die EI ist folglich erfolgreich gestohlen worden, und der Kommunikationspartner ist auf anderem Weg davon in Kenntnis zu setzen.<\/p>\n<\/li>\n<\/ul>\n Die Vorgehensweise und die Konsequenzen entsprechen denen kompromittierter Name\/Kennwort-Kombinationen.<\/p>\n Im Sinne des X.509-Schemas kann die Ausgabe einer neuen EI auch als Dienstleistung durch eine Authority angeboten werden. Zur reinen Kommunikation mit einer kleinen Gruppe m\u00f6glicher Gespr\u00e4chspartner ist dies jedoch nicht sinnvoll.<\/span><\/p>\n Ein Nutzer verwendet in der Regel verschiedene Ger\u00e4te: PC, Notebook, Tablet, Handy. Fallweise k\u00f6nnen sogar Fremdger\u00e4te zum Einsatz kommen: Internet-Cafe, Betriebs-Arbeitsplatz, Freunde. Zu verwalten sind <\/span><\/p>\n die EI des Nutzers,<\/span><\/p>\n<\/li>\n die Kontaktdaten und EI der Kommunikationspartner.<\/span><\/p>\n<\/li>\n<\/ul>\n Welche Daten gespeichert werden, um die gew\u00fcnschten Funktionen zu erf\u00fcllen, wird im Rahmen der Diskussion der einzelnen Anwendungsbereiche gekl\u00e4rt.<\/span><\/p>\n Als Speicherorte der Daten sind zu betrachten:<\/span><\/p>\n die Speicherung der Daten auf jedem Ger\u00e4t, <\/span><\/p>\n<\/li>\n die Speicherung der Daten auf nur einem Ger\u00e4t,<\/span><\/p>\n<\/li>\n die Speicherung auf einem besonderen Token,<\/span><\/p>\n<\/li>\n die Speicherung im Netzwerk<\/span><\/p>\n<\/li>\n<\/ol>\n Die Speicherung von Daten auf jedem Ger\u00e4t bietet sich f\u00fcr den Fall an, dass der Nutzer verschiedene Sicherheitsbereiche auch hardwarem\u00e4\u00dfig trennen will. Sollen Bankgesch\u00e4fte aus Sicherheitsgr\u00fcnden beispielsweise auf den PC beschr\u00e4nkt bleiben, befinden sich nur dort die dazu notwendigen Daten. <\/span><\/p>\n Da jedes Ger\u00e4t zun\u00e4chst eigene Daten aufzeichnet, kommt es zu unterschiedlichen Bewertungen der Vertrauensw\u00fcrdigkeit einzelner EI. Synchronisierungen zwischen den Ger\u00e4ten (beispielsweise abgesichert durch lokale EI) sind m\u00f6glich, widersprechen jedoch der Aufteilung in verschieden Sicherheitsbereiche. <\/span><\/p>\n<\/a>1 X.509 – Zertifikate<\/h1>\n
1.1 Aufbau<\/h2>\n
1.2 Grundlegende M\u00e4ngel<\/h2>\n
\n
<\/a>1.3 Technik<\/h2>\n
\n
2 Elektronischen Identit\u00e4t<\/h1>\n
2.1 Erweiterung von X.509<\/h2>\n
\n
2.2 Wesentliche Unterschiede und Ziele<\/h2>\n
\n
\n
2.3 Nutzerfreundlichkeit<\/h2>\n
\n
<\/a>2.4 Inhalte<\/h2>\n
2.5 Bindung<\/h2>\n
<\/a>3 EI-Typen<\/h1>\n
3.1 Globale EI<\/h2>\n
\n
\n
3.2 Lokale EI und Public Key Infrastructure<\/h2>\n
\n
4 Authentifizierung<\/h1>\n
<\/a>4.1 Keine Authentifizierung<\/h2>\n
4.2 Implizite Authentifizierung<\/h2>\n
4.3 Vollst\u00e4ndige Authentifizierung<\/h2>\n
4.4 Authentifizierung als Dienstleistung<\/h2>\n
<\/a>5 Lifecycle von EI<\/h1>\n
<\/a>5.1 Standard<\/h2>\n
\n
\n
5.2 Fehlerf\u00e4lle<\/h2>\n
\n
\n
<\/a>6 Verwaltung<\/h1>\n
\n
\n
6.1 Speicherung auf jedem Ger\u00e4t<\/h2>\n