Aus Linux-Magazin 12/2010

Cacert gibt kostenlose digitale Zertifikate aus

© Chris-Hochberger, Pixelio.de

Punkte sammeln Cacert-Mitglieder, um in den Genuss bestätigter Zertifikate zu kommen. Damit ließen sich Server per SSL/TLS prima absichern, wäre nur das Rootzertifikat den Browsern bekannt. Doch statt sich mit Nachdruck darum zu kümmern, jagt mancher im Projekt vornehmlich seinen Punkten nach.

Sicherheit scheint eine teure Angelegenheit zu sein. Wer etwa seine Webserver mit SSL oder TLS absichern möchte, benötigt dazu Zertifikate, die einige Dienstleister gegen gutes Geld verkaufen (siehe Kasten “Aufbau und Nutzen digitaler Zertifikate”). Da diese meist für einen einzigen DNS-Namen ausgestellt sind, kostet jede neue URL abermals Geld. Außerdem haben diese Bestätigungen eine begrenzte Lebensdauer und sind regelmäßig zu aktualisieren.

Aufbau und Nutzen digitaler
Zertifikate

Die Protokollschichten SSL oder TLS sichern – oft vom Benutzer unbemerkt – Onlineverbindungen wie zwischen Browser und Bankinstitut ab. Für die meisten ist allenfalls die URL-Dienstekennung »https« oder das Schlüsselsymbol in der Browser-Adresszeile ein Indiz für die Sicherung. Damit alles klappt, sind zwei Voraussetzungen nötig: starke Verschlüsselungstechnik und abgesicherter Austausch von Schlüsseln.

Erstere findet sich heute in fast jedem Browser. Die meisten heute verwendeten Cipher sind so stark, dass sie durchaus auch in sensiblen Bereichen zum Einsatz kommen. SSL und der Nachfolger TLS enthalten außerdem Mechanismen, die neue Verfahren nahtlos und vom Anwender weitgehend unbemerkt integrieren, sollte sich ein älterer Cipher als zu schwach erweisen. Bleibt die Frage, wie zwei Partner in einem nicht vertrauenswürdigen Netz vertrauliche Nachrichten austauschen, insbesondere den Sitzungsschlüssel, der den Datenverkehr wirksam schützt.

Hier kommen die Zertifikate ins Spiel, die meist dem X.509v3-Standard entsprechen [2]. Das sind Datenstrukturen, die zwei wesentliche Inhalte besitzen: Den öffentlichen Teil eines asymmetrischen Schlüsselpaars und Angaben dazu, zu welchem Inhaber er gehört, Identität genannt. Im Fall eines Webservers könnte das sein DNS-Name, im Fall einer Person könnten das ihre E-Mail-Adresse oder ihr Name sein.

Klare Abläufe sind Grundlage für Vertrauen

Essenziell ist die zweifelsfreie und nicht fälschbare Verbindung aus beiden genannten Angaben. Das bestätigt eine digitale Signatur unter dem Zertifikat. Die Güte einer solchen Public Key Infrastruktur, oft PKI genannt, ergibt sich daher nicht nur aus der eingesetzten Technik, sondern auch daraus, wie vertrauenwürdig die Beteiligten handeln. Insbesondere der Aussteller der digitalen Signaturen, die so genannte Certificate Authority (CA), sollte eine hinreichende Seriosität ausstrahlen.

Unternehmen wie Verisign oder Thawte zum Beispiel betreiben kommerziell ausgerichtete CAs und verlangen Geld dafür, dass sie Zertifikate nur dann signieren, wenn der angegebene Inhaber authentisch ist. Zusätzlich sorgen alle CAs dafür, wirksame Maßnahmen vorzuhalten, um solche Antragsteller zurückzuweisen, die sich mit einer fremden Identität melden. Eine Bezahlung fällt somit nicht in erster Linie für das faktische Erzeugen der Signatur und damit für das Zertifikat an sich an, sondern vielmehr für das Vorhalten der dafür notwendigen Prozesse und Abläufe.

