IT-Academy Logo
Sign Up Login Help
Home - Netzwerke - Sicherheit - Zehn Risiken bei PKIs



Zehn Risiken bei PKIs

Fragenzu PKIs, auf die man nicht so einfach eine Antwort bekommt.


Autor: Jochen Berner (jberner)
Datum: 15-01-2003, 23:12:34
Referenzen: http://www.counterpane.com/pki-risks-ft.txt (englischer Originaltext)
Schwierigkeit: Profis
Ansichten: 4644x
Rating: Bisher keine Bewertung.

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Einleitung
Computersicherheit ist Opfer des "Jahr des..." Syndroms geworden. Erst waren es Firewalls, dann Einbruchserkennung, danach VPNs und jetzt Certification Authorities (CAs) und Public Key Infrastrukturen (PKIs). "Kaufen Sie das Produkt X und Sie sind gegen alles abgesichert" verkündet die Werbung. Aber die Realität ist nie so einfach und das gilt besonders für PKIs.

Zertifikate bieten ein attraktives Geschäftsmodell. Ihre Herstellung kostet so gut wie nichts und wenn man jemanden überzeugen kann eines für 5 Euro pro Jahr zu kaufen und das auf die Zahl der Internetnutzer hochrechnet ergibt das ein schönes jährliches Einkommen. Wenn man jemanden überzeugen kann, eine private CA zu kaufen und pro ausgestelltem Zertifikat eine Lizenzgebühr zu zahlen ist das auch schönes Geld. Es wundert also nicht, das so viele Firmen aus diesem potentiellen Markt Geld ziehen wollen. Wenn so viel Geld auf dem Spiel steht, ist auch kein Wunder das die meiste Literatur und Lobbyarbeit zu dem Thema von den PKI-Herstellern kommt. Aber diese Literatur lässt einige grundlegende Fragen offen: Wozu braucht man Zertifikate überhaupt? Sind sie sicher? Wofür? In diesem Essay soll versucht werden, einigen dieser Fragen nachzugehen.

Sicherheit ähnelt einer Kette: sie ist nämlich nur so stark wie das schwächste Glied. Die Sicherheit einer CA hängt an vielen Gliedern und nicht alle sind verschlüsselt. Menschen spielen eine Rolle. Hilft das System diesen Menschen, verwirrt es sie oder ignoriert es sie einfach? Verlässt es sich unangemessen stark auf die Ehrlichkeit oder Gründlichkeit von Menschen? Computersysteme spielen eine Rolle. Sind diese Systeme sicher? Alle arbeiten in einem übergreifendem Prozess zusammen. Ist dieser Prozess auf maximale Sicherheit oder nur auf Profit ausgelegt?
Jede dieser Fragen kann auf Sicherheitslücken hinweisen, um die man sich kümmern muss.

Bevor wir anfangen: "Brauchen wir eine PKI für den e-commerce?"
Schlagen Sie irgendeinen Artikel über PKI in der Fach- oder Allgemeinpresse auf und Sie werden sehr wahrscheinlich die Aussage finden, das PKI unbedingt gebraucht wird, damit der e-commerce florieren kann. Diese Behauptung ist offensichtlich falsch. Es gibt bereits e-commerce aber eine PKI ist nirgendwo zu sehen. Webseiten nehmen Ihre Bestellung entgegen, egal ob Sie ein Zertifikat haben oder nicht. Aber wie bei vielen anderen falschen Behauptungen gibt es auch hier eine zugehörige wahre Behauptung: kommerzielle PKI braucht dringend den e-commerce um florieren zu können. Mit anderen Worten: neu gegründete PKI-Firmen brauchen die Behauptung, grundlegend wichtig für den e-commerce zu sein, um Investoren anzulocken.
Diese populäre Unwahrheit zu glauben birgt Risiken. Das unmittelbare Risiko trägt der Investor. Die Sicherheitsrisiken tragen alle diejenigen, die sich entschieden haben, das Produkt eines kommerziellen PKI-Anbieters zu verwenden.

