Pregunta | Respuesta |
Datenvertraulichkeit | gewährleistet die Vertraulichkeit von Informationen auf Kommunikations-kanälen und im Datenspeicher, um Offenlegung zu verhindern Allg. Use Cases: personenbezogene Daten, geheimes Dokument Use Cases IoT: Smartwatch-, Prozessdaten Typ. Abwehrmechanismen: Verschlüsselung, physikalischer Schutz Typ. Angriffe: Diebstahl, Social Engineering |
Daten befinden sich... | ...auf Geräten gespeichert ...in Transit ...im Kopf bzw. auf Papier |
Verschlüsselung von Daten | unverschlüsselte Daten werden leicht gestohlen deshalb gespeicherte Daten verschlüsseln, um sie vor Diebstahl oder unbefugtem Zugriff zu schützen: vollständige Festplattenverschlüsselung ("gesamtes Gerät", Beispiel-Tool: Veracrypt) Dateisystem-Verschlüsselung Datenbank-Verschlüsselung |
Verschlüsselung von Daten - Problem | nach dem Entsperren können Daten zugänglich sein (lokale Personen, Hacker mit Fernzugriff, Anwendungen) Schlüssel müssen ausreichend geschützt sein Viele kleine Geräte unterstützen keine Verschlüsselung (Kosten, wird als nicht-notwendig erachtet) Verwendung eigener (unsicherer) Krypto-Implementierungen |
Sniffing | Angriffe, bei denen die Kommunikations-verbindung angezapft wird, um die Kommunikation zwischen zwei oder mehreren Partnern zu belauschen Gründe: Netzwerkanalyse (legal) zur Fehlersuche, Überwachung des Netzwerkverkehrs... Angriff auf Vertraulichkeit und Integrität von Daten (Abhören vom Telefon...) |
Sniffing - Modi | promiscuous Mode: Erfassung aller Daten, die an der Netzwerkkarte ankommen (Wahl des Angreifers) non-promiscuous Mode: nur Daten eigener MAC-Adresse erfasst ABER: auch abhängig vom Typ der Verbindung (Broadcast- vs geswitchte Netzwerke) |
Man-in-the-Middle-Angriff (MitM) | Angreifer leitet heimlich die Kommunikation zwischen zwei Parteien (die glauben, dass sie direkt miteinander kommunizieren) weiter und verändert diese möglicherweise Maßnahmen: Verschlüsselung & Authentifizierung |
MitM-Angriffe - Vielfalt | ARP-Spoofing direkt zwischen Parteien oder über die ARP-Tabelle eines Routers Web-Spoofing durch betreiben eines gefälschten Webservers über den Kommunikation im Web verläuft Man-in-the-Browser (Benutzerbrowser kompromittiert) über offene, aber bösartige, WLAN-Zugangspunkte |
Address Resolution Protocol (ARP) | bildet globale IP- auf lokale MAC-Adressen in einer ARP-Tabelle ab in jedem lokalen Netzwerk / IP-Subnetz erforderlich |
ARP-Spoofing | zustandlos -> alle ARP-Antworten akzeptiert (auch ohne Anfrage) Angreifer nutzt dies um gefälschte ARP-Antworten zu senden => Manipulation von ARP-Tabellen, Umleitung des IP-Verkehrs zum Angreifer-Host (jetzt MitM) |
Secure Socket Layer (SSL) | Ziel: Sicherheit für Mosaic-Web-Sitzungen Basis für Entwicklung des Standards Transport Layer Security (TLS) |
Transport Layer Security (TLS) - SIcherheitsdienste | Authentizität von Kommunikations-instanzen (Client & Server bauen somit eine TLS-Sitzung auf) Verschlüsselung bei Zustimmung (Auswahl aus verschiedenen symmetrischen Algorithmen) Authentizität & Integrität von Nachrichten durch Nachrichten-Authentifizierungscodes |
Public Key Infrastructure | sorgen für Vertrauen in Bezug auf öffentl. Schlüssel Zertifizierungsstellen (Certification Authorities, CA) verifizieren Vertrauenswürdigkeit von Instanzen Digitale Zertifikate bescheinigen, dass der in ihm enthaltene öffentl. Schlüssel zu der im Dokument beschriebenen Instanz gehört |
Public Key Certificates | bestätigt Legitimität eines öffentl. Schlüssels Browser hat eine Reihe vertrauenswürdiger öffentl. Schlüssel vorinstalliert |
Kernaufgaben von Zertifizierungsstellen | sicherstellen, dass die Person/ Organisation, die Zertifikat beantragt, die angegebene Identität vertritt Signieren von digitalen Zertifikaten mit ihrem privaten Schlüssel (Überprüfung mit öffentl. Schlüssel der CA) |
Zertifizierungsstellen | es gibt in der realen Welt viele CAs, die hierarchisch organisiert sind => Chain of Trust (eigene Zertifizierung durch höhere Instanz) daher kommt es auch vor, dass Zertifikate selbstsigniert sind |
TLS - Sitzungen & Verbindungen | Sitzung: wird vor eigentlicher Kommunikation eingerichtet (Authentifizierung, Austausch von Sicherheitsparametern) Verbindung: eigentliche Kommunikation |
TLS - Zustandsinformation Sitzung | Session Identifier (Byte-Folge) Peer Certificate (optional) Compression Method (vor Verschlüsselung) Cipher Spec (kryptographische Alogrithmen und deren Parameter) Master Secret (48 Bytes zwischen Client & Server) Is Resumable (mehrere Verbindungen gleichzeitig?) |
TLS - Zustandsinformationen Verbindung | Server and Client Random (Zufallsbytefolge durch Client oder Server vorgegeben) Server Write MAC Secret (Schlüssel, der in MAC-Berechnung auf Server-Seite einfließt) Client Write MAC Secret (Schlüssel, der in MAC-Berechnung auf Client-Seite einfließt) Server Write Key (Schlüssel, für die Ver- & Entschlüsselung von Nachrichten des Servers) Client Write Key (Schlüssel, für die Ver- & Entschlüsselung von Nachrichten des Clients) |
TLS - Protokoll-Architektur | |
TLS Record Protocol - Sender | 1. Fragmentierung der Daten in Records 2. Optionale Kompression der Records 3. Berechne MAC des Records (kryptographischer Hash über Input) 4. Verschlüssele Record und MAC |
TLS Record Protocol - Empfänger | 1. Entschlüssele Record und MAC 2. Prüfe MAC des Records (analoge Berechnung zum Sender mit Hash) 3. Dekompression der Records (falls notwendig) 4. Defragmentierung der Records zu Daten |
TLS Handshake Protocol | Authentifizierung der Kommunikationspartner Aushandlung kryptographischer Parameter optional: Verhandlung ob TLS Session wiederaufnehmbar ist (vereinfachter Handshake bei Wiederaufnahme, wichtig bei HTTP-Sitzung bestehend aus mehreren TCP-Verbindungen) |
TLS 1.2 - Normaler Handshake | |
TLS 1.2 - verkürzter Handshake | |
TLS 1.3 - Handshake | reduziert den Overhead => im besten Fall können die Peers bereits im zweiten Schritt gesicherte Daten austauschen |
Heartbleed | TLS-Schwachstelle in Heartbeat Extension (sichere Kommunikationsverbindung ohne jedes Mal neu ausgehandelt zu werden) umgestaltete Heartbeat-Anfrage mit kleiner Nutzlast und großem Längenfeld => Auslesen des Speichers möglich |
TLS 1.2 - Berechnung Sitzungsschlüssel | 1. Pre-Master-Secret (zufällig (RSA-geschützt) oder Diffie-Hellman) 2. aus Pre-Master-Secret und Rc bzw. Rs leiten beide Seiten mittels PRF Master-Secret ab (Master-Secret = PRF(Pre-Master-Secret, "master secret", Rc|Rs) [0..47]) 3. Aus dem Master-Secret werden vier Verbindungsschlüssel (bit-weise aus Key-Block) berechnet |
(Perfect) Forward Secrecy | Eigenschaft bestimmter Schlüssel-austauschprotokolle, die sicherstellt, dass Sitzungsschlüssel nicht kompromittiert werden, selbst wenn privater Schlüssel des Servers kompromittiert wird (erfüllt durch Diffie-Hellman, aber nicht durch RSA) Problem: Angreifer könnte Schlüsselaustausch aufzeichnen und rückwirkend Sitzungsschlüssel berechnen |
Social Engineering | psychologische Manipulation von Menschen, damit sie Handlungen ausführen oder vertrauliche Informationen preisgeben |
Social Engineering - Beispieltechniken | Vortäuschung oder Nachahmung: Szenario vorgetäuscht, um ein Opfer so zu beeinflussen, dass es Informationen preisgibt (Phishing-Mails, KI...) Baiting: Angreifer hinterlässt Speichermedium mit Schadcode Gegenmaßnahmen: Sicherheitsschulung / Security Awareness |
Schutz der Daten während Verarbeitung | Homomorphe Kryptographie: Berechnungen auf verschlüsselten Daten Andere Lösungen entschlüsseln Daten vor Verarbeitung kurzzeitig und verschlüsseln sie dann wieder |
¿Quieres crear tus propias Fichas gratiscon GoConqr? Más información.