Zertifikate an sich lassen sich jedoch günstig herstellen: Bereits wenige Open-SSL-Kommandos erzeugen sie. Aufwändig ist hingegen die Infrastruktur, diese Arbeiten transparent und sicher auszuführen. Im Jahr 2002 war eine Gruppe Freiwilliger der Ansicht, dass ein Projekt diese Arbeiten erbringen könnte, und gründete 2003 in Australien die ehrenamtlich arbeitende Körperschaft “Cacert Incorporated”. Unter ihrem Dach stellt seitdem das Projekt über seine Website interessierten Anwendern die für eine asymmetrische Kryptographie notwendigen Schlüsselpaare ebenso wie die für eine Verifizierung der Schlüssel nutzbaren Public-Key-Zertifikate kostenlos zur Verfügung.

Hierarchische Community

Das Cacert-Projekt unterscheidet Teilnehmer hierarchisch zwischen einfachen Community-Mitgliedern, Assurern, Super-Assurern, Associated Members und dem Cacert-Board. Einfache Mitglieder treten Cacert auf der Website bei, indem sie ein Formular ausfüllen und ihre E-Mail-Adresse übermitteln [1]. Anschließend verschickt Cacert eine Verifizierungsnachricht an diese Adresse, die der Nutzer seinerseits durch Aufruf eines in der E-Mail enthaltenen Links bestätigt. Fortan darf sich das neuen Mitglied ein einfaches Zertifikat (unassured) ausstellen lassen.

Da die Authentifikation über E-Mail gemeinhin als nur mäßig vertrauenswürdig gilt, haben die auf eine E-Mail-Adresse ausgestellten Zertifikate nur eine Gültigkeit von sechs Monaten, um Missbrauch einzuschränken. Weist sich der Antragsteller jedoch gegenüber Cacert persönlich aus, enthält das Zertifikat den Personennamen und die Gültigkeit beträgt 24 Monate.

Die Gültigkeitsdauern von sowohl Server- als auch Clientzertifikaten hängen daher von der Identitätsprüfung ab, bei der sich das Mitglied und spätere Inhaber gegenüber dem Projekt mit einem offiziellen Dokument ausweist. Das ist die Kernaufgabe, der sich Cacert stellt.

Mitmachen erwünscht

Die verlässliche Verifikation von Individuen ist die aufwändigste Leistung einer Certificate Authority. Cacert löst das Problem dadurch, dass es seine Mitglieder dazu einlädt, das Projekt aktiv durch Teilnahme am Assurance-Programm zu unterstützen. Ist die Identität eines Mitglieds persönlich verifiziert und hat es eine Prüfung abgelegt und bestanden, erhält es den Status eines Assurers. Die nehmen als offizielle Vertreter an Veranstaltungen teil und bestätigen die Identität weiterer Mitglieder. Damit bilden sie das Web of Trust des Cacert-Projekts.

Neben den Assurern benennt die Cacert-Website auch Super-Assurer. Ihr Alleinstellungsmerkmal gegenüber Assurern bleibt jedoch unklar. In der Theorie zeichnen sich Super-Assurer durch mehr Erfahrung sowie Einsatz für das Projekt aus und übernehmen aufgrund ihrer Qualitäten besondere Aufgaben. Mitglieder mit Super-Assurer-Status treten bei Veranstaltungen in der Praxis jedoch nicht in allen Ländern auf.

Um als Associated Member beizutreten, stellen User einen Antrag auf Mitgliedschaft bei Cacert Inc. und zahlen einen Jahresbeitrag von 10 US-Dollar. Dafür können sie auch in den Vorstand (Board) gewählt werden. Der zeichnet für die Ausrichtung der Organisation verantwortlich. Die auf der Website veröffentlichte Statistik wies Mitte September 2010 insgesamt 181764 erfolgreich registrierte Nutzer sowie 3860 Assurer aus [3].

Die nach der einfachen E-Mail-Verifikation vergebenen Clientzertifikate weisen den Antragsteller selbst aus oder genauer gesagt seine E-Mail-Adresse. Ein Webserver lässt sich damit noch nicht schützen. Cacert unterscheidet nämlich Client-, Server- und Codezertifikate. Ein Clientzertifikat verifiziert E-Mail-Absender und ermöglicht es, Nachrichten mit dem asymmetrischen Schlüsselpaar und zum Beispiel Open PGP oder Kgpg verschlüsselt zu übertragen oder zu signieren.

Ausweise für alle

Cacert erzeugt Schlüsselpaare für seine Mitglieder selbst und überträgt sie anschließend ebenfalls verschlüsselt an den Anwender. Benutzt der beispielsweise Mozillas Firefox, so installiert sich das Zertifikat anschließend dort automatisch (siehe Abbildung 1).