Risiko #1: "Wem vertrauen wir und für was?"
Die nichteindeutige Verwendung des Wortes "vertrauen" stellt ein Risiko dar. Eine CA wird oft als "vertrauenswürdig" bezeichnet.
In der Literatur über Krytographie heißt das aber lediglich, das sie ihre eigenen privaten Schlüssel angemessen schützt. Es heißt nicht unbedingt, das man einem Zertifikat dieser CA trauen kann, weder für ein Micropayment noch für einen Multimillionendollarabschluss.
Wer hat einer CA das Recht gegeben, solche Ermächtigungen auszustellen? Wer hat sie vertrauenswürdig gemacht?

Eine CA kann hervorragende Arbeit beim Verfassen eines Certificate Practice Statement (CPS) leisten - alle CPS, die wir gelesen haben, lehnen jede Verantwortung und jede Bedeutung für ein Zertifikat ab - und sich dann strikt an dieses CPS halten, aber das heißt nicht, das man einem Zertifikat für die eigene Anwendung trauen kann. Dem Problem, das sie eigentlich gar nicht das Recht haben, Authorisierungen zu delegieren weichen viele CAs aus, in dem sie ID-Zertifikate ausstellen. Jeder kann Namen zuweisen. Wir alle machen das dauernd. Dieses Vorgehen wälzt das Risiko auf denjenigen ab, der das Zertifikat prüft, wenn er den Fehler macht anzunehmen, ein ID-Zertifikat stelle irgendeine Form von Authorisierung dar.
Einige versuchen, einem PKI-Kunden genau das einzureden. Ihre Logik funktioniert so:
(1) Sie haben ein ID-Zertifikat,
(2) dadurch haben sie den Namen des Inhabers,
(3) das heißt, sie wissen wer der Inhaber ist,
(4) das war das, was sie wissen müssen.

Das war natürlich nicht das, was sie wissen müssen. Darüber hinaus sind die logischen Schritte von 1 nach 2, von 2 nach 3 und von 3 nach 4 jeder für sich fehlerhaft (die Fehler zu finden überlassen wir dem Leser als Übung).

Risiko #2: "Wer benutzt meinen Schlüssel?"
Eines der größten Risiken in jedem CA-basiertem System liegt in Ihrem privaten Schlüssel. Wie schützen Sie ihn? Mit einiger Sicherheit haben Sie kein sicheres Computersystem mit physischer Zugangskontrolle, TEMPEST-Abschirmung, "Air wall" Netzwerksicherheit (was ist das? Anm. des Übers.) und anderen Sicherheitsmaßnahmen; Sie speichern Ihren privaten Schlüssel auf einem herkömmlichen Computer. Dort ist er den Angriffen von Viren oder anderen bösartigen Programmen ausgesetzt. Auch wenn ihr privater Schlüssel auf dem Computer sicher ist, steht der Rechner in einem abgeschlossenem Raum mit Videoüberwachung, so das sichergestellt ist, dass niemand außer Ihnen den PC benutzt? Wenn er durch ein Passwort geschützt wird: wie schwer ist dieses Passwort zu erraten? Wenn der Schlüssel auf einer Smartcard gespeichert ist: wie resistent ist die Karte gegen Angriffe? (Die meisten sind ziemlich schwach). Wenn er auf einem angriffsresistenten Medium gespeichert ist, kann ein infizierter Computer das Medium veranlassen etwas zu signieren, von dem Sie gar nicht vorhatten es zu signieren?

