Wiederholung: XML-Grundlagen

Transkript

1 IT-Sicherheit: XML-Sicherheit, Sicherheitskriterien Wiederholung: XML-Grundlagen! extensible Markup Language! XML 1.0 (3. Ausgabe, sowie XML 1.1), W3C Recommendation, Feb 2004! Meta-Language; entwickelt als Teilmenge von SGML! Elemente und Attribute! XML Namespaces! Gruppierung von Namen, identifiziert über URI-Referenzen, die in XML- Dokumenten als Elementtypen und Attributnamen genutzt werden.! XML Schema! Definiert die Struktur, den Inhalt [und ein bißchen Semantik] von XML- Dokumenten einer bestimmten XML-Anwendung! Vgl. Document Type Definition (DTD)! extensible Stylesheet Language (XSL)! Empfehlungen für die Transformation und Darstellung von XML- Dokumenten (inkl. XSLT und XPath) 2

2 XML-Sicherheit! XML wird z.b. ausgiebig im Bereich der Web Services genutzt:! Auf der Web Service-Technologie beruhende Anwendungen tauschen XML-Nachrichten mittels eines Standardprotokolls, SOAP (Simple Object Application Protocol), aus! Sicherung durch SSL/TLS bzw. durch IPsec nicht ausreichend:! U.U. keine Ende-zu-Ende-Sicherheit! Keine digitalen Signaturen! Sicherheit des Kanals, aber keine Sicherheit der Nachrichten! Sichereitsmechanismen für XML erforderlich! Sicherheit auf der Anwendungsebene 3 XMLSec-Dokumente! XML-Signature Syntax and Processing (auch RFC 3275): XML Encryption Syntax and Processing: XML Key Management Specification (XKMS 2.0): 4

3 XML Signatures: Motivation (1)! Bislang: Signieren einer Nachricht M.! Auf der Anwendungsebene Signieren von Dokumenten (und nicht von Nachrichten)! Dokumente haben eine interne Struktur! Baumstruktur von XML-Dokumenten! Dokumente können auf verschiedene Arten dargestellt werden! <a foo = 'yes' boo = "no" /> ist äquivalent zu <a boo = "no" foo = "yes"></a> 5 XML Signatures: Motivation (2)! Teile eines Dokumentes können sich ändern, d.h. es muss genau festgelegt werden, welche Teile signiert werden sollen! Was ist bei der Verifikation der digitalen Signatur zu tun, wenn nur Teile des Dokumentes signiert sind?! Bei der Berechnung einer digitalen Signatur werden viele verschiedene Schritte benötigt! Es muss genau festgelegt werden, welche Algorithmen für die Signierung verwendet werden (dürfen)! XML Signatures behandelt diese Aspekte 6

4 XML Signatures! XML Signatures werden auf digitale Inhalte (sog. Data Objects) über eine Indirektion (URI) angewendet:! Es wird ein Message Digest von den zu signierenden Data Objects gebildet,! das Ergebnis wird (mit Zusatzinformationen) in einem Element abgelegt,! von diesem Element wird wiederum der MD gebildet, der dann (kryptographisch) signiert wird.! Kryptographische Sicherung der Integrität der Zusatzinformationen wie z.b. die anzuwendende Hashfunktion und der Algorithmus zur Signaturbildung 7 Verschiedene Formen der Signatur! Enveloped Signatures:! Die Signatur ist in dem Data Object enthalten! Data Object ist der Vater! Enveloping Signatures:! Data Object ist Teil des Signatur-Elementes; das Signatur-Element ist der Vater! Das Data Object muss dann über einen URI referenziert werden (s. Syntax)! Detached Signatures:! Signatur ist getrennt von dem Data Object! Entweder externes Data Object! oder das Data Object und die Signatur sind Geschwisterknoten innerhalb des XML- Dokumentes! Ein Dokument kann auch mehr als eine Signatur enthalten. 8

