Private Key Protection in Windows – Sichern der privaten Schlüssel

Private Schlüssel werden, sofern sie nicht auf einer Smartcard abgelegt wurden, verschlüsselt im Application Data Ordner des Benutzerprofil eines Users  bzw. dem All Users Profil des Systems abgelegt (%APPDATA%\Microsoft\Crypto\).

Geschützt werden die Schlüssel durch die Data Protection API im Windows Kernel.

Securing Private Key in WindowsEin privater Schlüssel wird zuerst durch einen symmetrischen Session Key verschlüsselt, der sich wiederum aus einem Encryption Key und dem Master Key ableitet. Der Encryption Key bildet sich aus nicht geheimen Daten des Benutzerprofils und des Systems, die eigentliche Sicherheit entsteht durch den Master Key.

Der Master Key als wichtigster Schlüssel befindet sich unter:

%USERPROFILE%\AppData\Roaming\Microsoft\Protect\{SIDdesUsers}

Der Master Key wiederum wird durch den Master Key Encryption Key  geschützt, der sich aus dem Benutzerpasswort ableitet.  Verwendete Algorithmen sind u.a. 3DES im CBC Mode sowie SHA-1 etc.

Beschädigte Mater Keys können über folgende Verfahren wiederhergestellt werden:

  • Rechner in einer Domäne legen eine mit öffentlichem Schlüssel des Domänencontrollers verschlüsselte Kopie des private Keys im Active Directory ab
  • Credential History erlaubt Zugriff auf alte Master Keys die mit alten User PW verschlüsselt wurden – somit kann auch nach der Änderung des Windows Passworts auf die alten Private Keys zurückgegriffen werden
  • Verwenden einer Windows Password Recovery Disk, die ein neues Benutzerpasswort generiert und den Master Key wiederherstellt: DPAPI generates a 2048-bit RSA public/private key pair, which is the recovery key. The current password is then encrypted with the public key and stored in the user’s profile, while the private key is stored to the PRD, which can actually be any removable media, and then removed from memory. The private key is only stored on the PRD, and nowhere else, so it is important for a user to keep the PRD in a safe place“

Enable Strong Private Key Protection

Da alle Anwendungen die im Benutzerkontext laufen unkontrolliert auf die privaten Schlüssel des Benutzers zugreifen könnten, kann ein Zertifikat so ausgestellt werden, dass bei jedem Schlüsseleinsatz des privaten Schlüssels eine zusätzliche Benutzerinteraktion oder eine Passworteingabe erforderlich ist. Dies erhöht den Schutzlevel des private Keys und verhindert ungewollte Aktionen z.B. das Anstoßen von CodeSigning durch Malware. Für noch höhere Sicherheit empfiehlt sich aber eine hardwarebasierte Ablage der Schlüssel durch bspw. Token, Smartcards oder HSMs.

Setzen Strong Private Key Protection:

  • Im Certificate Template
  • Im  Zertifikatsimport Wizard
enableStrongProtection im Import Wizard

Auswahl von „Medium“ (nur Zustimmung des Nutzers) oder „High“ (zusätzlich PW Eingabe) möglich

Auswirkung Stong Private Key Protection

Strong Private Key Protection - Medium

Vgl. De Clercq, Jan.: „Windows Server 2003 Security Infrastructures“, K. 13.4.4 – 13.4.5.

Vgl. NAI Labs, Network Associates, Inc.: „Windows Data Protection“ http://msdn.microsoft.com/en-us/library/ms995355.aspx (abgerufen am 26. November 2014).

Vgl. Radutskiy, Alex [MSFT] : „What is a strong key protection in Windows?“ http://blogs.technet.com/b/pki/archive/2009/06/17/what-is-a-strong-key-protection-in-windows.aspx (abgerufen am 26. November 2014).

Veröffentlicht unter PKI: Komponenten und Prozesse, PKI: Kryptografische Grundlagen | 3 Kommentare

Sicherheit im E-Mail Verkehr