Der letzte Punkt ist hauptsächlich wegen des Begriffs der "Nichtablehnbarkeit" (im Original "non-repudiation", Anm des Übers.) interessant. Ähnlich wie der Begriff "vertraut" ist er aus der akademischen Literatur zur Kryptographie übernommen. In diesem Bereich hat er eine sehr eng begrenzte Bedeutung: das der Algorithmus für die digitale Unterschrift nicht zu brechen ist, so daß eine dritte Seite die Unterschrift nicht fälschen kann. PKI-Hersteller haben sich diesen Begriff zu eigen gemacht und verwenden in jetzt in einem juristischen Kontext. Sie arbeiten auf Gesetze hin, die besagen, dass, wenn jemand Ihren privaten Schlüssel verwendet hat, Sie nicht berechtigt diese Unterschrift abzulehnen. Mit anderen Worten: unter einigen Gesetzgebungen (z.B. Utah und Washington) sind Sie als Besitzer eines von einer zugelassenen CA signierten Schlüssels verantwortlich für alles, was mit diesem Schlüssel gemacht wird. Ganz egal, wer am Computer gesessen hat oder welches Virus die Unterschrift veranlasst hat: Sie sind vor dem Gesetz verantwortlich.
Vergleichen Sie dieses Vorgehen mit dem Umgang mit Kreditkarten. Nach den mail-order/telephone-order (MOTO) Regeln gilt: wenn Sie Zweifel an einem Punkt auf Ihrer Kreditkartenabrechnung haben, können Sie ihn zurückweisen - sagen, das Sie das nicht gekauft haben - und der Verkäufer muss Ihnen das Gegenteil beweisen.

Risiko #3: "Wie sicher ist der prüfende Computer?"
Der vorige Absatz hat gezeigt, das der Computer, auf dem der private Schlüssel liegt, sicher sein muss. Große Schlüssellängen ersetzen kein sicheres System, da die Gesamtsicherheit schwächer ist als die schwächste Komponente in dem System.
Das gleiche gilt für den prüfenden Computer - den, der das Zertifikat verwendet.
Zertifikatsbestätigungung benötigt keine privaten Schlüssel, nur öffentliche.
Deshalb gibt es auch keine Geheimnisse zu schützen. Allerdings werden ein oder mehrere "root" öffentliche Schlüssel verwendet. Wenn ein Angreifer seinen eigenen öffentlichen Schlüssel dieser Liste hinzufügen kann, dann kann er seine eigenen Zertifikate ausstellen, die genau wie die legitimen Zertifikate behandelt werden. Sie können sogar anderen Zertifikaten in allen Belangen gleichen, außer das sie statt des korrekten den öffentlichen Schlüssel des Angreifers enthalten.
Es hilft nicht, diese Rootschlüssel in "Rootzertifikaten" aufzubewahren. Ein solches Zertifikat ist selbstunterschrieben ("self-signed") und bietet keine zusätzliche Sicherheit. Die einzige Möglichkeit ist es, alle Bestätigungen auf einem Computer durchzuführen, der unverwundbar gegen Einbruchsversuche durch Programme oder physischen Zugriff ist.

Risiko #4: "Welcher John Robinson ist er?"
Zertifikate ordnen gewöhnlich einen öffentlichen Schlüssel einem Namen zu, aber nur wenige Leute fragen nach der Nützlichkeit einer solchen Zuordnung. Stellen Sie sich vor, Sie erhalten das Zertifikat eines John Robinson. Sie selbst kennen vielleicht nur einen John Robinson, aber wieviele kennt die CA? Wie können Sie sicherstellen, das das John-Robinson-Zertifikat, das Sie erhalten haben, wirklich Ihrem Freund gehört? Sie könnten seinen öffentlichen Schlüssel persönlich von ihm erhalten haben oder es persönlich überprüft haben (PGP lässt das zu), aber es ist wahrscheinlicher, daß Sie das Zertifikat per e-mail erhalten haben und einfach glauben, daß es vom richtigen John Robinson stammt. Der Common Name des Zertifikats ist wahrscheinlich mit einigen Zusatzinformationen ergänzt, um ihn unter allen anderen Namen die von der CA verwaltet werden einzigartig zu machen.
Kennen Sie diese Zusatzinformation über ihren Freund? Wissen Sie, von welcher CA das Zertifikat kommen sollte?
Als Diffie und Hellman die Public-Key-Kryptographie vorstellten, sagten Sie ein erweitertes Telefonbuch voraus, in dem auch öffentliche Schlüssel zu finden wären. Anstatt Name, Adresse und Telefonnummer stünden dort Name, Adresse und öffentlicher Schlüssel. Wenn man John Robinsons öffentlichen Schlüssel suchte, würde man in diesem Verzeichnis nachschauen, seinen Schlüssel nehmen und ihm eine Nachricht zukommen lassen, die nur er lesen könnte dank seines öffentlichen Schlüssels. Diese Idee funktioniert vielleicht mit dem Telefonbuch des Fachbereichs Computerwissenschaft der Stanford University im Jahre 1976, aber wie viele John Robinsons gibt es im New Yorker Telefonbuch, geschweige denn in einem hypothetischen internetweiten Telefonbuch?