5 Überblick über die Syntax von XML Signtures <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature> 9 Grundlegende Elemente! Eine Digitale Signatur wird in einem <Signature>- Element gespeichert. Dieses enthält im Wesentlichen drei Elemente: 1. <SignedInfo>: Informationen über die Signatur wie z.b. den Signatur-Algorithmus, einen URI auf die zu signierenden Daten 2. <SignatureValue>: enthält die digitale Signatur 3. <KeyInfo>: enthält u.a.! den öffentlichen Schlüssel zur Verifikation der Signatur! evtl. die benötigten Zertifikate (X.509- oder auch PGP-Zertifikate)! Weitere Elemente s. Beispiel auf der folgenden Folie 10

6 Ein Beispiel: Detached Signature <Signature Id="MyFirstSignature" xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI=" <Transforms> <Transform Algorithm=" </Transforms> <DigestMethod Algorithm=" <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> <P>...</P><Q>...</Q><G>...</G><Y>...</Y> </DSAKeyValue> </KeyValue> </KeyInfo> </Signature> 11 Referenzen, Transformation Kanonisierung! Referenzen (references):! Optionales URI-Attribut des <Reference>-Elementes verweist auf die zu signierenden Daten (Data Object)! Legt eine Message Digest-Methode fest und enthält den MD des zu signierenden Data Objects! Transformation:! Beispiele: XPath, XSLT des XML-Dokumentes möglich! Kanonisierung (canonicalization):! Spezielle Form der Transformation! Erzeugung einer Normalform des XML-Dokumentes! Verschiedene Algorithmen werden unterstützt 12

7 Ein XML-Dokument... <!DOCTYPE doc [<!ATTLIST e9 attr CDATA "default">]> <doc>!!!<e1!!!/>!!!<e2!!!></e2>!!!<e3!!!name = "elem3"!!!id="elem3"!!!/>!!!<e4!!!name="elem4"!!!id="elem4"!!!></e4>!!!<e5 a:attr="out" b:attr="sorted" attr2="all" attr="i'm"!!!!! xmlns:b=" xmlns:a=" xmlns=" xmlns="" xmlns:a=" xmlns=" xmlns="" xmlns:a=" xmlns="" xmlns:a=" </doc> und eine kanonische Darstellung <doc>!!!<e1></e1>!!!<e2></e2>!!!<e3 id="elem3" name="elem3"></e3>!!!<e4 id="elem4" name="elem4"></e4>!!!<e5 xmlns=" xmlns:a=" xmlns:b=" attr="i'm" attr2="all" b:attr="sorted" a:attr="out"></e5>!!!<e6 xmlns:a=" xmlns=" xmlns="">!!!!!!!!!!!!<e9 xmlns:a=" attr="default"></e9>!!!!!!!!!</e8>!!!!!!</e7>!!!</e6> </doc> 14

8 Algorithmen (1)! Digest! Required SHA1 Encoding! Required base64 MAC! Required HMAC-SHA1 Signature! Required DSAwithSHA1 (DSS) Recommended RSAwithSHA Algorithmen (2)! Canonicalization! Required Canonical XML (without Comments) Recommended Canonical XML with Comments Transform! Optional XSLT Recommended XPath Required Enveloped Signature 16

9 XML Encryption! Verschlüsselung von XML-Dokumenten:! Verschlüsselung des gesamten Dokumentes! Verschlüsselung eines XML-Elementes! Verschlüsselung nur des Inhaltes eines XML-Elementes! Unterschiedliche Teile des Dokumentes können mit unterschiedlichen Schlüsseln verschlüsselt werden! Ähnliche Elemente wie bei XML Signature! Vaterelement: <EncryptedData>! Verschlüsselte Information wird durch dieses Element ersetzt! Kindelemente: folgende Folie 17 Grundlegende Elemente! <EncryptionMethod>! Gibt das Verfahren an, mit welchem die Daten verschlüsselt werden! Beispiele für unterstützte symmetrische Verschlüsselungsverfahren:! 3DES, AES (128-, 192-, 256-Bit CBC),! Stromchiffren werden auch unterstützt, aber es werden keine speziellen Stromchiffren spezifiziert! <CipherData> enthält <CipherValue>-Element: enthält die verschlüsselten Daten! Beispiel: übernächste Folie 18