Die klassische E-Mail ist seit jeher so sicher wie das Versenden einer Postkarte.
Das zum Versand verwendete SMTP-Protokoll arbeitet im Klartext – d.h. jedes Paket kann auf der Strecke vom Sender bis zum Empfänger mühelos abgefangen, gelesen, ggf. verändert und wieder weitergeleitet werden.
Eine Identifizierung von Absender bzw.  Empfänger und eine Prüfung der Nachrichtenintegrität findet dabei nicht statt.
Auch Mail Spoofing – also das Fälschen des Absendernamens ist daher meist einfach möglich, was zu großen unternehmensinternen Problemen führen kann, wenn z.B. illegitim Angebote, Bestellungen, Arbeitsanweisungen etc. unter einer fremden E-Mail Adresse vorgenommen werden.

Verbindlichkeit und Integrität im E-Mail Verkehr kann aber über das Instrument der Digitalen Signatur erlangt werden (siehe Digitale Signatur ), wogegen die Vertraulichkeit durch Verschlüsselung erreicht wird.
Beide Technologien lassen sich bei E-Mail über die Standards S/MIME und PGP einsetzen, wobei sich das auf PKI-Strukturen und auf X.509 Zertifikaten basierende S/MIME, auch aufgrund der nativen Implementierung in Microsoft Komponenten, weitgehend durchgesetzt hat.

Für den unternehmensinternen S/MIME Einsatz gibt es zwei grundlegende Ansätze:

End-to-End Signatur/Verschlüsselung am E-Mail Client: Bei diesem Ansatz muss jeder Mitarbeiter eigenverantwortlich die Signatur und Verschlüsselung von E-Mails am E-Mail Client ( Outlook, Thunderbird etc. ) durchführen. Während die Signatur von E-Mails – vorausgesetzt man besitzt ein entsprechendes X.509 Zertifikat für S/MIME Signatur –  noch relativ einfach zu handhaben ist, ist für den Einsatz der S/MIME Verschlüsselung eine Anwenderschulung unumgänglich.

  • Das Problem bei der Verschlüsselung liegt im Schlüsselmanagement, das auch hier beim Endanwender selbst liegt. Eine verschlüsselte Mail kann immer erst gesendet werden, wenn das entsprechende Zertifikat des Empfängers (mit dessen öffentlichen Schlüssel) sich bereits in den eigenen Kontakten befindet.
    D.h. der E-Mail Empfänger muss dem Sender vorher einmalig sein Zertifikat übermittelt haben und dieser muss es selbständig in seine Kontakte importieren.

Weitere Nachteile:

  • Der Empfänger muss für jedes Gerät (z.B. Smartphone), mit dem er verschlüsselte E-Mails abruft, den privaten Schlüssel vorhalten.
  • Stellvertreterregelungen sind schwierig, da der Stellvertreter mit den personalisierten Zertifikaten der Originalentität arbeiten müsste.
  • Verschlüsselte E-Mails können nicht von Antiviren-Software geprüft werden.

Vorteile:

  • Eignet sich, wenn nur wenige Mitarbeiter Signieren/Verschlüsseln sollen.
  • Einzige End-to-End Lösung – nur auf diesem Weg wird die Signatur/Verschlüsselung unberührt bis zum Empfänger gesendet.
  • Einfache Implementierung für firmeninternen E-Mail Verkehr bei Einsatz einer Exchange-Lösung, da die Zertifikate der Empfänger einfach über die Globale Adressliste ausgelesen werden können.

 S/MIME mittels eines Unternehmensgateways:

Spezielle Signaturgateways, entweder hardwarebasiert oder als virtuelle Appliance, bieten ein zentralisiertes Management für Digitale Signatur und Verschlüsselung mit S/MIME. Das Signaturgateway wird dem eigentlichen E-Mail Gateway vorangestellt und kann je nach Hersteller und Konfiguration auf eine der folgenden Arten arbeiten:

  •  Ein spezielles E-Mail Gatewayzertifikat wird für eine gesamte E-Mail Domäne z.B. concept.com verwendet, um ausgehenden Verkehr zu signieren. TC Trustcenter bietet bspw. solche Zertifikate an.
  • Es wird ein zentral gesteuertes 1:1 Mapping von Zertifikaten zu E-Mail Adressen durch einen Administrator angelegt.
  • Die MailSealer Lösung von Reddoxx liefert bspw.  eine eigene CA am Gateway selbst, die in die unternehmensinterne PKI eingeordnet werden kann. Die CA erstellt dann bei der ersten ausgehenden E-Mail eines Benutzers automatisch ein S/MIME Zertifikat und ordnet es dem Benutzer zu.

Vorteile (je nach Leistungsumfang):

  • Zentrales S/MIME Management durch Gateway Administratoren möglich
  • Verschlüsselte E-Mails werden zentral am Gateway entschlüsselt und können anschließend von Antivirensoftware inspiziert werden.
  • Automatisches Lernen eingehender öffentlicher Zertifikate möglich.
  • Verschlüsselung/Signierung nach bestimmten Regeln z.B. Text im Betreff der E-Mail bzw. Anwenden der Regeln auf bestimmte Gruppen.
  • Benachrichtigung des Nutzers bei erfolgreicher Signaturprüfung eingehender E-Mails z.B. durch einen angehängten Prüfbericht
  • Automatisches Abweisen von signierten oder verschlüsselten Mails ein bzw. ausgehend.

Nachteile:

  • keine echte End-to-End Signatur/Verschlüsselung, da Verifizierbarkeit nur bis zum Unternehmensgateway geht.
  • Nachrichten, die mit Gatewayzertifikaten signiert wurden, werden von vielen empfangenden E-Mail Lösungen abgelehnt, da der Name im Zertifikat nicht mit der Absenderadresse übereinstimmt.

SMIME Gateway

Vgl. Carius, Frank: „Signieren und Verschlüsseln auf dem Gateway“. http://www.msxfaq.de/signcrypt/gateway1limitierungen.htm (abgerufen am 10. September 2011).

Vgl. Carius, Frank: „Signieren und Verschlüsseln auf dem Gateway – Vorteile“. http://www.msxfaq.de/signcrypt/gateway2vorteile.htm (abgerufen am 10. September 2011).

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

Signieren von Anwendungscode

Microsoft-Anwendungen, wie z.B. Internet Explorer, Windows Installationsroutinen etc.  verfügen über Sicherheitsfunktionen zur Überprüfung, ob eine digitale Signatur  für eine auszuführende Anwendung vorhanden ist und geben eine Empfehlung für das weitere Vorgehen des Benutzers aus.

Code Signierung mit X.509 Zertifikaten ist für Unternehmen sinnvoll, die selbst Softwareprodukte anbieten und nicht wollen, dass bei den Kunden Warnungen angezeigt werden bzw. um das Vertrauen in das Softwareprodukt zu erhöhen. Der Kunde kann  sicher sein dass die Software unmanipuliert und unverfälscht zur Ausführung gebracht wird.

Für nicht signierte Anwendungen bzw. von einer unbekannten CA eingesetzte Zertifikate wird dabei je nach Sicherheitseinstellungen ein roter Warnhinweis angezeigt oder die Inhalte können schlicht nicht ausgeführt werden.

Ist die Anwendung signiert und dem Zertifikat wird vertraut – so wird lediglich eine Informationsmeldung angezeigt.

CodeSigning

Anm.: Wenn der Herausgeber vom Anwender zusätzlich explizit zu den „Vertrauenswürdigen Herausgebern“ im Zertifikatmanagement  hinzugefügt wird (manuell oder mit „Immer Software von Herausgeber ausführen“ s. Grafik) so kommt zukünftig auch keine Informationsmeldung mehr, wenn Anwendungen dieses Herausgebers geöffnet werden.

Für das Signieren von Code muss ein Zertifikat mit der EKU „Code Signing“ vorhanden sein. Um Windows Code bspw. .exe Dateien zu signieren, kann das Programm Signtool.exe, das im Windows SDK enthalten ist, verwendet werden. Für eine sichere Code Signing Infrastruktur empfiehlt sich die Verwendung von HSMs oder zumindest Token/Smartphones.

Code Signing gibt es auch für Java Plattformen wie J2SE und J2ME.

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

Digitale Signatur in Dokumenten

Nur durch den Einsatz der Digitalen Signatur kann technisch festgehalten werden, dass ein bestimmtes  Dokument zu einer bestimmten Entität gehört und nicht manipuliert wurde.

Je nach Signaturgesetzgebung im entsprechenden Einsatzland gilt die Signatur auch als Ersatz der eigenhändigen Unterschrift auf einem Dokument (in DE nur bei qualifizierter Signatur siehe Elektronische Signaturen in Unternehmen). Für den Einsatz der Digitalen Signatur in Dokumenten ist ein X.509 Zertifikat nötig, für das die EKU „Document Signing“ freigegeben ist (siehe Zertifikatsattribute)

 Digitale Signatur in Office-Dokumenten

Office Dokumente können entweder nicht sichtbar oder sichtbar mit einer Signaturzeile digital signiert werden. Sobald ein Dokument signiert wurde, ist der Inhalt schreibgeschützt und kann nicht mehr abgeändert werden, ohne die Signatur zu zerstören.

  • Bei der nicht sichtbaren Signatur  wird das Signatursymbol schlicht in der Statuszeile des Dokuments angegeben

NichtSichtbareDigitaleSignatur

  • Bei der sichtbaren Signatur können ein oder mehrere Signaturzeilen in das Dokument eingefügt werden. Die Signaturzeile wird dann mit dem Zertifikat signiert, weiterhin kann eine Grafik mit der eigenen Unterschrift eingefügt bzw. direkt auf einem Tablet unterschrieben werden. Man kann das Dokument auch mit dem Auftrag zur Signaturerstellung manuell an den Empfänger weiterleiten. Mithilfe von Microsoft Sharepoint sind auch automatisierte Workflows zur Signaturerstellung möglich.

Sichtbare Digitale Signatur in Microsoft Office

Digitale Signatur in PDF Dokumenten

Auch PDF Dokumente können digital signiert werden. Mit Adobe Acrobat Reader ist die Signatur eines Dokuments aber nur möglich, wenn das PDF mit Signaturzeile vorher mit einer Adobe Acrobat Professional Version erstellt wurde. Als PDF Alternative bietet sich unter anderem der  günstigere Nitro PDF Professional an, der PDF Dokumente jeglicher Art signieren kann.

PDFSignatur_mit_Nitro_Professional

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

Elektronische Signaturen in Unternehmen

Das deutsche Signaturgesetz unterscheidet verschiedene Signaturtypen, die in einem Unternehmen vorkommen können. Diese Signaturtypen stützen sich dabei (exklusive der einfachen Elektronischen Signatur) auf das kryptografische Verfahren der Digitalen Signatur (siehe Kapitel Digitale Signatur),  differieren dabei aber in  organisatorischen und rechtlichen Kriterien. Eine technische Umsetzung kann im Rahmen der Digitalen Signatur bei E-Mail bzw. durch den Signaturprozess auf Dokumente stattfinden (siehe 3.3.1 und 3.3.2).

Definition:

vgl. § 2 SigG (Signaturgesetz)

Eine elektronische Signatur im Sinne des Signaturgesetzes ist ein Siegel zu elektronischen Daten, das den Absender und die Unverfälschtheit der Daten erkennen lässt. Elektronisch übermittelte Daten können somit auf dem Weg vom Absender zum Empfänger nicht unbemerkt verändert werden.

Rechtliche Rahmenbedingungen:

  • EU-Richtlinie 1999/93/EG über gemeinschaftliche Rahmenbedingungen für elektronische Signatur
  • Signaturgesetz (SigG) und Signaturverordnung (SigV)
  • Bürgerliches Gesetzbuch (BGB): Vorschriften zur Schriftform (insbes.§126)
  • Zivilprozessordnung (ZPO): Beweiskraft elektronischer Dokumente (u.a. 371a/ 445)

Ausprägungen nach deutschem Signaturgesetz

Folgende Signaturtypen gelten nicht als Ersatz der Schriftform:

  • Elektronische Signatur(§ 2 Nr. 1 SigG): Erfüllt  keine besonderen Sicherheitsanforderungen (es reicht z.B. bei E-Mail ein angefügter Name des Urhebers), kann folglich  nicht zweifelsfrei einer Person zugeordnet werden und hat daher wenig Beweiswert. Einsatz nur für formfreie Verträge geeignet.
  • Fortgeschrittene elektronische Signatur (§ 2 Nr. 2 SigG): Ermöglicht eindeutige Zuordnung der Signatur zum Urheber bzw. dessen Identifizierung. Eine nachträgliche Veränderung der signierten Daten ist nicht möglich – dies entspricht der Verwendung eines ausgestellten Signaturzertifikats. Durch erhöhte Anforderungen, auch erhöhte Beweiskraft der Signatur.

Als Ersatz für die Schriftform können folgende Signaturtypen dienen, falls die elektronische Form zulässig ist (entspricht persönlicher Unterschrift):

  • Qualifizierte elektronische Signatur (§ 2 Nr. 3 SigG): Entspricht der Fortgeschrittenen Signatur, die zusätzlich auf einem qualifizierten Zertifikat beruht und mit einer sicheren Signaturerstellungseinheit[2] erzeugt wurde. Um ein qualifiziertes Zertifikat auszustellen, muss der Zertifikatsanbieter die §4 bis §14 des Signaturgesetzes einhalten und die Tätigkeit, sowie die zur Signatur nach  SigG und SigV verwendbaren Komponenten (spezielle Software, Treiber, Klasse 3 Kartenleser mit Tastatur), bei der Bundesnetzagentur anzeigen.

Vorgeschrieben ist die qualifizierte elektronische Signatur:

  • Branchenübergreifend: Elektronische Rechnungen (außer EDI), die zum Vorsteuerabzug berechtigen (am 23.09.2011 rückwirkend zum 01.07.2011 wieder abgeschafft)
  • Justiz: Elektronisches Gerichts und Verwaltungspostfach (EGVP)
  • Verwaltung: Austausch Behörden und Bürger (Projekt ELENA für elektronischen Einkommensnachweis, Arbeitnehmerdaten und Sozialleistungen – Projekt wurde am 18.07.2011 gestoppt)
  • Energiewirtschaft: Emissionshandel (CO2-Zertifikate)
  • Versicherungswesen: Einsatz anstelle von  Papierarchiven für Belege der Sozialversicherung
  • Abfallwirtschaft: Belege des Transports von Sondermüll (elektronischer Abfallnachweis)
  • Gesundheit: zukünftig – Elektronisches Rezept, Elektronische Patientenakte
  • Qualifizierte elektronische Signatur mit Anbieter Akkreditierung (§15): entspricht der Qualifizierten elektronischen Signatur, zusätzlich muss der Anbieter des Zertifikats nach §15 SigG akkreditiert sein. Die Bundesnetzagentur bescheinigt dem Anbieter erhöhte Sicherheit und ermöglicht dem Anbieter den Erhalt qualifizierter Zertifikate der Root CA der Bundesnetzagentur-PKI.

Die qualifizierte Signatur hat sich bis dato weitgehend nicht durchgesetzt, in der Regel reicht die fortgeschrittene Signatur, die auch mit einer eigenen PKI erzeugt werden kann, für die meisten Anwendungen vollkommen aus.


[1] Vgl. Bartonitz, Martin; Lenz, Joerg Matthias.: „Elektronische Signaturen ein Überblick aus der Praxis “ Vortrag zum Informationstag Elektronische Signatur am 23.9.2011 in Berlin.  http://www.slideshare.net/SOFTPROGroup/signaturtag-2011-elektronische-signatur-berblick-aus-der-praxis (abgerufen am 13. November 2011).

[2] Anm.: Smartcard / neuer Personalausweis / neue Gesundheitskarte / Heilberufsausweis / Geldkarte.

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

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