Wir wachsen in kleinen Familien auf, in denen die Identifizierung per Name funktioniert. Wenn wir fünf Jahre alt sind, haben wir das schon gelernt. Namen funktionieren. In der großen weiten Welt ist diese Annahme falsch, aber Sachen die wir als Kinder gelernt haben vergessen wir nie wieder. In diesem Fall aber müssen wir Namen genau hinterfragen und sie nicht blind mit der Haltung eines fünfjährigen Kindes akzeptieren.

Risiko #5: "Ist die CA eine Autorität?"
Die CA mag eine Autorität sein, wenn es um das Ausstellen von Zertifikaten geht aber ist sie auch eine Autorität was die Inhalte angeht? Ein SSL-Zertifikat zum Beispiel enthält zwei Teile die möglicherweise sicherheitsrelevant sind: den Namen des Inhabers (normalerweise ein Firmenname) und den DNS-Namen des Servers. Es gibt Behörden, die DNS-Namen zuweisen, aber keine SSL-CAs die den gängigen Browsern bekannt sind gehört dazu. Das heißt, das der DNS-Name nicht vertrauenswürdig ist. Es gibt Behörden die Firmennamen verwalten. Diese Namen werden registriert, wenn man einen Gewerbeschein bekommt. Auch hier gehört keine SSL-CA zu diesen Behörden. Außerdem: wenn irgendein Server ein SSL-Serverzertifikat hat, so hat er die Erlaubnis SSL zu benutzen. Wer hat der SSL-CA das Recht gegeben, diese Erlaubnis zu überwachen? Ist die Überwachung dieser Erlaubnis überhaup notwendig? Sie dient einem wirtschaftlichem Zweck (den CAs ihre Einnahmen zu sichern) aber dient sie auch der Sicherheit? Welcher Schaden entstünde, wenn es einem nichtzertifizierten Server erlaubt wäre Verschlüsselung zu verwenden?
Keiner.

Risiko #6: "Ist der User Teil des Sicherheitsentwurfes?"
Berücksichtigt die Anwendung die das Zertifikat verwendet den Benutzer oder kümmert sie sich nur um die Verschlüsselung?
Ein Beispiel: ein normaler User trifft die Entscheidung, ob er auf einer SSL-geschützten Seite einkauft anhand der Inhalte, die diese Seite ihm anzeigt. Das Zertifikat wird nicht angezeigt und hat auch nicht unbedingt eine Beziehung zu dem, was angezeigt wird. SSL-Sicherheit hat weder Kontrolle über das was angezeigt wird, noch kann es auf den Inhalt der Webseite reagieren. Alles, was es kennt ist der DNS-Name. Der Firmenname wird nicht mit dem verglichen, was der Anwender zu sehen bekommt. Es gibt Webseiten, bei denen das Zertifikat auf die Firma lautet, die die Seite hostet und nicht auf den Firmennamen der auf der Webseite gezeigt wird. Normale Anwender wissen von all dem nichts und man kann auch nicht erwarten, das sie es tun.

