Datei und Ordnerverschlüsselung mit EFS (Encrypting File System)

Obwohl sich der Zugriff auf Files in Computersystemen durch eine sichere Authentifizierung und Berechtigungen auf Dateisystemebene schützen lässt, kann dies nicht mehr gewährleistet werden, wenn ein Angreifer physischen Zugriff auf den Rechner hat (z.B. Diebstahl Firmenlaptop).
Der Angreifer könnte diese Sicherheitsmaßnahmen aushebeln, indem er ein anderes Betriebssystem aufspielt bzw. von einer Live-CD startet oder die Festplatte in ein anderes System einbaut.
Um dies zu verhindern, kann ein Anwender mit einem X.509 Zertifikat für EFS vertrauliche Dateien auf einem NTFS Filesystem so verschlüsseln, dass diese auch bei physischem Rechnerzugriff nur lesbar sind, wenn der entsprechende Entschlüsselungsschlüssel vorhanden ist.

EFS ist ein Windows Standard-Tool und verwendet zur Verschlüsselung eine Kombination aus symmetrischen und asymmetrischen Verschlüsselungsverfahren (siehe Kombination symmetrischer / asymmetrischer Verschlüsselung). Der Inhalt der Datei wird mit symmetrischen AES, 3DES oder DESX chiffriert, der symmetrische Verschlüsselungsschlüssel selbst wird – mithilfe des öffentlichen Schlüssels des EFS-Benutzerzertifikats – RSA bzw. ECC verschlüsselt.
Der private Schlüssel des Benutzers verbleibt gesichert im Benutzerprofil oder auf einer SmartcardEFS Encrypting File SystemEine EFS verschlüsselte Datei kann auch vom Eigentümer für mehrere Personen freigegeben werden, dazu wird der symmetrische Verschlüsselungsschlüssel zusätzlich mit dem Public Key aus den  Benutzerzertifikaten der zugriffsberechtigten Personen verschlüsselt und in der Datei abgelegt

Anm.: Vorbeugend für den Fall, dass ein privater Schlüssel beschädigt oder verloren geht, kann der private Schlüssel vorher auf eine sicheres Medium exportiert werden oder  alternativ in Active Directory basierten IT-Infrastrukturen auf OU Ebene ein Data Recovery Agent bestimmt werden, der als letzte Instanz mit einer Art Generalschlüssel die Dateien wiederherstellen kann.
Dies bedeutet, dass bei jedem Verschlüsselungsvorgang einer Datei durch einen Benutzer, der symmetrische Verschlüsselungsschlüssel zusätzlich noch einmal durch den öffentlichen Schlüssel des Recovery Agents verschlüsselt abgelegt wird

Nachteile von EFS:

  • EFS schützt Dateien nicht, wenn die gesicherten Dateien vom Ersteller über das Netzwerk übertragen werden. Bevor sie gesendet werden, werden die Dateien immer zuerst entschlüsselt.
  • EFS kann keine Systemdateien oder ganze Festplattenvolumes verschlüsseln, für diesen Fall müsste hardwarebasierte TPM Verschlüsselung wie z.B. BitLocker verwendet werden, diese ist dann aber immer maschinenbezogen und nicht personenbezogen wie EFS
Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

Anwendungsszenarien die von einer Public Key Infrastructure profitieren

Eine Public Key Infrastructure ermöglicht einem Unternehmen diverse Anwendungsszenarien, die eine signifikante Verbesserung der IT-Sicherheit zulassen. Die Auswahl der geplanten Anwendungsszenarien gilt gleichsam als erster Schritt bei der Erstellung einer PKI Strategie (späterer Beitrag).
Im Folgenden sollen einige dieser Möglichkeiten vorgestellt werden.

Darunter:

PKI Anwendungen / PKI Applications

Veröffentlicht unter Allgemein, PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

DNSSEC – Domain Name System Security Extensions

Das originäre DNS-Protokoll zur Auflösung von Namen in IP-Adressen bietet keinerlei Sicherheitsmechanismen und ist deshalb anfällig gegenüber Man-In-The-Middle, Spoofing und DNS-Cache Poisoning Angriffen.