10 Überblick über die Elemente von XML Encryption <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:keyinfo> <EncryptedKey>? <AgreementMethod>? <ds:keyname>? <ds:retrievalmethod>? <ds:*>? </ds:keyinfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData> 19 Beispiel: XML Encryption <EncryptedData Id='ED' xmlns=' <EncryptionMethod Algorithm=' <ds:keyinfo xmlns:ds=' <ds:retrievalmethod URI='#EK' Type=" <ds:keyname>sally Doe</ds:KeyName> </ds:keyinfo> <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData> </EncryptedData> 20

11 Key Transport! Wird für den Schlüsselaustausch benötigt! <EncryptedKey>-Element! Enthält den symmetrischen Schlüssel, mit einem Public-Key- Verfahren verschlüsselt! Algorithmen (s. auch RFC 2437)! RSA v1.5 Key Transport Algorithmus in Verbindung mit 3DES! RSA v2 Key Transport Algorithmus in Verbindung mit AES! RSAES-OAEP-ENCRYPT Algorithmus für AES und 3DES! Schlüsselvereinbarung nach Diffie-Hellman auch möglich:! <OriginatorKeyInfo>- und <RecipientKeyInfo>-Elemente 21 Sicherheitskriterien, Sicherheitsmanagement

12 Sicherheitskriterien, Sicherheitsmanagement! Bislang in der Vorlesung: Behandlung technischer Themen! Zugriffskontrolle! Firewalls! Krypto! Sicherheitsprotokolle auf verschiedenen Ebenen!...! Die schwierigen Fragen wurden noch gar nicht behandelt:! Wie konstruiere ich ein sicheres System?! Woher bekomme ich die Sicherheitsanforderungen für mein IT-System?! Wie etabliere ich einen systematischen und nachhaltigen Sicherheitsprozess (Sicherheitsmanagement)?! Wie erkenne ich, ob ein IT-Produkt bestimmte Sicherheitsanforderungen erfüllt und bestimmten Qualitätskriterien genügt? 23 Motivation: Sicherheitskriterien! Viele IT-Systeme müssen bestimmte Sicherheitsziele erfüllen:! Betriebssysteme, Anwendungen, Datenbanken, Smartcards,...! Frage: Wie kann man die Sicherheit solcher Systeme bewerten (evaluieren)?! Allgemeine Anerkennung der Evaluationsergebnisse! Möglichkeit des Vergleiches von IT-Systemen mit ähnlicher Funktionalität! Einführung einer Evaluationsmethodik 24

13 Kriterienkataloge! TCSEC (Trusted Computer Evaluation Criteria, 1980)! ITSEC (Information Technology Security Evaluation Criteria, Europa, 1991)! CTCPEC (Canadian Trusted Computer Product Evaluation Criteria, 1993)! CC (Common Criteria, 1996; V2.1 vom April 1999) 25 Trusted Computer Evaluation Criteria TCSEC! US National Computer Security Center (Teil der NSA), 1980! Auch Orange Book genannt! Älteste Kriterien zur Bewertung der Sicherheit von IT-Systemen! Sieben Hierarchiestufen zur Sicherheitsstufen zur Klassifikation eines IT-Systems! Vier Hauptstufen A bis D! fünf Unterstufen (C1, C2, B1, B2, B3)! Niedrigste Stufe ist D 26