Risiko #7: "War es eine CA oder eine CA plus Registrierungsbehörde?"
Um dem Problem zu entgehen, dass Sie für den Zertifikatsinhalt nicht garantieren können, haben einige CAs eine zweistufige Zertifizierungsstruktur erschaffen: eine Registrierungsbehörde ("Registration Authority", RA), betrieben durch eine Stelle die die Inhalte garantieren kann über sichere Kommunikationswege verbunden mit einer CA, die lediglich die Zertifikate ausstellt. Andere Händler verkaufen die CA-Hardware und Infrastruktur direkt an die RA.
Das RA+CA Modell ist eindeutig unsicherer als ein System, bei dem die CA in die RA integriert ist. Das RA+CA Modell erlaubt es einem Teil (der CA) das keine Kontrolle über Inhalte hat, Zertifikate mit diesen Inhalten zu fälschen. Natürlich unterschriebe die CA einen Vertrag, in dem sie verspräche so etwas niemals zu tun, aber das beseitigt nicht ihre Fähigkeit es zu tun. Da die Gesamtsicherheit einer Kette schwächer ist als ihr schwächstes Glied ist RA+CA schwächer als einer von beiden, egal wie sicher die CA ist oder wie gut die Verträge zwischen beiden sind.
Natürlich verletzt das andere Modell (RA mit integrierter CA) das Geschäftsmodell einiger PKI-Verkäufer. Es ist schwieriger, Geld für Zertifikate zu verlangen, wenn man jemanden das CA-Programm verkauft hat (oder er es kostenlos, als Open Source, bekommen hat).

Risiko #8: "Wie hat die CA den Zertifikatsinhaber identifiziert?"
Egal ob das Zertifikat lediglich zu Identifizierungszwecken dienen soll oder zur Authorisierung verwendet wird: die CA muss die Identität des Antragstellers vor der Ausstellung des Zertifikates eindeutig feststellen.
Es gab mal eine Kreditgesellschaft, die dachte, sie könnte in das CA-Geschäft einsteigen. Immerhin hatten sie eine enorm große Datenbank über ihre Kunden, so dass es ein einfaches wäre, die Identität einer Person online feststellen zu können, jedenfalls lautete so der Gedankengang. Wenn man eine Identität online überprüfen möchte, kann man das tun, vorausgesetzt man kennt ein gemeinsames Geheimnis und einen sicheren Weg dieses Geheimnis zu übermitteln. SSL bietet diesen sicheren Weg.
Das Problem aber ist, das in dieser ganzen riesigen Datenbank nicht ein einziges Geheimnis zu finden ist, das nur die Kreditgesellschaft und der Kunde kennen. Das liegt daran, das Kreditgesellschaften auch Geld damit verdienen, Informationen über Personen an Dritte zu verkaufen. Schlimmer noch: da Kreditgesellschaften wirklich gut darin sind, Informationen zu sammeln und weiterzuverkaufen, haben andere, die vielleicht Informationen über jemanden haben Mühe, irgendein Faktum zu finden, das nicht bereits über andere Quellen erhältlich ist. Das wiederum gefährdet kommerzielle CAs, die sich auf die Informationen von Kreditgesellschaften verlassen um Identitäten online zu überprüfen. Dieses Geschäftsmodell funktioniert einfach nicht.
Angenommen, die Identität des Antragstellers wäre irgendwie festgestellt worden: wie hat die CA geprüft, ob er wirklicher Besitzer des privaten Schlüssels war dessen öffentliches Gegenstück zertifiziert werden soll? Einige CAs sehen dies überhaupt nicht als Teil des Antragsprozesses. Andere könnten verlangen, dass der Bewerber unter den Augen der CA einige Aufgaben löst oder Fragen beantwortet.