Schwachstelle Client – DNS Server
Ein Angreifer kann sich z.B. bei einer DNS Abfrage  eines Clients zwischenschalten und ihm eine gefälschte Antwort auf den DNS-Query liefern (z.B. eine IP-Adresse die ihn an einen anderen Rechner lenkt), noch bevor ihm sein eingetragener DNS Server antwortet.

Schwachstelle DNS Server zu DNS Server
Der Angriff kann auch dadurch erfolgen, dass der Verkehr zwischen zwei DNS-Servern manipuliert wird, indem ein weiterer gefälschter Record in eine Antwort eingeschleust wird, für die der sendende DNS Server eigentlich nicht autoritativ ist.
Der empfangende DNS Server nimmt  den gefälschten Record dann evtl. in seinen Cache auf und leitet die ihn selbst anfragenden Clients dann an die gefälschte Zieladresse weiter.

Attacking DNS Infrastructures

Gegenmaßnahmen
DNSSEC ist eine aktuelle Protokollerweiterung, welche die DNS Sicherheit durch Datenintegrität und Ursprungsbeweis über Signaturmechanismen deutlich ausweiten kann.
Dabei signiert der DNS-Server, der für eine Zone autoritativ ist, seine Zoneneinträge mit einem privaten Schlüssel.
Anfragende DNS-Server können dann, wenn sie mit dem korrespondierenden Öffentlichen Schlüssel (Trust Anchor bei DNSSEC genannt) ausgestattet wurden, die Zoneneinträge auf ihre Integrität und Unverfälschtheit prüfen.
Im Gegensatz zu den DNS-Servern können anfragende Endclients selbst keine DNSSEC Signierung prüfen, sie müssen sich dabei vollständig auf ihren lokalen DNS-Server verlassen.

Windows Implementierung
Zur Absicherung des Verkehrs zwischen Client und lokalem DNS-Server kommt in Windows Implementierungen eine spezielle IPSec-Richtlinie (siehe IPSec ) zum Einsatz, die auf X.509 Zertifikaten basiert (Client mit Clientauthentifizierungszertifikat, DNS-Server hat spezielles Serverauthentifizierungszertifikat mit DNS EKU).
Zusätzlich kann ab Windows 7 ein Client explizit über eine NRPT-Regel (Name Resolution Policy Table) so konfiguriert werden, dass er von seinem eingetragenen DNS Server auch nur solche Antworten annimmt, bei denen dieser eine DNSSEC Signaturprüfung vorgenommen hat.

DNSSec Auf Windows Clients

Stand heute hat sich DNSSEC – vor allem auf Grund der nur langsam fortschreitenden Implementierung im öffentlichen DNS Namespace – noch nicht weitgehend durchgesetzt.  Ein weiterer Nachteil von DNSSEC ist, dass in Windows Umgebungen Änderungen an der signierten DNS-Zone nur noch manuell vom  DNS-Administrator vorgenommen werden können.

Ein durchaus  sinnvoller PKI-gestützter Einsatzrahmen in einem Unternehmen kann dagegen in Hochsicherheitsbereichen sein, bei denen nur eine eingeschränkte Menge an Clients eine Namensauflösung durchführen muss.

Vgl. Seshadri, Shyman; Lindsay, Greg: „Windows Server 2008 R2 – DNSSEC Deployment Guide“.  S.53-60.

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

802.1x am Switchport für sicheren LAN Zugriff

Bei klassischem drahtgebundenen Ethernet gilt es ebenso zu verhindern, dass unbefugte Personen einen Zugriff zum Netzwerk erhalten.
Ohne spezielle Schutzmaßnahmen kann jeder der innerhalb des Firmengeländes physischen Zugriff auf eine Netzwerkdose erlangt, eigene Geräte (z.B. Laptop) anschließen und das Netzwerk attackieren (Port Scans, Rogue DHCP Server etc.).
Manche Switches bieten als Gegenmaßnahmen MAC-Filter pro Port bzw. spezielle DHCP Snooping Maßnahmen an, doch diese sind weitgehend umständlich zu administrieren (jeder Switchport muss einzeln für die entsprechenden MACs konfiguriert werden) bzw. leicht zu umgehen (z.B. mit MAC Spoofing).
Weitaus effektiver und flexibler ist der Einsatz einer 802.1x Authentifizierung mit RADIUS. Damit ist analog zu Wireless Verbindungen (siehe W-LAN und 802.1X) eine Computer bzw. Benutzerbezogene Authentifizierung mit den entsprechenden X.509 Zertifikaten möglich, eine standardmäßige Verschlüsselung des Verkehrs zum Authenticator findet dabei aber im Gegensatz zu WPA/WPA2 nicht statt.