Abbildung 1: Firefox installiert das generierte Zertifikat automatisch und teilt dies in einem Hinweisfenster mit. Anwender finden es unter »Bearbeiten | Einstellungen | Verschlüsselung | Zertifikate anzeigen« wieder.

Abbildung 1: Firefox installiert das generierte Zertifikat automatisch und teilt dies in einem Hinweisfenster mit. Anwender finden es unter »Bearbeiten | Einstellungen | Verschlüsselung | Zertifikate anzeigen« wieder.

Der Export des im Browser eingebundenen Zertifikats in eine Datei und der anschließende Import in ein E-Mail-Programm erlaubt es dem Anwender, das Schlüsselpaar zum Signieren und Verschlüsseln zu verwenden: Unter »Bearbeiten | Einstellungen | Verschlüsselung | Zertifikate anzeigen« markiert er das Zertifikat und wählt »Sichern …« (siehe Abbildung 2). Nach der Vergabe eines Dateinamens liegt das von Cacert generierte Schlüsselpaar in der Export-Datei vor [5]. Der Anwender sollte diese im PKCS#12-Format [6] vorliegende Datei besonders sorgfältig schützen, da sie auch den privaten Schlüssel enthält (siehe Abbildung 3).

Abbildung 2: Nach Eingabe eines Dateinamens erzeugt ein Klick auf »Sichern« eine PKCS#12-Datei zum Exportieren, die neben dem öffentlichen auch den privaten Schlüssel des Zertifikats enthält. Sie bedarf besonderen Schutzes.

Abbildung 2: Nach Eingabe eines Dateinamens erzeugt ein Klick auf »Sichern« eine PKCS#12-Datei zum Exportieren, die neben dem öffentlichen auch den privaten Schlüssel des Zertifikats enthält. Sie bedarf besonderen Schutzes.

Abbildung 3: Ein Passwort schützt das Schlüsselpaar in der Export-Datei. Der Anwender importiert bei Bedarf ihren Inhalt in sein E-Mail-Programm und nutzt die erzeugten privaten Schlüssel zum Dekodieren von Nachrichten an ihn.

Abbildung 3: Ein Passwort schützt das Schlüsselpaar in der Export-Datei. Der Anwender importiert bei Bedarf ihren Inhalt in sein E-Mail-Programm und nutzt die erzeugten privaten Schlüssel zum Dekodieren von Nachrichten an ihn.

Gegen das Abhören während der Übertragung eines den privaten Schlüssel enthaltenden Zertifikats schützt sich der Nutzer, indem er zunächst ein Schlüsselpaar auf dem eigenen System erzeugt. Danach lädt er beim folgenden Certificate Signing Request (CSR) nur den öffentlichen Schlüssel zur Generierung des Zertifikats auf den Cacert-Server hoch.

Server mit Identität

Wollen Administratoren Webanwendungen schützen, greifen sie auf Cacerts Serverzertifikate zurück. Das Projekt vergibt sie sowohl für die Host- als auch für Wildcard-Nutzung, um damit Web- oder IMAP-Server fit für SSL und TLS zu machen. Dieses Einsatzszenario ist vermutlich für Anwender der nützlichste Dienst von Cacert. Website-Betreiber profitieren von der erhöhten Sicherheit bei Internetverbindungen, drückt die Verschlüsselung von Kundendaten doch notwendige Professionalität aus.

Auch hier bedürfen die bestätigten Zertifikate einer persönlichen Identifikation des Antragstellers (siehe Abbildung 4). Sie enthalten daher neben dem Domainnamen des Servers auch den vollen Namen des Inhabers. Zur Identifikation legt das Mitglied am einfachsten den Personalausweis persönlich einem Assurer auf einer der weltweit stattfindenden Cacert-Veranstaltungen vor. Schneller geht die Bestätigung, wenn er mehrere Identitätsnachweise vorlegt. Durch die Bestätigung verlängert sich die Gültigkeit beider Zertifikatsarten auf 24 Monate.

Abbildung 4: Je nach Status dürfen Cacert-Mitglieder unterschiedliche Zertifikate ausgeben. Mitglieder benötigen 50 Punkte, um bestätigte Client- oder Serverzertifikate zu erhalten. Ab 100 Punkte dürfen sie eine Prüfung zum Assurer ablegen. Die bestätigten Zertifikate gelten in der Regel 24 Monate.