Risiko #9: "Wie sicher ist der Umgang mit Zertifikaten?"
Zertifikate sind nicht wie ein Zaubertrank, von dem man nur einen Tropfen in das System gibt und schon ist es sicher. Man muss mit Zertifikaten vernünftig umgehen wenn man Sicherheit haben will. Ist dieser Umgang mit Blick auf die Sicherheit entwickelt worden oder imitieren sie einfach das Vorgehen von jemand anderem? Viele gängige Praktiken und sogar Teile mancher Standards sind lediglich Nachahmungen die, wenn man sie zurückverfolgt, sich als zufällige Auswahl von jemandem herausstellen, der gar keine Antworten gesucht hat.
Wie wird die Gültigkeitsdauer des Schlüssels berechnet? Setzt der Verkäufer ein Jahr an, weil es so üblich ist? Ein Schlüssel hat eine kryptographische Lebensdauer. Er hat auch eine Diebstahlswahrscheinlichkeit, die sich aus der Angreifbarkeit des aufbewahrenden Systems, dem Grad der physischen und netzwerkseitigen Erreichbarkeit, seiner Attraktivität für einen Angreifer usw. ergibt. Aus diesen Angaben kann man eine Verlustwahrscheinlichkeit des Schlüssels als Funktion von Zeit und Nutzungshäufigkeit berechnen. Nimmt der Verkäufer diese Berechnung vor? Welcher Wahrscheinlichkeitsgrad wird angenommen um einen Schlüssel für ungültig zu halten?
Unterstützt der Händler den Widerruf von Zertifikaten oder Schlüsseln? Zertifikatswiderrufslisten ("Certificate Revocation Lists") (CRLs) sind in einigen Zertifizierungsstandards vorgesehen, aber viele Implementierungen vermeiden sie, da man sie für veraltete Überbleibsel hält. CRLs werden als zu groß und als zu überholt angesehen um noch relevant zu sein. Wenn sie jedoch nicht genutzt werden, wie werden Widerrufe dann gehandhabt?
Wenn der Widerruf unterstützt wird, wie wird die Kompromittierung eines Schlüssels festgestellt, damit der Widerruf ausgelöst werden kann? Können Widerrufe rückwirkend sein, d.h. kann ein Zertifikatsinhaber nachträglich bestreiten eine Unterschrift geleistet zu haben? Wenn ja, sind die Unterschriften so datiert (mit einem Zeitstempel versehen), dass man gültige von verdächtigen unterscheiden kann? Wird dieser Zeitstempel von einer verläßlichen Instanz vergeben?