X.509 Zertifikate im Local Area Network

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

W-LAN und 802.1x

Auch bei der Verwendung von Wireless LAN Clients (Laptops, Tablets/PDAs, Smartphones), steigert der Einsatz von X.509 Zertifikaten – in Kombination mit einem RADIUS-Server – die Sicherheit deutlich.

Die Verschlüsselung von Drahtlosverkehr erfolgt grundsätzlich ab  OSI-Layer 2, aktuell werden dazu der WPA (Wi-Fi Protected Access)  Standard mit RC4 basierter TKIP (TKIP – T emporal Key Integrity Protocol) Verschlüsselung, respektive WPA2 mit verbesserter AES basierter CCMP (CCMP – Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) Verschlüsselung verwendet. Beide WPA Versionen gibt es jeweils in einer Personal und einer Enterprise Variante.

WPA/WPA2 Personal
Die Personal Variante basiert dabei auf einem am Access Point vorkonfigurierten Preshared Key (PSK), ein bis zu 63-stelliger ASCII Wert, der nach einer festen Formel in einen 256-Bit Schlüssel umgewandelt wird. Der Nachteil dieses Verfahrens besteht darin, dass jeder Zugriffsclient den identischen Schlüssel vorkonfiguriert haben muss. Gelingt es einem Angreifer z.B. durch eine Social Engineering Attacke auch nur einen dieser PSKs in Erfahrung zu bringen, kann er mit beliebigen Clients dem Netzwerk beitreten und auf die Ressourcen zugreifen. Die einzige Möglichkeit den Angreifer wieder aus dem Netz zu drängen besteht dann darin, alle Schlüssel sowohl auf dem Zugriffspunkten als auch auf den Clients zu tauschen.

WPA/WPA2 Enterprise
Die WPA Enterprise Varianten umgehen diesen Umstand, indem sie zwingend eine 802.1x RADIUS Authentifizierung mit Zertifikaten verlangen. Dadurch besitzt jeder Zugriffsclient ein individuelles, sperrbares Schlüsselpaar mit zudem deutlich erweiterter Schlüsselkomplexität, um Angriffe zu erschweren.

Die WPA/WPA2 Enterprise RADIUS-Authentifizierung kann Computer oder Benutzerbezogen erfolgen:

  • Für die Computerbezogene Authentifizierung muss am Zugriffsclient ein Computerauthentifizierungszertifikat mit dem korrekten DNS-Namen im Computer Store installiert sein, sowie in Windowsumgebungen der Client Mitglied der Domäne sein (bzw. ein vordefiniertes Mapping auf ein Manuell erstelltes Computerobjekt existieren). Die Computerbezogene Authentifizierung bewirkt, dass sich der Client schon im Netz befindet, noch bevor sich der erste Benutzer einloggt. Dies hat den Vorteil, dass schon vorab eine Verbindung zum Verzeichnisdienst aufgebaut werden kann bzw. auch remote administrative Aufgaben wie z.B. Softwareupdates, Monitoring am Client durchgeführt werden können, ohne dass zuvor eine Benutzerbezogene Authentifizierung durchgeführt werden muss.
  • Für die reine Benutzerbezogene Authentifizierung können analog zu (Kapitel VPN mit Zertifiakten) jeweils die Verfahren PEAP-MSCHAPv2, EAP-TLS bzw. PEAP-TLS mit den jeweiligen X.509 Zertifikaten verwendet werden. Erst mit der abgeschlossenen Authentifizierung des Benutzers wird ein Zugriff auf das Netz erteilt.
  • Eine Kombination beider Methoden macht z.B. Sinn, wenn man die Computerauthentifizierung nur für den Zugang zu beschränkten Ressourcen zulässt (z.B. nur Zugriff auf separates V-LAN mit Update Servern) und einen unbeschränkten Netzzugang erst mit anschließender Benutzerbezogener Authentifizierung freischaltet.
Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