Abbildung 4: Je nach Status dürfen Cacert-Mitglieder unterschiedliche Zertifikate ausgeben. Mitglieder benötigen 50 Punkte, um bestätigte Client- oder Serverzertifikate zu erhalten. Ab 100 Punkte dürfen sie eine Prüfung zum Assurer ablegen. Die bestätigten Zertifikate gelten in der Regel 24 Monate.

Codezertifikate, die dritte Kategorie, zur Signierung von Programmcode enthalten immer den vollen Namen des Inhabers und setzen in jedem Fall eine persönliche Identifikation voraus. Mit Codezertifikaten können Entwickler das Ausführen von bestimmtem Programmcode bei fehlendem oder falschem Zertifikat unterbinden. Ihre Gültigkeitsdauer beträgt durchgehend zwölf Monate.

Nur persönlicher Nachweis

Die ehemals angebotene Identitätsprüfung mit Hilfe von Trusted Third Parties (TTP), also durch vertrauenswürdige Drittparteien wie Notare, Richter, Anwälte, Bankbedienstete oder vereidigte Bilanzprüfer, steht zurzeit nicht mehr zur Verfügung. Ein Identitätsnachweis auf dem Postweg gegenüber Cacert ist somit für Anwender unmöglich. Mitglieder müssen bei einer der Cacert-Veranstaltungen persönlich vorbeischauen.

Der Anwender haftet bei allen drei Zertifikatstypen für den Missbrauch seines jeweiligen Zertifikats der Cacert Inc. gegenüber mit einem Betrag von derzeit 1000 US-Dollar für aufgetretene Missbrauchsfälle. Sollten unberechtigte Dritte mit gestohlenen Zertifikaten Straftaten begehen, könnte theoretisch auch der Inhaber des Rootzertifikats zur Rechenschaft gezogen werden.

Die vorstehende Regelung gibt Cacert die Möglichkeit, ihrerseits die Zertifikatsinhaber auf Schadensersatz zu verklagen. In Deutschland wäre dies wohl auf Fälle begrenzt, die ein Inhaber durch eine grobe Fahrlässigkeit herbeiführt.

Falls die Cacert Inc. selbst in Rechenschaft gezogen wird, müsste sie ihre Ansprüche gegen den Zertifikatsinhaber über Landesgrenzen hinweg durchsetzen. Das erscheint jedoch unwahrscheinlich. Auch ist es fraglich, inwieweit die nach australischem Recht getroffene Regelung in Deutschland nach internationalem Recht gültig und durchzusetzen ist.

Anhaltendes Interesse

Das Projekt veröffentlicht Statistiken zu verteilten Zertifikaten. Die Angaben auf der Website erscheinen auf den ersten Blick positiv: Bis Mitte September 2010 gab Cacert insgesamt 627184 Zertifikate aus (siehe Tabelle 1), in den zwölf Monaten davor waren es 85907. Zum Stichtag besitzen jedoch nur noch 83985 der jemals ausgegebenen Zertifikate Gültigkeit (siehe Tabelle 2). In anderen Worten: Inhaber von Zertifikaten verlängern diese nur in 13,7 Prozent der Fälle. Cacert-Mitglieder räumen ein, dass die Zertifikatsverwaltung verbesserungsfähig ist, und verweisen auf die Vielzahl an Anwendungen bei Nutzern.

Tabelle 1:
Zuwachsraten bei Cacert (Stand 09/2010)

 

Jahr

Neue Nutzer

Neue Assurer

Neue Zertifikate

2010

19768

624

58803

2009

29846

1390

103432

2008

29172

1463

116908

2007

26809

1974

107481

2006

31828

2864

110014

2005

28114

3367

88870

2004

13306

855

35417

2003

2760

75

3994

2002

161

 

147

Tabelle 2: Fakten
zum Projekt (Stand 09/2010)

 

Kennzahl

Anzahl

verifizierte Nutzer

181764

verifizierte E-Mail-Adressen

233573

verifizierte Domains

121307

ausgegebene Zertifikate

627184

gültige Zertifikate

83985

von Assurern durchgeführte
Identitätsprüfungen

128297

