IT-Sicherheit für 04INM 6. Application Layer Security. 6. Application Layer Security Überblick: Literatur: z.b.: [1, 2] PGP+SMIME SET/HBCI

Transkript

1 IT-Sicherheit für 04INM 6. Application Layer Security Prof. Dr. Uwe Petermann Dept. of Computer Science University of Applied Sciences Leipzig P.O.B D Leipzig (Germany) May 29, 2006 Datendarstellung Anwendung FTP DNS SNMP 6. 1 Einordnung in den Protokollstapel OSI-Modell TCP/ Standards/Protokolle Anwendungsschicht Kommunikationssteuerung Transport Transport SSL ssh TLS PCT SGC NFS Vermittlung Vermittlung ICMP IGMP ARP RARP Sicherung Netzwerk- Ethernet Tokenring Bitübertragung zugang ATM SL PPP... SNMP Simple Network Management Protocoll ICMP Internet Control Message Protocoll ARP Address Resolution Protocoll RARP Reverse Address Resolution Protocoll IGMP Internet Group Management Protocoll U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 1 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 3 IT-Security, 05INM 6. Application Layer Security Überblick: Literatur: z.b.: [1, 2] 1. Einordnung in den Protokollstapel 2. Sicherungsmöglichkeiten für Anwendungen 3. Sicherheit im WWW 4. Elektronische Post 5. File Transfer Sichere Dateisysteme zu 6. 2 Sicherungsmöglichkeiten für Anwendungen PTPT L2TP Sec SSL / ssh Secure FTP Secure S- PGP+SMIME SET/HBCI U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 2 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 4 IT-Security, 05INM

2 zu Sicherungsschicht (Data link) Point-To-Point-Tunneling-Protocol Layer-2-Tunneling-Protocol Protokolle der Sicherungsschicht kommunizieren nur zwischen unmittelbar verbundenen Rechnern nur Verbindung zwischen je 2 benachbarten Rechnern absicherbar sind zur Sicherung von Internet-Diensten in eher speziellen Fällen geeignet zu Transportschicht SSL ssh PCT TLS SGC Entscheidung über Nutzung der sicheren Dienste kann von den darüberliegenden AnwendungsProtokollen je nach Bedarf erfolgen allerdings ist anders als bei z.b. Sec das Kommunikationsverhalten ausspähbar U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 5 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 7 IT-Security, 05INM zu Vermittlungsschicht (Network) Sec Bestandteile : SKEME, ISAKMP, OAKLEY, IKE, SK Anwendungen müssen bei Verwendung von z.b. Sec nicht modifiziert werden andererseits haben die Anwendungen keinen Einfluß auf die genutzten Mechanismen u.u. würde mit Schutz mittels Sec zuviel getan: z.b. Schutz des gesamten Verkehrs eines öffentlich zugänglichen Web-Servers zu In der Anwendungsschicht Integration von Sicherheit in Anwendungsprotokolle flexibel: Sicherheitslösung kann der Anwendung angepaßt werden. allerdings: Sicherheitsdienste müssen für jeweilige Anwendung entwickelt werden U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 6 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 8 IT-Security, 05INM

3 zu Oberhalb der Anwendungsschicht unsichere Anwendung wird genutzt übertragene Information selbst wird geschützt Beispiel: Verschlüsseln und Signieren von elektronischer Post mittels PGP zu 6. 3 WWW Paßwortverfahren zur Authentifizierung des Klienten: Name + Paßwort in zu schützenden Seiten kann entsprechende Abfrage vorgesehen werden Browser fragt Klient nach diesen Daten sehr schwaches Verfahren, da gesamte Kommunikation im Klartext U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 9 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 11 IT-Security, 05INM Fazit: Wahl der zu nutzenden Sicherheitsmechanismen richtet sich nach der zu lösenden Aufgabe. Besondere Verbreitung erlangten allerdings Sicherheitsdienste auf der Ebene der Transportschicht. weiter zu 6. 3 WWW S- von IETF-AG Web Transaction Security dikutiert noch nicht als RFC veröffentlicht draft_ietf_wts_shttp_nn.txt SSL Transaktionssicherheit Serverauthentifizierung mittels SSL-Zertifikat in neueren Versionen auch Clientenauthentifizierung mittels SSL-Zertifikat möglich keine Nachweisbarkeit von Transaktionen U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 10 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 12 IT-Security, 05INM