IPSec – Sicherer Kanal auf Layer 3

Im Unterschied zu TLS/SSL und SSH setzt IPSec schon auf der dritten Ebene des OSI Modells (Network Layer) an, um Daten im Transit abzusichern. IPSec kann dabei jeglichen IP basierten Verkehr unabhängig vom verwendeten Anwendungsprotokoll absichern. Im Gegensatz zum ungesicherten Standard IPv4 Protokoll bietet die IPSec Protokollsuite auch

  • Nichtabstreitbarkeit durch Signierung,
  • Authentifizierung und
  • Verschlüsselung von Verkehr.
  • Zudem kann durch konfigurierbare Regelsätze der Verkehr zwischen zwei Endpunkten nach bestimmten IP-Adressen, verwendeten Protokollen, Verkehrsrichtung etc. gefiltert werden = Basis-Firewallfunktion auf Protokollebene.

Sinnvolle Einsatzszenarien innerhalb des Unternehmens sind z.B. das End-to-End Absichern des Verkehrs zwischen sicherheitskritischen Servern und Arbeitsstationen. Optional kann IPSec auch als sichere Site-to-Site Tunneling Lösung verwendet werden, falls die beteiligten Endpunkte nicht über ein Standard VPN-Protokoll kompatibel sind. Dies ist allerdings selten der Fall und meist wird nur der Transportmodus für IPSec verwendet. Nichtsdestotrotz gibt es mit L2TP/IPSec ein reines VPN Protokoll auf IPSec-Basis, das weithin Verwendung findet (siehe Kapitel VPN mit Zertifikaten). IPSec profitiert von PKI Diensten, indem für die sichere gegenseitige Authentifizierung der Kommunikationsendpunkte auch die Verwendung von X.509 Zertifikaten ermöglicht wird.

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

Echte und sichere VPN Authentifizierung über X.509 Zertifikate

Immer dann, wenn Mitarbeiter  außerhalb des Unternehmens (z.B. Roadwarrior im Vertrieb, Homeworker, Smartphone-Einsatz) auf das interne Firmennetzwerk zugreifen müssen, ist besondere Vorsicht geboten.

Um die Kommunikation über ein unsicheres öffentliches Netzwerk wie das Internet sicher zu gewährleisten, werden VPN Tunnel  aufgebaut, die den Verkehr vom Endgerät bis zum VPN Gateway der Firma durchgehend verschlüsseln (End-to-Site Tunneling).  Während der Dauer der VPN-Verbindung befindet sich der Client logisch im Firmen-LAN und der Mitarbeiter kann sich dann z.B. mit RDP auf seinen Arbeitsplatz verbinden und die gewohnte Arbeit durchführen. Ebenso ist es als Alternative zu herkömmlichen Standleitungen möglich, mit VPN Technologien Firmenstandorte über unsichere Netze wie das Internet zu verbinden (Site-To-Site Tunneling).

Verbreitete Protokolle für die Erstellung eines VPN-Tunnels sind z.B.

  • PPTP,
  • L2TP/IPSec,
  • SSL basierte VPN-Protokolle wie SSTP
  • oder in Sonderfällen  auch natives IPSec im Tunnelmodus (siehe IPSec).

1. Verbindungsaufbau der einzelnen VPN Protokolle

Alle diese Protokolle benutzen zum Verbindungsaufbau das PPP (Point-to-Point) Protokoll zusammen mit Benutzerauthentifizierungsmethoden, verwenden dabei aber unterschiedliche Herangehensweisen:

  • PPTP bspw. verschlüsselt die Daten erst (!), wenn bereits über PPP eine erfolgreiche Benutzerauthentifizierung stattgefunden hat,
  • hingegen erstellen SSTP und L2TP/IPSec schon vorab eine gesicherte Verbindung. Hierzu verwendet SSTP ein X.509 Serverzertifikat am Gateway, das sich gegenüber dem VPN-Client authentifiziert – damit kann der Anwender auch sicher sein, dass er seine Zugangsdaten dem richtigen Server anvertraut.
  • L2TP/IPSec setzt zusätzlich noch Client Zertifikate voraus, damit sich auch die VPN-Clients gegenüber dem Server authentifizieren müssen.