Nutzer mit 1 bis 49 Punkten

5569

Nutzer mit 50 bis 99 Punkten

4380

Assurer-Kandidaten

10036

Assurer mit Prüfung

3860

vergebene Punkte

2134390

Trotz dieser Hürden probieren viele von ihnen das kostenlose Zertifikatswesen von Cacert jedes Jahr aufs Neue aus (Abbildung 5). Doch die Nichterneuerung vieler Zertifikate weist auf zwei Probleme hin: Zum einen probieren die Anwender die Zertifikate aus, schätzen den Nutzen auf Dauer aber gering ein und kehren dem Projekt den Rücken. Zum anderen erzeugen sich Teilnehmer lieber neue Zertifikate, als alte zu verlängern, weil das Verlängern als komplex gilt.

Abbildung 5: Obwohl sich seit 2005 konstant neue Mitglieder anmelden (blau), stagniert die Zahl aktiven Zertifikate (gelb). Nutzer schätzen zwar das kostenlose Angebot, haben aber Probleme mit den komplexen Regeln zur Verlängerung.

Abbildung 5: Obwohl sich seit 2005 konstant neue Mitglieder anmelden (blau), stagniert die Zahl aktiven Zertifikate (gelb). Nutzer schätzen zwar das kostenlose Angebot, haben aber Probleme mit den komplexen Regeln zur Verlängerung.

Bei wenigen inklusive

Sicherheitsbewusste Anwender schrecken vor Websites zurück, die mit einer Nachfrage Zustimmung zu einem neuen Zertifikat oder gar eine händische Installation von Rootzertifikaten oder das manuelle Prüfen von Zertifikat-Fingerprints fordern. Kommen die Rootzertifikate in den Anwendungen bereits mit der Installation des Betriebssystems oder des Browsers, erhöht sich die Akzeptanz.

Gängige Browsermodelle oder Desktop-Oberflächen enthalten bereits viele gültige Rootzertifikate der kommerziellen CAs. Anwender sollten sich bewusst sein, dass sie damit eine wichtige Sicherheitsaufgabe an die Anbieter ihrer Software delegieren, und sich über die Kriterien informieren, nach denen das geschieht. Leider sind diese oft wenig transparent. Das Rootzertifikat von Cacert fehlt jedoch bislang in den bekannten Browsern oder Distributionen (siehe Abbildung 6). Eine Ausnahme stellt Knoppix dar. Bei Debian enthält das per Apt nachinstallierbare Paket »ca-certificates« unter anderem das Cacert-Rootzertifikat.

Abbildung 6: Warnhinweise auf fehlende Zertifikate erschrecken normale Internetnutzer. Das Rootzertifikat der Cacert-CA ist den meisten Browsern standardmäßig nicht bekannt und sorgt dann für Irritationen bei Anwendern.

Abbildung 6: Warnhinweise auf fehlende Zertifikate erschrecken normale Internetnutzer. Das Rootzertifikat der Cacert-CA ist den meisten Browsern standardmäßig nicht bekannt und sorgt dann für Irritationen bei Anwendern.

Das Fehlen des Cacert-Rootzertifikats in vielen Browsern begründet sich bei näherer Betrachtung nicht alleine als eine Frage des Geldes, das Browserhersteller für ihre eigene Prüfung des Rootzertifikats der CA in Rechnung stellen. Vielmehr spielen sicherheitskritische Faktoren wie die Schlüsselgenerierung, -vorhaltung und -übertragung bei den Browserentwicklern und Distributoren eine ganz zentrale Rolle. Deshalb erwarten viele, dass eine CA mit einem Audit aus eigener Initiative ihre Maßnahmen zur Qualitätssicherung darlegt.

Ulrich Schroeter zum
Cacert-Audit


Zu einer Erklärung, wie das Projekt plant sein Rootzertifikat mit populären Browsern auszuliefern, sah sich der Vorstand der Cacert Inc. gegenüber dem Linux-Magazin außerstande. Die Regularien erforderten eine mehrwöchige Vorlaufzeit für solche Anfragen, ließ das Board wissen und verwies an den deutschen Assurance Officer Ulrich Schroeter, der viele Subprojekte bei Cacert vorangetrieben hat.

Linux-Magazin:Ulrich, arbeitet Cacert daran, sein Rootzertifikat in die Browser zu bringen?