4 zu 6. 4 Elektronische Post Gefährdungen: allgemein: keine Verschlüsselung auf dem Transport beim Senden und Abholen: i.a. keine permanente Verbindung zum Mail-Server bei der Zustellung: Auslieferung der Post über i.a. mehrere Mail-Server weiter zu 6. 4 Elektronische Post PGP: nicht offiziell standardisiert wirkt jedoch durch sehr weite Verbreitung wie ein Standard Verschlüsselung der Nachrichten: IDEA oder 3DES Signatur der Nachrichten: RSA oder Diffie-Hellman (bis 4096 Bit) + DSS (Digital Signature Standard) Hash: MD5, REMD-160 oder SHA-1 Probleme: MIME-Anhänge nicht explizit unterstützt U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 13 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 15 IT-Security, 05INM weiter zu 6. 4 Elektronische Post Lösungenprinzipien: Vertraulichkeit: Nachricht mit symmetrischen Schlüssel des Absenders sichern diesen Schlüssel mit öffentlichen Schlüssel des Empfängers sichern Authentizität: Absender signiert Nachricht (oder deren Fingerabdruck) mit seinem privaten Schlüssel noch weiter zu 6. 4 Elektronische Post S/MIME: Standard für Formate gesicherter s application/pkcs7-mime Param.: any Dateiendung: any application/pkcs10 Param.: any Dateiendung: any multipart/signed Param.: protocol=\"application/pkcs7-signature" Dateiendung: any application/octet-stream Param.: any Dateiendung: p7m, p7s, aps, p7c, p10 U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 14 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 16 IT-Security, 05INM

5 noch weiter zu 6. 4 Elektronische Post weiter zu S/MIME: entworfen von Firmengruppe unter Leitung von RSA symmetrische Verschlüsselung: DES, 3DES, RC2 (block cypher, unterstützt variable Schlüssellängen) asymmetrische Verschlüsselung: RSA, Standard (RCF) bezieht sich auf PKC#7 und PKC#10 Anwendung, z.b. -Client muß Kryptographie selbst implementieren ( Zertifikate: hierarchische Infrastruktur RFC 2311: S/MIME V.2 Message Specification zu 6. 5 File Transfer FTP : weder übertragene Daten noch Steuerverbindung geschützt Alternativen FTP über ssh FTP Security Extensions (IETF) Protokoll-Erweiterung um Befehle zum Aushandeln der zu benutzenden kryptographischen Verfahren zur Sicherung der Verbindung wenig verbreitet U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 17 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 19 IT-Security, 05INM noch weiter zu 6. 4 Elektronische Post Abholen der Post: POP (Post Office Protocol) Passwort offen übertragen Verbesserung: zusätzliches Auth-Kommando (MD5-hash von Zeitmarke + Geheimnis) selten von Servern implementiert IMAP (Internet Message Access Protocol) Verschlüsselungsverfahren ebenfalls selten von den Servern unterstützt zu 6. 6 unsicher Alternative1: Tunneln über ssh Alternative2: Secure RPC (Remote Procedure Call) Authentication (SRA) mangelhaft implementiert Alternative3: Secure (CERT IT + Uni Milano) nicht kompatibel zu U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 18 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 20 IT-Security, 05INM

6 zu 6. 7 Sichere Dateisysteme noch weiter zu 6. 7 Sichere Dateisysteme Andrew File System (AFS): 1986 von CMU entwickelt, um Schwächen von NFS zu überwinden 1989: Entwickler wechseln zu Transarc (seit 1994 IBM-Tochter) heute: Versionen 3.0 und 4.0 des Distributed File System (DFS) des Distributed Computing Environment (DCE) der OSF Funktion: weitgehend analog zu NFS + Sicherheit Kerberos, gegenseitige Authentifizierung (simple oder complex) U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 21 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 23 IT-Security, 05INM weiter zu 6. 7 Sichere Dateisysteme Cryptographic File System (CFS): verschlüsseln von Daten bei lokalem Speichern, Senden zu bzw. Speichern auf File-Servern, Backup-Erstellung Verschlüsselung transparent auf jedem UNIX-System aufsetzbar Schnittstelle: z.b. /crypt Schlüsseleingabe: Passwort-Phrase (per Hand) oder von SmartCard Windows Encrypting File System (EFS): Windows NT und Windows 2000 Übertragung zwischen Server und Client unverschlüsselt References [1] S. Fischer, C. Rensing, and U. Rödig. Open Internet Security. Springer-Verlag, Berlin Germany, [2] A. J. A. J. Menezes, P. C. Van Oorschot, and S. A. Vanstone. Handbook of applied cryptography. The CRC Press series on discrete mathematics and its applications. CRC Press, 2000 N.W. Corporate Blvd., Boca Raton, FL , USA, [3] M. Schumacher, U. Rödig, and M.-L. Moschgatj. Hacker Contest. Springer, U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 22 IT-Security, 05INM U. Petermann, Leipzig University of Applied Sciences, C.S. Dept. 24 IT-Security, 05INM