|
|
 |
 |
|
 Challenge Response with PKI
| One-Time-Pass - Systems
|
Please note, that the Knowledge Base isn't translated to english completely at the moment. You will still find some german texts - we are translating permanently the outstanding parts! Thank you for understanding! |
Authentication with PKI |
| |
|
|
|
Ersetzt PKI andere Formen der Authentifizierung? Ja und Nein, durch die Flexibilität und Eigenschaften einer PKI verschiedenste Prozesse abzusichern ist es möglich, dass man jede Authentisierung auf diese Art und Weise durchführen kann.
Doch nur in Kombination mit anderen Authentisierungsmethoden (Wissen oder Biometrie) ist PKI sinnvoll.
1. Der private Schlüssel muss wiederum geschützt werden und seine Verwendung sollte authentisiert sein. Damit erhält man eine 2-Faktor-Authentifizierung.
2. Außerdem muss eine Zertifizierungsstelle für eine Sperre oder Widerruf eines Zertifikates Prozesse zur Identifikation und Authentifzierung bereithalten, das kann ein Widerrufspasswort, ein schriftlicher Widerufsauftrag mit handschriftlicher Unterschrift oder anhand eines Fotos authentisiert sein.
3. Administratoren sollten bei einem Versagen der PKI nicht selbst ausgesperrt sein sondern auf ein anderes Verfahren zurückgreifen können.
|
|
Private Schlüssel können als Software-Token oder geschützt in einem Hardware-Token vorliegen. Bei beiden Fällen ist eine Aktivierung durch Wissen (PIN) oder Sein (Biometrik) sehr zu empfehlen, um eine 2-Faktor-Authentifizierung zu erreichen.
Die Verwendung eines privaten Schlüssels als Pseudo-Token, sprich eine "private Key" Datei, ist nicht sehr komplex. Der Schutz dieser Datei geschieht im guten Fall mittels Passwort, der bei Standardapplikationen aber auch nicht schwer auszuschalten ist. Durch Verwendung eines Passwortes wiederum landet man erst wieder beim leidigen Passwortproblem.
Durch Verwendung von eigener Software kann der technische Schutz etwas erhöht und eine Passwort-Richtlinie leichter durchgesetzt werden. Die Verwendung von solcher Software als "Virtual Smart Card" bleibt aber suboptimal.
Die Verwendung eines Hardware-Tokens (Smart Card) macht den privaten Schlüssel mobil und bietet besseren technischen Schutz. Der Schutz vor unrechtmäßiger Verwendung muss trotzdem implementiert werden - um ein Smart Card PIN Management kommt man auch nicht herum.
|
|
|
Motive eine PKI einzusetzen |
E-Business - Transaktionen können mit PKI sicher gestaltet werden, durch ihre Eigenschaft der Nicht-Abstreitbarkeit erhalten Finanztransaktionen, Bestellungen oder Anträge eine höhere "Reklamationsresistenz" und neue höherwertige Transaktionen wie Vertragsabschlüsse können problemlos vollkommen online umgesetzt werden.
Die komplette Elektronische Abwicklung von Geschäftsfällen inklusive Verträge, Rechnungen, und Empfangsbestätigungen sowie die abgesicherte Übermittlung, hat eine Reduzierung von Zeit- und Ressourceneinsatz zur Folge.
Bei elektronischen Kommunikationsformen ist die Authentizität des Partners entscheidend, E-Mail, SSL, VPN, WLAN können mit einer PKI im Hintergrund sicher betrieben werden - oder haben sie schon signierte Virenmails bekommen?
Statt viele einzelne Authentifikationssysteme zu designen und zu warten, kann mit einer PKI ein einziges System, verwendet werden, das nur einmal gewartet und überwacht werden muss.
Abgesehen von der allgemeinen Sorgfaltspflicht existieren gesetzliche Regelungen (DSG, KontraG) die bestimmte Schutzmaßnahmen verlangen, bzw. bestimmte Angelegenheiten erst unter besonderen Voraussetzungen zulassen, wie z.B. die Verordnung über elektronische Rechnungen in Österreich.
Das eingegangene Risiko müsste in einer Kostenrechnung als kalkulatorische Kosten Eingang finden, was bisher kaum berücksichtigt wird. Eine Erhöhung des Sicherheitslevels verringert diese. Durch Versicherungsprämien, höhere Kreditzinsen (Basel II-Bewertung) oder durch konkrete Sicherheitsvorfälle haben diese Kosten nicht mehr nur kalkulatorischen Charakter.
|
|
|
Kritische Designfaktoren eines PKI - Projekts? |
Wem, welcher Zertifizierungsstelle, wird vertraut und warum?
Wie sicher sind die Certificate Practises?
Welche Daten bestätigt die CA mit ihrer Autorität tatsächlich?
Womit wurde der Zertifikatsbesitzer identifiziert?
Wie ist das Enrollment organisiert, sind eigene Registration Authorities (RA) beteiligt?
Wie wird der private Schlüssel geschützt?
Wie wurde die Identität festgestellt?
Welche Daten bestätigt die CA mit ihrer Autorität tatsächlich?
Wie sicher ist der verifizierende Rechner?
Welche Anwendungen sind PKI-fähig - wie gehen PKI und SSO zusammen?
Wie wird PKI als Single Point of Failure vermieden?
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
Legal notice