Nur mit Zertifikaten kann eine echte, eindeutige Authentifizierung zwischen den Device-Identitäten auf Gateway und Clientseite stattfinden

VPN_Certificate_Based_Device_Authentication

2. Benutzerauthentifizierung im VPN
Ohne eine PKI ist man bei der VPN-Benutzerauthentifizierung auf  passwortbasierte Methoden (PAP, CHAP, MSCHAPv2) beschränkt und die Sicherheit des Systems korreliert direkt mit der Komplexität der verwendeten Benutzerpasswörter.

Durch die Verwendung des EAP-Frameworks ist es aber möglich verschiedene erweiterte Authentifizierungsmethoden in die PPP Authentifizierung mit einzubinden, damit kann die Benutzerauthentifizierung z.B. auch über Benutzerzertifikate oder Smartcards erfolgen (z.B. EAP-TLS, PEAP-TLS), womit das Problem der schwachen Passwörter behoben wird.

X.509 Benutzerauthentifizierung VPN
Erweiterte Flexibilität bei der Kontrolle des VPN-Zugriffs kann zudem durch den Einsatz von RADIUS erzielt werden

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

Erweiterte Authentifizierung mittels 802.1x und Radius

Für Netzwerke mit mehreren Zutrittspunkten bietet sich eine zentral gesteuerte Authentifizierung und Protokollierung der Verbindungen an, um den administrativen Aufwand klein zu halten.

802.1x
Mit 802.1x gib es ein solches Zugriffsframework, das den Zugriff auf ein Netzwerk zulässt oder ablehnt. Es besteht in der Regel aus 3 Komponenten:

  • Supplicants: Clients, die den Zugriff auf ein Netzwerk anfordern, indem sie Authentifizierungsanfragen mit dem EAP-Protokoll an einen Authenticator senden.
        • EAP (Extensible Authentication Protocol):Authentifizierungsframework, das die Einbindung verschiedener Authentifizierungsmethoden erlaubt z.B. 2-Faktor über Zertifikate/Smartcards  etc.
  • Authenticator: Zugriffsgateway (VPN Gateway, W-LAN Access Point, Ethernet Switch), das jeglichen Verkehr – außer dem Authentifizierungsverkehr – solange blockt, bis eine erfolgreiche Authentifizierung stattgefunden hat. Der Authenticator leitet alle Authentifizierungsanfragen der Supplicants an den Authentication Server weiter.
  • Authentication Server: zentraler Server, der die  weitergeleiteten Authentifizierungsanfragen mehrerer Authenticator validiert und ihnen das  Ergebnis der Überprüfung rückmeldet. Erst bei positiver Rückmeldung erlaubt der Authenticator dem Supplicant den gewünschten Netzwerkzugang.

RADIUS als Authentication Server für 802.1X
Eine weit verbreitete Implementierung für den Authentication Server ist der RADIUS (Remote Authentication Dial In User Service) Standard, der auch von Internet Providern für den Zugriff auf ihre Backbones verwendet wird. Dieser Standard kann neben der reinen Authentifizierung zusätzlich Autorisierung und Accounting (zentrale Protokollierung der Verbindungen) durchführen.

  1. Dabei prüft der RADIUS Server zuerst die grundsätzliche Authentifizierungsanforderung der Supplicants (korrekte Credentials bzw. Zertifikate) gegenüber einem Verzeichnisdienst wie Active Directory und
  2. wendet bei Erfolg bestimmte Autorisierungsrichtlinien auf die Verbindung an. Diese enorm flexiblen Richtlinien untersuchen, ob bestimmte weitere Bedingungen für die Verbindung erfüllt sind  (z.B. korrekte Benutzer/Computergruppe, Uhrzeit, Zugriffsart, IP-Adresse etc.) und weisen die Verbindung ggf. trotz gültiger Authentifizierungsangaben ab.