14 Die Hierarchiestufen von TCSEC (1)! Stufe D: Minimaler Schutz (Im Grunde gar keine Aussage über Schutz)! Stufe C1: Benutzerbestimmbare Zugriffskontrolle (DAC) für Gruppen:! Benutzer können Rechte nur grobgranular an Gruppen vergeben! Beispiel: gängige Unix-Systeme! Stufe C2: Benutzerbestimmbare Zugriffskontrolle (DAC) für einzelne Benutzer und Audit! Benutzer können Rechte auch an einzelne Benutzer vergeben! Mitprotokollieren der Aktionen einzelner Nutzer! Schutz der Audit- und Authentisierungsinformationen! Beispiel: Windows NT (ohne Netzanbindung!), RACF-OS von IBM, div. speziell für C2 umgerüstete Unix-Varianten 27 Die Hierarchiestufen von TCSEC (2)! Stufe B1: systembasierte Zugriffskontrolle (MAC)! Wie C2, aber zusätzlich Einführung von Sicherheitsmarkierungen (vgl. Bell-LaPadula-Modell)! Stufe B2: Strukturierter Schutz:! Wie B1, u.a. zusätzlich! formales Sicherheitsmodell (security model)! Die Trusted Computing Base (TCB) muss strukturiert sein: Trusted Computing Base = die Komponenten eines IT-Systems, die korrekt arbeiten müssen, damit die Security Policy nicht verletzt wird! Analyse von verdeckten Kanälen! Strikte Tests müssen durchgeführt werden 28

15 Die Hierarchiestufen von TCSEC (3)! Stufe B3: Security Domains! Wie B2, aber TCB muss minimal, ausführlich getestet und gegen unbefugte Zugriffe geschützt sein;! Echtzeit-Monitoring und Mechanismen zur Benachrichtigung! Stufe A: Verifiziertes Design! Keine funktionalen Erweiterungen von B3, aber es wird ein formaler Nachweis gefordert, dass die TCB-Spezifikation und das zugrunde liegende Sicherheitsmodell äquivalent sind! Beispiel: MLS LAN Version 2.1 der Firma Boeing 29 Bewertung: TCSEC! Nur auf Betriebssysteme beschränkt! Betonung von Bell-LaPadula-Policies, Vernachlässigung anderer Schutzziele wie der Integrität und der Verfügbarkeit! Nur auf USA beschränkt! Keine Trennung von Sicherheitsfunktionalität und der Qualität, mit der die Sicherheitsfunktionen erbracht werden 30

16 ITSEC! Europäische Kriterien (Großbritannien, Frankreich, Deutschland, Niederlande), 1991! Einführung von Funktionalitätsklassen F! teilweise Orientierung an den Stufen des Orange Books (F-C1, F-B3,...)! Einführung weiterer Funktionsklasse: Bspw. F-IN besondere Anforderungen an die Integrität! Sieben verschiedene Evaluationsstufen E0,..., E6 (Qualitätsstufen)! E0: Einstiegsstufe,! E6: formale Spezifikation der Sicherheitsanforderungen! Weitere Neuerung: Der Produkthersteller muss die Kosten für Zertifizierung übernehmen.! Gegenseitige Anerkennung der Zertifizierungsergebnisse in europäischen Staaten, bis auf Stufe E6 31 Die Common Criteria! Common Criteria V1.0, 1996! Aktuelle Version:! Common Criteria V2.2, Januar 2004: Keine funktionalen Änderungen im Vergleich zu V 2.1! Zusammenführung von CTCPEC, TCSEC und ITSEC! Im Wesentlichen Orientierung an ITSEC! Weltweit einheitlicher Kriterienkatalog! unter Beteiligung von Deutschland, Frankreich, Großbritannien, Kanada, den Niederlanden und den USA! Internationaler Standard: ISO/IEC (CC V 2.1) 32

17 Zusammenhang mit ITSEC! Orientiert sich an den ITSEC-Kriterien; Weiterentwicklung von ITSEC! Trennung von Sicherheitsfunktionalität und Qualitätskriterien! CC-Evaluierung wird von national akkreditierten Prüfstellen (commercial licensed evaluation facility, CLEFF) durchgeführt! derzeit 13 Prüfstellen in Deutschland (z.b. TÜV Nord SysTec GmbH & Co. KG, T-Systems GEI GmbH, datenschutz nord GmbH)! Prüfstellen werden in Deutschland vom BSI lizenziert! Akkreditierung in den USA von der NSA und dem NIST! Die Kosten der Zertifizierung werden wieder vom Produkthersteller übernommen 33 Struktur der CC-Dokumente! Dokumente (auch in Deutsch) zugreifbar unter Drei Teile:! Teil 1: Einführung in die CC und allgemeines Modell! Glossar, Grundlagen der Evaluation, Schutzprofile, Sicherheitsvorgaben! Verständliche Einführung; diese Folien beruhen auf diesem Material! Teil 2: Funktionale Sicherheitsanforderungen! Kataloge von Empfehlungen für Sicherheitsanforderungen! Teil 3: Anforderungen an die Vertrauenswürdigkeit (assurance) 34

18 Funktionale Sicherheitsanforderungen (1) Teil 2 der CC:! Sicherheitsprotokollierung (FAU)! Kommunikation (FCO)! Kryptographische Unterstützung (FCS)! Schutz der Benutzerdaten (FDP)! Identifikation und Authentisierung (FIA)! Sicherheitsmanagement (FMT)! Privatheit (FPR)! Schutz der EVG-Sicherheitsfunktionen (FPT)! Betriebsmittelnutzung (FRU)! EVG-Zugriff (FTA)! Vertrauenswürdiger Pfad/Kanal (FTP) 35 Funktionale Sicherheitsanforderungen (2) Funktionale Sicherheitsanforderungen an einen Evaluationsgegenstand (Auszug)! Klasse FCS Kryptographische Unterstützung! FCS_COP.1 Kyptographischer Betrieb ( Hashen )! FCS_COP müssen Hashfunktion gemäß SHA-1 oder RIPEMD-160 durchführen...! FCS_COP.2 Kyptographischer Betrieb ( Verifizieren )! FCS_COP müssen Verifikationsalgorithmus gemäß RSA (1024 Bit) durchführen...! FCS_STA.1 Statusprüfung von Zertifikaten! FCS_STA.1.1 Die TSF müssen die Gültigkeit eines Zertifikats zuverlässig feststellen. 36

19 Teil 3 der CC: Vertrauenswürdigkeitsanforderungen! Konfigurationsmanagement (ACM)! Auslieferung und Betrieb (ADO)! Entwicklung (ADV)! Handbücher (AGD)! Lebenszyklus-Unterstützung (ALC)! Testen (ATE)! Schwachstellenbewertung (AVA)! Erhaltung der Vertrauenswürdigkeit (AMA)! Prüfung und Bewertung des Schutzprofiles (APE)! Prüfung und Bewertung der Sicherheitsvorgabe (ASE) 37 Vertrauenswürdigkeitsstufen (1)! Vertrauenswürdigkeitsstufen (Evaluation Assurance Level, EAL)! EAL1: funktionell getestet! EAL2: strukturell getestet! EAL3: methodisch getestet und überprüft! EAL4: methodisch entwickelt, getestet und durchgesehen! EAL5: semiformal entworfen und getestet! EAL6: semiformal verifizierter Entwurf und getestet! EAL7: formal verifizierter Entwurf und getestet 38

20 Vertrauenswürdigkeitsstufen (2)! EALs sind Sammlungen von Vertrauenswürdigkeitsanforderungen aus Teil 3 der CC (s. auch nächste Folie)! EALs entsprechen im Wesentlichen den Evaluationsstufen von ITSEC:! EAL2 entspricht E1,..., EAL 7 entspricht E6! EAL1 wurde neu eingeführt. 39 < ATE_DPT 3: Testtiefe 3 (höchster Detaillierungsgrad beim Testen) 40

21 Schutzprofile (1)! Ein Schutzprofil (protection profile) besteht u.a. aus! einer Sammlung von Sicherheitsanforderungen (die evtl. auch schon in den CC vordefiniert sein können, s.o.)! Bedrohungen! Sicherheitsziele (security objectives)! Einer Erklärung (rationale), die u.a. nachweist, dass die Sicherheitsziele und Bedrohungen einander entsprechen! Evtl. einer EAL 41 Schutzprofile (2)! Darstellung in einer implementierungsunabhängigen Form! Ein Schutzprofil steht für eine Klasse von Produkten! Beispiele:! Firewalls (Paketfilter/Application Gateways)! Rollenbasierte Zugriffskontrolle! Krankenhausinformationssysteme! Smartcards! JavaCard (s. Beispielausdruck)! Weitere Profile siehe 42

22 43 Sicherheitsvorgaben! Sicherheitsvorgabe (security target): eine Menge von Sicherheitsanforderungen und Sicherheitsspezifikationen, die als Grundlage für die Prüfung und Bewertung eines angegebenen Evaluationsgegenstands dienen. Evaluationsgegenstand (target of evaluation, TOE): ein IT-Produkt oder -system, das Gegenstand einer Prüfung ist! Eine Sicherheitsvorgabe (security target) kann eine Verfeinerung (Erweiterung) eines Schutzprofiles sein.! Es gibt aber auch Sicherheitsvorgaben, die nicht auf einem Schutzprofil beruhen.! Implementierungsabhängig /herstellerabhängig! Für jedes TOE muss eine Sicherheitsvorgabe existieren! Gegen diese Sicherheitsvorgabe wird evaluiert. 44

23 45 Vorgehensweise! Standardvorgehensweise 1. Schutzprofil erstellen (falls ein solches noch nicht existiert) 2. Schutzprofil auf Vollständigkeit, Konsistenz und Korrektheit hin evaluieren 3. Sicherheitsvorgabe erstellen 4. Ggf. überprüfen, dass die Sicherheitsvorgabe eine korrekte Verfeinerung eines Schutzprofiles ist 5. TOE gegen die Sicherheitsvorgabe evaluieren 46

24 Zertifizierte Produkte! Unter orderindex=4&showcatagories=-1 findet man eine Liste mit zertifizierten Produkten.! Es gibt zertifizierte Produkte mit der Evaluationsstufe EAL 5+, z.b.:! Infineon Smart Card IC (Security Controller) SLE66CX322P with RSA 2048/m1484 a24/ m1484a27 and m1484b14! GemXplore Xpresso V3 Java Card Platform Embedded Software V3 (Core)! Weltweite Anerkennung nur bis EAL

25 Abschließende Bemerkungen & Bewertung (1)! Vorteile der CC:! Weltweit anerkannter Kriterienkatalog! Anwendbar auf verschiedene Klassen von Produkten (nicht nur auf Betriebssysteme)! Viele Produkte sind bereits zertifiziert worden.! Sicherheitsvorgabe/Schutzprofil nützliche Hilfsmittel zur Entwicklung eines sicheren Systems! Unternehmen können Zertifikate als Wettbewerbsvorteil nutzen: z.b.: Ausschreibungen bzgl. Gesundheits- und Bürgerkarte 49 Abschließende Bemerkungen & Bewertung (2)! Nachteile/Probleme der CC:! CC enthalten keine Evaluationsmethodik (Wie wird von den Prüfstellen evaluiert?).! Aber: zusätzliche Einführung der Common Evaluation Methodology (CEM)! Aufwendiger und teurer Prozess! Nicht jede Prüfstelle ist für jedes Produkt kompetent.! Abhängigkeit der Prüfstellen von den (nationalen) Behörden: Es wird so zertifiziert, wie es offiziell gewünscht wird.! Teilweise werden bekannte Sicherheitsprobleme ignoriert:! Beispiel: Schutzprofil für Krankenhausinformationssysteme setzt voraus, dass alle internen Benutzer wirklich ehrlich sind! 50

26 Nächste Termine Mo, Uhr: Vertiefung XML-Sicherheit, CC Do, Uhr: Sicherheitsmanagement (BSI-GSHB, BS 7799, Bedrohungs- und Risikoanalyse) Übungsblatt 11 bald auf Stud.IP, s.: 51