Ullrich-Schroeter:Wir treiben zurzeit sechs Projekte voran, um “Audit ready” zu werden. Am wichtigsten ist dabei die Registration Authority, die RA. Da legen wir fest, wie wir Mitglieder identifizieren. Fast fertig ist der Plan, das Cacert Community Agreement an alle Mitglieder zu verteilen. Vier weitere Aktivitäten betreffen die interne Technik der CA, die die Zertifikate ausstellt. Leider hinken diese Projekte dem Zeitplan nach.

Linux-Magazin:Wenn das alles klappt, wann dürfen Anwender denn darauf hoffen, dass das Zertifikat größere Verbreitung findet?

Schroeter:Die Frage kennen wir seit 2005. Dazu brauchen wir das Audit und für das Audit jede Menge Regelungen. Bis Ende 2009 dachten wir alle, dass unser Auditor diese festlegt, und sind letztlich daran gescheitert. Wir müssen als Community die Vorarbeiten selbst erledigen, Regeln schreiben und Abläufe festlegen. So kann der Auditor schließlich prüfen, ob die mit der Realität konform sind.

Wir hatten schon die wichtigsten Regelungen getroffen und prüfen lassen, sind jedoch im Bereich “Systeme” durchgefallen. Die RA war schon weit und das Co-Audit-Konzept sogar bestätigt, doch dann mussten wir aus anderen Gründen das Gesamtaudit wieder stoppen. Damit es weitergeht, brauchen wir noch mehr Hilfe, denn wir arbeiten nur als Freiwillige. Davon haben wir aber zu wenige, darum geht es gegenwärtig nur ziemlich langsam voran.

Linux-Magazin:Was sind die nächsten Schritte?

Schroeter:Das Software-Assessment-Projekt startete im letzten Dezember. Den für das erste Quartal geplanten Meilenstein konnten wir im Oktober abschließen. Als Nächstes kommen die Projekte “New Roots” und “Escrow”. Weil letzteres schon einmal durchgefallen ist, müssen wir vieles neu machen. Die Policy Group kommt immerhin seit dem Frühling voran, aber auch hier gibt’s wegen vieler Nebenprojekte nicht genügend Entwickler, die sich praktisch mit dem Roots Escrow auskennen. Wir würden das gerne auf mehrere Mitglieder abbilden.

Linux-Magazin:Was sagen denn eigentlich die Browser-Hersteller? Seid ihr da in Kontakt?

Schroeter:Ende 2009 haben wir unsere Cross-Community-Kampagne gestartet und sind dabei in Kontakt mit vielen Linux-Distributionen, Open Office, Drupal und anderen Organisationen.

Dürftige Dringlichkeit

Wer die Arbeit des Projekts seit seiner Gründung betrachtet, fragt sich bisweilen, wieso es auf diesen Aspekt so wenig Wert zu legen scheint. Stattdessen befassten sich die meisten Aktivitäten der vergangenen Jahre mit internen Organisationsfragen und dem Ausstellen nur untereinander akzeptierter Zertifikate. Schauen sich interessierte Nutzer auf den Projekt-Webseiten um, finden sie kaum oder erst nach längerem Suchen Informationen zu den technischen Aspekten.

Angaben etwa zur Zertifikatseinbindung und -vorhaltung beziehungsweise der Übertragung, internen Speicherung und Nutzung der privaten Schlüssel sind vergleichsweise schwer zu finden – problematisch für eine CA [4]. Demgegenüber befassen sich viele Dokumente und Einzelseiten mit dem Themenkomplex der “Organisation der Organisation” und Cacerts Punktesystem.

Die Projektdokumentation unternimmt viele Anstrengungen, die Glaubwürdigkeit von Cacert zu stärken. Andere CAs verankern diese, indem sie ein strenges hierarchisches System etablieren: Ein Rootzertifikat bildet die Basis sämtlicher von ihr ausgehenden Zertifikate. Eine solche CA führt in der Regel alle dafür notwendigen Identitätsprüfungen selbst durch. Dann stellt ein einzelnes gefälschtes Zertifikat auch nicht die Glaubwürdigkeit der ganzen CA in Frage.

Cacert hingegen verbindet durch seine Organisation den zum Beispiel von Open PGP her bekannten Web-of-Trust-Ansatz mit der strengen hierarchischen Gliederung einer Certificate Authority: Auf der einen Seite gibt sich Cacert aufeinander aufbauende Regeln, die einzuhaltende Verfahrensschritte und zu beteiligende Instanzen definieren. Auf der anderen Seite identifizieren sich die Zertifikatsinhaber nicht direkt gegenüber Cacert, sondern gegenüber Assurern, die das Cacert-Web-of-Trust ausbilden.

Hybrides Vertrauensmodell

Diese Crossover-Verifizierung stellt die Identität der Instanzen untereinander fest und nicht die einer übergeordneten Stelle, die ihrerseits Engpass oder Angriffspunkt sein kann. Welches Modell Vertrauen besser abbildet, ist Gegenstand vieler Diskussionen, jeder Anwender muss dies letztlich für sich selbst entscheiden.

Cacert versucht die Glaubwürdigkeit seiner ausgegebenen Zertifikate durch ein ausgeklügeltes Punktesystem zu untermauern. Mitglieder sammeln durch die Bestätigung ihrer persönlichen Identität Punkte. Die wiederum ermöglichen es den Mitgliedern, länger gültige Zertifikate zu erhalten oder die Assurer-Prüfung abzulegen. Unbestätigte einfache Zertifikate besitzen die geringste Glaubwürdigkeit, was sich in einer geringen Gültigkeitsdauer und im Fehlen des Inhabernamens niederschlägt.

Punkte als Qualitätsmaß

Ab einer bestimmten Punktzahl darf ein Mitglied seine einfachen Zertifikate in bestätigte umwandeln. Die Punkte dazu sammelt es beispielsweise auf Cacert-Veranstaltungen, indem ein Assurer persönlich seine Identität bestätigt. 50 Punkte erlauben es dem einfachen Mitglied, bestätigte Zertifikate zu erlangen. Eine vergleichbare Regelung betrifft Serverzertifikate, mit denen Mitglieder ihre Web- oder IMAP-Server sichern können. Die genannte Punktzahl setzt Cacert auch für Codezertifikate voraus.

Durch Identitätsprüfungen gesammelte 100 Punkte ermöglichen es einem Mitglied, sich zur Assurer-Prüfung anzumelden. Je mehr Punkte ein Assurer besitzt, desto mehr erhalten ihrerseits die von ihm identitätsgeprüften einfachen Mitglieder. Er vergibt so zwischen 10 und 35 Punkte an Mitglieder, die sich durch ihn ihre Identität bestätigen lassen.

Die Höhe der zu vergebenden Assurer-Punkte drückt bei diesem Modell das Maß der Vertrauenswürdigkeit eines Assurers aus. Sie bewerten also, wie viele hoffentlich kompetente Assurer ein Mitglied getroffen hat. Als Maß für die Vertrauenswürdigkeit der zertifizierten Person selbst taugt er jedoch wenig.

Die maximal erreichbare Punktzahl hat das Cacert-Board in seinen Regularien auf 200 festgelegt. Höchstens 150 davon sammelt das Mitglied durch Identitätsnachweise von Assurern. Nach bestandener Prüfung erhalten die Assurer für jede getätigte Identitätsprüfung eines einfachen Mitglieds ihrerseits zwei Punkte (siehe Abbildung 4). Ab diesem Zeitpunkt haben die Punkte also eine andere Bedeutung: Sie symbolisieren nun die Produktivität des Assurers für das Projekt. Spätestens dies hat mit einem Maß für Vertrauenswürdigkeit nur noch wenig zu tun. Jeder Super-Assurer verfügt auf seinem Punktekonto über die maximale Anzahl von 200 Punkten.

Das Punktesystem präsentiert sich auf den ersten Blick als von vielen Audits geforderte Qualitätssicherungsmaßnahme, dennoch fallen bei näherer Betrachtung einige Ungereimtheiten auf: Die Punkte suggerieren, dass Mitglieder mit einer hohen Punktzahl über umfangreiches Wissen bezüglich Zertifikatsstrukturen besitzen und sich längerfristig im Projekt engagiert haben.