Wie lang sind die erzeugten öffentlichen Schlüssel und warum wurde diese Länge gewählt? Unterstützt der Händler 512-bit lange RSA-Schlüssel weil sie schnell sind oder 2048-bit lange Schlüssel weil der Typ da drüben gesagt hat, er halte sie für sicher?
Setzt der richtige Umgang mit den Zertifikaten Aktionen des Benutzers voraus? Führt der Benutzer diese Aktionen auch aus? Wenn man zum Beispiel mit seinem Browser eine SSL-Verbindung aufbaut gibt es einen optischen Hinweis darauf, das der Verbindungsaufbau erfolgreich war und die Verbindung verschlüsselt ist. Aber mit wem unterhält man sich eigentlich auf dieser sicheren Verbindung? Solange man sich nicht die Zeit nimmt, das erhaltene Zertifikat zu lesen weiß man es nicht.
Und selbst dann kann man nicht sicher sein (siehe Risiko #4 weiter oben). Aber wenn man nicht mal hinschaut, dann ähnelt die Situation dem Betreten eines dunklen Raumes: man weiß, dass jemand da ist und das niemand Drittes die Unterhaltung belauscht, aber solange man nicht weiß wer die andere anwesende Person ist, solange sollte man über nichts geheimes reden.

Risiko #10: "Warum nutzen wir diesen CA-Prozeß überhaupt?"
Ein Angestellter eines PKI-Herstellers vertraute uns vor einigen Jahren an, dass ihre PKI-Lösung sich hervorragend verkaufe, die Kunden aber immer noch unzufrieden seien.
Nachdem die CA installiert war und alle Angestellten ein Zertifikat erhalten hatten kam der Kunde zum Händler und fragte "OK, wie funktioniert jetzt das single sign-on?" Die Antwort war natürlich "Gar nicht. So etwas erfordert grundlegende Änderungen der zugrundeliegenden Systemsoftware."
Single Sign-On (SSO) könnte der Durchbruch für die PKI werden. Mit SSO kommt man morgends zur Arbeit, führt seine Smart-Card ein und nach Eingabe einer PIN zur Aktivierung hat man mit Logins für den Rest des Tages nichts mehr zu tun da alles vom SSO-Mechanismus gehandhabt wird.
Verlockend, nicht wahr? Natürlich ist das verlockend, Authentisierung ist nervtötend. Wir würden alles tun um sie zu umgehen.
Unglücklicherweise wird der Sicherheitsgewinn durch Authentisierung durch SSO komplett zunichte gemacht. Durch Authentisierung kann man sicherstellen, das der Nutzer an dem Computer zum Zeitpunkt der Eingabe anwesend ist. Ist man jedoch per SSO angemeldet und muss plötzlich mal raus kann jeder der an dem PC vorbeikommt sich irgendwo im Netz anmelden.
Warum also stürzen sich so viele auf die CA? Werden Zertifikate nur genutzt weil es jeder macht und dieses Jahr angesagt ist? Oder weil die Verantwortung weitergeschoben werden soll: wenn irgendwo unsichere Stellen auftauchen ist es eben der PKI-Experte schuld?
So zynisch wollen wir gar nicht sein. Unsere Einschätzung ist, das Sicherheit sehr kompliziert ist, sowohl zu verstehen als auch umzusetzen. Gestresste Systemadministratoren und IT-Manager haben keine Zeit sich in dieses Thema umfassend einzuarbeiten. Sie lesen die Handelspresse die, beeinflusst durch die PKI-Hersteller, das Loblied der PKIs singt. Und PKI-Verkäufer wissen, was gestresste Leute brauchen: eine möglichst einfache Lösung. "Kauf das hier und Du wirst sicher sein." ist es was sie anbieten. Die Realität bleibt hinter diesen Versprechungen notgedrungen weit zurück aber immerhin geht es hier um das Geschäft und die am besten zu hörenden Stimmen sind die, die etwas zu verkaufen haben. Caveat emptor!

Bruce Schneier ist Autor von "Angewandte Kryptographie" (ISBN 3893198547, Originaltitel "Applied Cryptography"), des Blowfish und Twofish Verschlüsselungsalgorithmus und Dutzender Fachartikel über Kryptographie und Computersicherheit. Er ist der CTO von Counterpane Internet Security Inc., einer führenden Firma in den Bereichen Einbruchserkennung und -vorbeugung, präventive Bedrohungserkennung, forensische Forschung und unternehmensweiter IT-Systemanalyse.
Sein kostenloser monatlicher e-mail newsletter Crypto-Gram kann unter http://www.counterpane.com abonniert werden.
Carl M. Ellison ist Senior Security Architect bei Intel mit besonderem Schwerpunkt Kryptographie, Zugangskontrolle mit kryptographischen Mitteln und Public-Key-Zertifikaten. Bevor er sich auf die Kryptographie konzentrierte, befasste er sich mit Systemdesign mit Schwerpunkt auf verteilten und vernetzten Systemen.


Anm. des Übersetzers: Ich bin kein professioneller Übersetzer, es ist also möglich und wahrscheinlich, dass einiges besser hätte übersetzt werden können. Sollten mir grobe und/oder sinnentstellende Fehler, die korrigiert werden müssen unterlaufen sein oder Sie sonstige Anmerkungen, Kritiken oder gar Lob haben, so können Sie mich unter jochen_berner@hotmail.com erreichen.
Den englischen Originaltext finden Sie unter http://www.counterpane.com/pki-risks-ft.txt


[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04511
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06248
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1158
Comments: 0