Erweiterte Policies und Quarantäne
Eine RADIUS-Implementierung kann ferner mit einem Network Policy Server (NPS) kombiniert werden, der noch erheblich detailliertere Zutrittskontrollen erlaubt. Haben die Supplicants bestimmte Prüf-Agenten installiert, kann der NPS bspw. ermitteln, ob ein Zugriffsclient die aktuellen Virenschutzdefinitionen/ aktuellen Updates installiert hat bzw. die Host-Firewall aktiviert ist. Ist dies nicht der Fall, wird der Client vom NPS temporär in eine vom internen LAN abgeschottete Quarantänezone – meist  ein spezielles V-LAN – verwiesen.

Die Quarantänezone erlaubt dem Client ggf. die fehlenden Komponenten z.B. mit Hilfe eines Update Servers nachzuinstallieren, ehe er über einen weiteren Authentifizierungsvorgang noch einmal versuchen kann, dem internen Netzwerk beizutreten.

Zertifikate in Kombination mit Radius und 802.1x

Alle RADIUS Authentifizierungsversuche müssen stets über das EAP-Protokoll erfolgen, zudem muss auf dem RADIUS Server ein X.509 Serverzertifikat mit Serverauthentifizierungs-EKU installiert sein, um seine Identität gegenüber den Supplicants zu beweisen.

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

TLS/SSL Verschlüsselung und X.509 Zertifikate

TLS (Transport Layer Security) bzw. vormals SSL (Secure Socket Layer)  Verschlüsselung ist das am weitesten verbreitete Anwendungsszenario einer PKI. TLS ermöglicht die Erstellung eines sicheren Kanals zwischen zwei Endpunkten, indem es bestimmten Anwendungsverkehr (HTTPS, SMTPS, FTP over SSL etc.) auf der Sitzungsschicht des OSI Modells durch Verschlüsselung schützt.

  • In TLS werden asymmetrische Algorithmen für die Authentifizierung und den Schlüsselaustausch verwendet, symmetrische Algorithmen dagegen für die Bulk Encryption der Daten.
  • Neben Vertraulichkeit durch Verschlüsselung bietet TLS auch eine Authentifizierung und eine Integritätsprüfung über Hashalgorithmen an.

Webserver und SSL/TLS – Server beweist seine Identität gegenüber den Clients

Häufige Verwendung findet TLS auf Webservern, die Clients über ein Webserverzertifikat ihren öffentlichen Schlüssel anbieten. Vertraut der Client dem Zertifikat (zusätzlich kann er noch eine Sperrlistenprüfung durchführen – siehe auch Certificate Chaining and Validation), so kann er mit dem öffentlichen Schlüssel des Webservers verschlüsselten Web-Verkehr sicher über ein eigentlich unsicheres Netz übertragen.

ssl tunnel client to webserver

SSL/TLS und Clientauthentifizierung – der Client beweist seine Identität gegenüber dem Webserver

Standardmäßig authentifiziert sich nur der Server gegenüber dem Client indem er sein Zertifikat präsentiert, der Webserver kann aber zusätzlich so konfiguriert werden, dass auch er eine Authentifizierung des Clients über ein Clientzertifikat verlangt.

Dabei gibt es im IIS zwei Möglichkeiten, die beide den potenziellen Anwenderkreis einschränken:

– Zertifikat ohne Certificate Mapping: Der Client benötigt ein Zertifikat mit Clientauthentifizierungs-EKU um sich zu Authentifizieren. Es wird lediglich die Gültigkeit des Zertifikats, sowie die Vertrauenswürdigkeit des Ausstellers geprüft. Ein etwaiges Login Formular muss aber vom Anwender weiterhin manuell mit Benutzername/Passwort ausgefüllt werden.