Dem steht die Erkenntnis gegenüber, dass selbst ein neues Mitglied 100 oder gar 150 Punkte leicht an einem Nachmittag auf einer Konferenz sammelt. Drei oder vier Bekannte reichen aus, und das einfache Mitglied legt nach thematischer Vorbereitung bereits die Assurer-Prüfung ab. Die restlichen notwendigen 50 Punkte bis zum Status des Super-Assurers sammeln die Assurer ziemlich leicht, indem sie zum Beispiel ihre Kommilitonen oder ihre ganze Sportriege nach und nach assuren. Hinzu kommt, dass das Board die nicht für alle Zeiten festgeschriebenen Punkteregeln bei Gefallen aufheben oder ändern kann.

Hatz nach dem Highscore

Die Forderung nach einer bestimmten Punktezahl ist somit keine ernsthafte Hürde gegen das Vortäuschen von versprochener Eigenschaften. Sie ist auch kein Garant für fachliche Kompetenz oder Engagement. Als Entscheidungs- oder Qualitätskriterium, das Rootzertifikat in eine Anwendung zu implementieren, taugen Punkte nicht.

Eine regelrechte Jagd der Mitglieder nach hohen Punktezahlen fördert zudem nicht den verantwortungsvollen Umgang mit sicherheitsrelevanten Daten oder Zertifikaten. Von dem Wunsch nach hohen Punktezahlen und ihrer Bedeutsamkeit für den Einzelnen getreu dem Motto “Mehr Punkte sind besser” profitiert im Zweifel eine auch beim Cacert-Projekt nicht auszuschließende Vetternwirtschaft. Ob somit Punkte eine gute Grundlage für die Ausbildung eines Web of Trust darstellen, bleibt zweifelhaft.

Ehrenhafte Motive

Die Ziele von Cacert sind ehrenhaft: kostenlose Zertifikate für Authentifikation und Verschlüsselung einer interessierten Öffentlichkeit in Form eines Projekts bereitstellen. Die Entscheidung, ein Web of Trust für die Modellierung von Vertrauen heranzuziehen, erscheint zwar durchaus folgerichtig, ist aber diskussionswürdig. Doch offenbar dreht sich das Projekt im Wesentlichen nur noch um sich selbst, befasst sich mit einer wenig transparenten Eigenorganisation und hechelt Punkte-Rekorden hinterher.

Für Anwender wichtige Fragen wie die Voraussetzungen für das Einbetten des Rootzertifikats in Browser wie Firefox & Co. haben offenbar eine niedrigere Priorität. Alleine am Geld für ein Audit kann es kaum liegen, denn das Thema dümpelt schon seit mehreren Jahren vor sich hin. Auch die technische Umsetzung ist noch verbesserungswürdig. Dass Cacert private Schlüssel eingebettet überträgt, bewerten manche Anwender kritisch. Denn die lassen sich auch selbst generieren. Nur der Public Key ist beim Signieren notwendig.

Cacert steckt in einer Zwickmühle: Das Vertrauen in die eingesetzte Technik und die Transparenz der Abläufe sind unabdingbar für eine CA. Andererseits muss das Projekt irgendwann auch einmal Ergebnisse zeigen. Gelingt es in Zukunft, das Verfahren zur Anwendung der Zertifikate und der in ihnen enthaltenen Schlüssel zu vereinfachen, die Nutzer insgesamt mehr zu binden und das Rootzertifikat in Browsern standardmäßig zu hinterlegen, dann nähert sich Cacert seinem Ziel bedeutend schneller – kostenlose Zertifikate für jedermann zur Verfügung zu stellen und den Anwendern eine wirkliche Alternative zu den etablierten kommerziellen Anbietern zu bieten.

Infos

[1] Cacert:[http://www.cacert.org/index.php?id=1]

[2] Spezifikation X.509v3: [http://www.itu.int/rec/T-REC-X.509-200508-I]

[3] Statistiken zum Cacert-Projekt:[http://www.cacert.org/stats.php]

[4] Projekt-Wiki: [http://wiki.cacert.org]

[5] Zertifikatserstellung: [http://ivamp.de/cert/CACert_Zertifikatserstellung_Mail.pdf]

[6] Public-Key Cryptography Standards (PKCS): [http://rsa.com/rsalabs/node.asp?id=2124]

Der Autor

Kay Königsmann arbeitete seit 1999 zunächst als Datenbank- und Java-Dozent, später im Projektmanagement. Seine Schwerpunkte sind Debian sowie IT-Security. Er ist Autor zahlreicher Fernlehrgänge für die Erwachsenenweiterbildung.

LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Nach oben