–  Zertifikat mit Certificate Mapping: Im Verzeichnisdienst oder direkt am Webserver wird eine Zuweisung eines (1:1 Mapping) oder mehrerer Zertifikate (N:1 Mapping) mit einem Benutzerkonto erstellt. Präsentiert der Zugriffsclient dann ein zum Mapping passendes Zertifikat, so wird er automatisch als das entsprechende Benutzerkonto authentifiziert und braucht keine Benutzername/Passwort Kombination mehr einzugeben. Somit sind Erraten des Passwortes, sowie einfache Social Engineering bzw. Brute Force Angriffe auf das selbige kaum mehr möglich.
Exchagne Active Sync mit Client Zertifikaten

  • In einem mittelständischen Unternehmen eignet sich TLS in Kombination mit dem HTTPS Protokoll vor allem, um Kunden einen sicheren Zugriff auf Portal- bzw. Extranetlösungen über das Web zu gewähren.
  • Auch für das sichere Abrufen von Unternehmens-Emails über Smartphones wird TLS in Kombination mit Active Sync over Exchange eingesetzt.
  • Ebenso arbeiten Terminalserver – alternativ zum RDP Protokoll – mit TLS.

Der Nachteil von TLS liegt darin, dass die  IP Quell- und Zieladresse der Kommunikationspartner nicht verborgen werden und es daher anfällig für Datenverkehrsanalysen ist – weiterhin ist keine Garantie der Nichtabstreitbarkeit möglich.


Vgl. Morimoto, Rand et al.: „Windows Server 2003 unleashed“, S. 344-345.

 

Veröffentlicht unter PKI: Anwendungen und Applikationen, PKI: Kryptografische Grundlagen | Hinterlasse einen Kommentar

Smartcardanwendungen

Viele PKI-Anwendungen erlauben den Einsatz von Smartcards. Smartcards sind kreditkartenähnliche Chipkarten, die für kryptografische Operationen (Cryptographic Service Provider) wie z.B. die Erzeugung asymmetrischer Schlüssel ausgerichtet sind. Zusätzlich besitzen sie einen Speicher, in dem die privaten Schlüssel, sowie die Zertifikate einer Entität sicher abgelegt werden können. In der Regel werden Smartcards nach einer Identitätsprüfung personalisiert für bestimmte Nutzer ausgestellt und mit einer PIN versehen, die nur der Benutzer selbst kennt. Die Verwendung von Smartcards hat folgende Vorteile:

  • Sicherheit: Ein Angreifer müsste in Besitz der Karte kommen und die PIN ausspähen, um die Smartcard einsetzen zu können. Social Engineering Angriffe sind schwieriger, da eine personalisierte Smarcard kaum aus der Hand des Besitzers gegeben wird. Auch Brute Force Angriffe auf Passwörter gestalten sich – durch die deutlich höhere Schlüssellänge im Vergleich zu  Standardpasswörtern – als schwierig.
  • Portabilität: Zertifikate und Schlüssel werden portabel. Der Nutzer kann seine Karte an einen beliebigen Rechner mit Smartcardleser einstecken und auf eigene Schlüssel und Zertifikate zugreifen bzw. damit neue Schlüssel generieren, um Zertifikate anzufordern und zwar unabhängig davon ob er Zugriff auf die Daten seines Benutzerprofils hat.
  • Flexibilität: Smartcards können im Gegensatz zu One-Time Password Token mehrere Schlüssel und Zertifikate für verschiedene Zwecke speichern und sind daher deutlich flexibler einsetzbar.

Statt Smartcards gibt es auch sogenannte USB Tokens mit ähnlichen Eigenschaften. Sie haben den Vorteil, dass kein Kartenleser für deren Einsatz nötig ist, dafür sind sie etwas weniger robust und benötigen einen freigeschalteten USB Port, der sie für Hochsicherheitsumgebungen weniger attraktiv macht.

Ein häufiger Einsatzzweck  einer Smartcard ist z.B. die sogenannte  2-Faktor Authentifizierung (Besitz: Karte + Geheimnis: PIN) beim Windows Logon.

Smart Card und USB Token von SafeNET/Aladdin

Folgende weitere Einsatzszenarien für Smartcards sind:

  • Benutzerauthentifizierung bei VPN-Zugriff (EAP-TLS, PEAP-TLS)
  • Benutzerauthentifizierung bei WPA/WPA2 Enterprise W-LAN (EAP-TLS/PEAP-TLS)
  • TLS Benutzerauthentifizierung über Smartcards für Websites
  • EFS Dateiverschlüsselung (möglich ab Windows Vista / Server 2008)
  • Signieren und Verschlüsseln von E-Mails mit S/MIME
  • Code Signing mittels Smartcards
Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar