Maximilian Stark (mail@dakror.de), WS2019
Stand: 16.02.2020
IT-Sicherheit
Basics
Risk Landscape: Symantec Internet Thread Report 2019
- Neuer Fokus auf spezialisierte Ransomware (mobile, Unternehmen)
- Angriffsziele
- IoT: Router & IP-Cams
- Supply Chain: Spearphishing bei Zulieferern statt Zero-Day Exploits bei Ziel
- Wahlen: Angriff auf Mailserver in USA
- Hardware: Spectre & Meltdown
- Lessons learned
- Angreifer schneller als Verteidigung
- Notwendigkeit für Secure Engineering
- Zielgerichtetere Attacken
- Notwendigkeit für Signierung, Isolierung, Secure Boot
Safety vs. Security
- Safety
- Schutz nach innen
- Betriebssicherheit, Zuverlässigkeit
- Spezifikation gewünschter Funktionalität
- Security
- Schutz nach außen
- Minimierung der Verwundbarkeit
- Bewahrung vor Missbrauch
- Spezifikation zulässiger Aktionen
Definitionen
- Objekt (Asset): schützenswertes Gut / Information
- Subjekt: Aktive Einheiten, Nutzer von Objekten
- Rechte: Zulässigkeitsbestimmung über Zugriff auf Objekte
- Regelwerk (Policy): Festlegen und Nutzerzuteilung von Rechten
- Schutzziele
- primär: CIA
- Confidentiality: Schutz von unautorisiertem Informationszugang
- Integrity: Schutz vor unautorisierter & unbemerkter Modifikation
- Availability: Schutz vor Beeinträchtigung der Nutzbarkeit
- sekundär
- Authenticity: Echtheitsnachweis, Glaubwürdigkeit
- Accountability: Verbindlichkeit, Unabstreitbarkeit durchgeführter Handlungen
- Privacy: Schutz der Privatsphäre
- Security-Policy: Festlegung von...
- Schutzzielen
- Regeln und Verhaltensrichtlinien
- Maßnahmen zur Gewährleistung der Schutzziele
- Verantwortlichkeiten und Rollen
- Schwachstelle (vulnerability): Lücke im System
- Bedrohung (threat): mögliche Gefahren, die exploits nutzen können
- Risiko R (risk): Wahrscheinlichkeit des Eintritts eines Schadensereignisses (E) mal Höhe des resultierenden Schadens (S), $R = E * S$.
- Angriffsvektor: Möglicher Angriffsweg
Angriffe und deren Ziele
- Netze: Sniffen, Spoofen, DoS
- Web-Anwendungen und Datenbanken: XSS, SQL-Injection
- Endgeräte: Buffer-Overflow, Viren, Würmer, Trojaner
- Benutzer: Phishing, Spamming, Social Engineering
Schadcode
- Virus: reproduzierend, braucht Host
- Wurm: reproduzierend, selbstständig
- Trojaner: sinnvolle Anwendung mit verstecktem Schadcode
- Rootkit: OS Backdoor / Keylogger
- Ransomware: Datenerpressung
- ROP-Gadget: Stackmanipulation und arbitrary code execution
Angriffe
- Buffer-Overflow: Schreiben über Speichergrenzen hinaus
- Überschreiben anderer Stackvariablen
- Überschreiben der Rücksprungadresse (→ ROP)
- ROP: Rücksprung zu beliebigen Stellen (ROP-Gadgets), für eigene Codeausführung (ROP-Chains)
- Heap-Overflow: use-after-free
- Integer-Overflow
- Formatstring attack: printf
- SQL-Injection:
"' OR 1=1 --"
, ignore rest of query
- Identitätsdiebstahl
- OSI Modell
- Schicht 2: ARP-Spoofing
- Schicht 3+: IP-Spoofing
- Schicht 4+: Session-Hijacking
- Schicht 7: Cache Poisoning, Web-Spoofing
- Man-in-the-Middle
- (D)DoS
- Social Engineering
- Web Angriffe: XSS, Schutz durch Same-Origin-Policy
Crypto
Kryptologie
- Kryptografie: Ver- und Entschlüsselung
- Symmetrische Chiffren
- Block-Chiffren (AES)
- Strom-Chiffre (ChaCha20)
- Asymmetrische Chiffren
- Basis: Faktorisierung (RSA)
- Basis: Logarithmus (EIGamal)
- Basis: Elliptic Curve (ECC)
- Kryptoanalyse: Metacrypto
- Schlüsselaustausch
- Integrität, Authentizität, Signatur
Kryptografisches System $(M,C,E,D,K)$
- $M$: Menge der Klartexte über Alphabet, $m \in M$
- $C$: Menge der Kryptotexte über Alphabet, $c \in C$
- $K$: Menge der Schlüssel, $e,d \in K$
- $E = \{E_e~|~E_e : M \rightarrow C \}$: Familie der Verschlüsselungsverfahren
- $D = \{D_d~|~D_d : C \rightarrow M \}$: Familie der Entschlüsselungsverfahren
- $\forall~ m \in M | E_e(m) = c ~ \exists~ d \in K: m = D_d(c)$
- $E_e(m)=c ~= E(m,c)=c$
- symmetrisch
- $e = d$ oder $d = f(e)$
- $e$ gemeinsamer, geheimer Schlüssel
- asymmetrisch
- Schlüsselpaar pro Kommunikationspartner (public, private)
- Verschlüsselung mit public, Entschlüsselung mit private
Anforderungen
- Kerckhoffs-Prinzip: Sicherheit allein durch Güte der Schlüssel → Keine "Security by Obscurity"
- Ausschluss von Brute-Force: großer Schlüsselraum
- symmetrisch: $\geq 128$ Bit
- asymmetrisch: $\geq 2048$ Bit (RSA), $\geq 250$ Bit (ECC)
Symmetrische Verfahren
Blockchiffre
- Aufteilen in Blocks $m_i$ fester Länge
- blockweises Verschlüsseln mit Funktion f und Schlüssel k
- Designprinzipien
- Diffusion: Verschleierung statistischer Eigenschaften
- Konfusion: Verschleierung des Zusammenhangs
- Feistel-Chiffre
- Rundenweise Blockverarbeitung
- Anwendung von f auf rechte Blockhälfte und Rundenschlüssel k
- Betriebsmodi
- ECB (Electronic Code Book)
- $c_i = E_k(m_i)\quad m_i = D_k(c_i)$
- Parallelisierte Verschlüsselung
- Wiederholte Verwendbarkeit des Verschlüsselungsschlüssels
- - Blöcke sind voneinander unabhängig
- - Gleiche Textblöcke ergeben gleiche Chiffre-Blöcke
- CBC (Cipher Block Chaining)
- $c_i = E_k(m_i \oplus c_{i-1})\quad m_i=D_k(c_i)\oplus c_{i-1}, ~c_0=\text{IV}$
- Startvektor IV, nicht geheim
- - Fehlerfortpflangung bei fehlerhafter Übertragung
- Bitfehler in $c_i$ → Fehlerhafte Entschlüsselung von $c_i$ und $c_{i+1}$
AES (Advanced Encryption Standard)
- 128, 192, 256 bit keys
- 10, 12, 14 Runden, je nach key Länge
- Keine Feistel-Chiffre, immer der ganze Block
- benötigt Hardware-acceleration
- $GF(2^8)$
- Ablauf
- 128 Bit block als 4x4 byte Matrix ("State")
- Operationen Zeilen- & Spaltenweise
- pro Runde
- SubBytes: byte-weise Substitution
- ShiftRows: zyklischer Linksshift
- MixColumns: Spaltenweise Polynomenmultiplikation, Verknüpfung aller Bytes einer Spalte untereinander
- AddRoundKe
- Entschlüsselung: Invertierung und Rückwärtsanwendung der Verschlüsselung
Stromchiffre
- Bitweise Verschlüsselung mit (pseudo)zufälliger Schlüsselfolge k ("Schlüsselstrom")
- k gleich lang wie m
- Verschlüsselung: $m \oplus k$
- Perfekte Sicherheit: Vernam-Chiffre (One-time Pad)
- - Nicht praxistauglich
- Anwendung: Geseedeter PRNG für k
- k nur für ein m verwendbar
- CTR - Counter Mode
- Stromchiffre mit Blockchiffre f
- Initialisierung von Zähler mit Nonce (Zufallszahl)
- Zählerstand pro Block $m_i: \mathrm{ctr}(i)=\mathrm{ctr}(i-1)+1$
- Verschlüsselung des i-ten Blocks: $c_i = m_i \oplus f_k(\mathrm{ctr}(i))$
- Entschlüsselung des i-ten Blocks: $m_i = c_i \oplus f_k(\mathrm{ctr}(i))$
ChaCha20 Stromchiffre: RFC 7539
- Effiziente Alternative zu AES ohne hardware-acceleration (3 mal schneller)
- 256 bit Stromchiffre mit 20 Runden
- Operationsfolge: Add-Rotate-XOR (ARX)
- Input: 256 bit key, 64 bit nonce, 64 bit counter
- Output: 512 bit block
- Nutzung in TLS
Asymmetrische Verfahren
Anforderungen
- Schlüsselpaare (e,d): $\forall m: D_d(E_e(m)) = m$
- Effiziente Schlüsselerzeugung
- Effiziente Ver- & Entschlüsselung
- d nicht aus e errechenbar
- optional: $\forall m: E_e(D_d(m)) = D_d(E_e(m)) = m$
- keys als Einweg-Funktion
- Faktorisierung $n = pq$ mit $p, q$ prim
- Diskreter Logarithmus
- $f(x)=g^x ~ \mathrm{mod} ~ p = y; ~p$ prim, $g \leq p$ einfach
- Umkehr $x=f^{-1}(y)=\log_g y ~ \mathrm{mod} ~ p$ schwer
- Einweg-Funktion mit Falltür
- Vereinfachte Berechnung der Umkehrfunktion mit Zusatzinfos
- $n = pq; f(x) = x^2 ~ \mathrm{mod} ~n$ Backdoor durch Kenntnis von $p,q$
- RSA
RSA
- $n$ RSA-Modul, $x$ Klartext, $k(p-1)(q-1)+1 = ed$, $e$ public key, $d$ private key
- $p,q \text{ prim}, n=pq, \forall x \leq n, k \in \mathbb{N} ~x^{k(p-1)(q-1)+1} ~ \mathrm{mod} ~n=x$
- Eulersche phi-Funktion: $\varphi(m) = |\{ a~|~ \mathrm{ggT}(a,m)=1 \wedge a < m \}|$
- Für $p$ prim: $\varphi(p)=p-1$
- Euler's Theorem: $ggT(M,n) = 1 \implies M^{\varphi(n)} = 1 ~ \mathrm{mod} ~n$
- Satz von Fermat: $p$ prim, $a \in \mathbb{Z} ~ a^p = a~ \mathrm{mod} ~p;~ a^{p-1}=1~ \mathrm{mod} ~p$
- Key-Berechnung
- Wahl von 2 großen Primzahlen
- Öffentlich bekannt gemachtes $n = p*q$
- Berechnung von $\varphi$
- Wahl von öffentlichem Exponent $e \in \{1,2,...,\varphi(n)-1\}:~ \mathrm{ggT}(\varphi(n),e)=1$
- Berechnung von privatem Exponent $d: ed = 1~ \mathrm{mod} ~ \varphi(n)$
- Operation auf Ganzzahl-Ring $\mathbb{Z}_n$, Klartext $x < n$
- Verschlüsselung: $E_e(x)=x^e~ \mathrm{mod} ~n = y,~x,y \in \mathbb{Z}_n$
- Entschlüsselung: $D_d(y)=y^d~ \mathrm{mod} ~n$
- starkes Modul: mindestens 2048 bit
- Implementierung
- Effizienter Primzahltest
- Berechnung multiplikativer Inverse
- Schnelles Potenzieren (square & multiply)
- Padding für Verschleierung (RSA-OAEP)
Elliptische-Kurven-Kryptographie (ECC)
- Gruppe von Punkten mit Koeffizienten von 160, 256,521 bit
- Abgeschlossen unter Punkt-Addition
- geringerer Speicheraufwand als große RSA keys
- Elliptische Kurve $E = \{(x,y)|x,y \in K: y^2=x^3+ax+b \wedge 4a^3+27b^2 \neq 0 \}$
- abel'sche Gruppe $(K^2 \cup \{\theta \}, \dot{+})$
- Geometrische Addition
- Schnittpunkt der Gerade durch P1 und P2 in P3'(=-P3)
- P3 durch Spiegelung von P3'
- ECDLP - Diskretes Logarithmus Problem
- Generator-Element G und Element T auf elliptischer Kurve E über Körper $Z_p$
- Finde $d \in N: 1\leq d \leq |E|: d = \log_G T; ~ T = d * G$
- d private key, T public key
- Verschlüsselung
- Klartext m: Punkt M auf E
- Wahl $k \in \{0,...,n-1\}$
- Berechnung $C1 = kG,~C2=M+kT$
- Entschlüsselung: $dC1 = d(kG) = k(dG) = kT;~C2-kT=M$
- Starke Sicherheit bei kleinem Parameterraum
- Angriffe mit ca. sqrt(p) Schritten
- Angriffsmöglichkeiten bei nicht standardisierten ECC
Kryptographische Hashfunktion
- Integritätsprüfung und Ursprungsnachweise als Ziel
- Abbildung zu Message-Digest, nicht vertraulich: $h: X^m \mapsto X^n; ~ m >>n$
- Kollisionsresilienz essentiell
- Anforderungen
- $\forall~ x \in X^m: ~ h(x)=y$ einfach
- Einwegeigenschaft (Preimage resistance)
- Schwache Kollisionsresistenz (second Preimage)
- $\forall~x \in X^m:$ Finden von $x'\in X^m: x \neq x'\wedge h(x)=h(x')$ nicht effizient
- Starke Kollisionsresistenz
- Finden von Paaren $x,x'\in X^m: h(x)=h(x')$ nicht effizient
- Schwerer zu garantieren als schwache ~: Zwei Freiheitsgrade $M, M'$
- Geburtstagsangriff
- Annahme: 50% Kollision bei $2^n/2$ Versuchen
- Tatsache: 50% Chance einer Kollision im Raum $2^n$ schon bei $\approx \sqrt{2^n}$ Versuchen
- => Länge des Hashwertes essentiell
Klassen von Hashfunktionen
- basierend auf Block-Chiffren
- AES-CBC
- Letzter Block als Hashwert
- $C_n = h(m)$, 128 bit Hashwert von $m$
- Dedizierte Hashfunktion
- MD5 (128 bit)
- SHA-1 (160 bit)
- SHA-2-Familie (256, 512 bit)
- SHA-3-Familie
- 224 - 512 bit
- Sponge-Funktion
- Kein weiterhashen möglich
- Passworthashfunktionen
- Langsame & ressourcenintensive Verifikation
- "bremsbar" parametrisierbare Hashf.
- bcrypt (1.3KH/s), Argon2, PBKDF2 <-> SHA256 (2900MH/s)
Message-Authentication-Code (MAC)
- Checksum, keyed-hash
- Authentizitätsprüfung
- Hashfunktion mit Schlüssel: $h: X^m \times EK \mapsto X^n$
- geheimer, symmetrischer, pre-shared key $k_{AB}$ zwischen Partnern
- Keyed Hash: $x' = x | k_{AB}$
- Schwachstellen
- weiter-hashen in SHA-1,2 (interner Zustand bekannt)
- Anhängen von Daten und Korrektur in MAC dank weiter-hashen möglich
- Alternativen: SHA-3, HMAC
HMAC
- Vereinigung von key und Nachricht
- Innen-& Außen-Padding: $ipad, opad$
- $\mathrm{HMAC}_k(x)=h((k \oplus \text{opad})~|~ h((k \oplus \text{ipad})|x));~| = $ Konkatenation
AEAD (Authenticated Encryption with Associated Data)
- Galois/Counter Modus (GCM) symmetrischer Chiffren
- Verschlüsselung 128 bit Blöcke in CTR mit K, IV
- Authentizitätsberechnung der assoziierten Daten (AD)
- Konstante $H = \mathrm{AES}_K(0,...,0)$ Hash-Subkey
- $g_0 = \text{AD} \times H; ~ \forall~i \in[1,n]: g_i = (g_{i-1} \oplus c_i) \times H$
- Authentizitätstag $T = (g_n \times H) \oplus \mathrm{AES}_K(\text{CTR}_0)$
- Ausgabe von AES-GCM: $c, T$
- Reihenfolge, Encrypt-then-MAC
Digitale Signatur
- Urheberschaftsnachweis
- Signaturverfahren
- dediziert (DSA, ECDSA)
- public key (RSA)
- Public key: Signaturschlüssel $K_\text{sig}$
- Private key: Verifikationsschlüssel $K_\text{veri}$
- Ablauf
- Hashen: $\mathrm{SHA3}(m) = h$
- Signieren: $\mathrm{RSA}_d(h)=h^d ~ \mathrm{mod} ~ n = \text{sig}$
- Prüfen: $\mathrm{RSA}_e(\text{sig})=\text{sig}^e~ \mathrm{mod} ~n=?~ h$
Digital Signature Algorithm (DSA)
- basiert auf ElGamal
- Nutzung von 2 zyklischen Gruppen
- Große Gruppe mit Primzahl p, $\geq 2048$ bit
- Kleine Untergruppe mit Primzahl q,$\approx 224$ bit
- Signaturlänge: $2*|q|$
- Diskreter Logarithmus: $d = \log_\alpha \beta ~ \mathrm{mod} ~ p$
Elliptic Curve Digital Signature Algorithm (ECDSA)
- 160-256 bit ECC ~= 1024-3072 bit RSA
- Ablauf
- Wähle p prim, GF(p) bestimmt Kurve E
- Bestimme Generator A ($= \alpha$ DSA), generiert zyklische Gruppe der Ordnung q
- Schlüsselgenerierung
- Wähle geheimes d: $0<d<q$
- Berechne öffentlichen Validierungsschlüssel $B = dA$ ($= \beta$ DSA)
- Signieren
- Wähle $k_E,~ o<k_e<q$
- Berechne $R=k_E A$
- Bestimme $r=X_R$ (X-Koordinate)
- Berechne $s = (h(x)+d \cdot r) k_E^{-1} ~ \mathrm{mod} ~q$
- Sicherheit: Komplexität $\geq \sqrt{q}$
Fortgeschrittene Kryptographie-Konzepte
Homomorphe Verschlüsselung
- Berechnungen auf Chiffre korrelieren mit Berechnung auf Klartext
- Homomorphe Abbildung $(H,\circ),~(G,\diamond),~f: G \mapsto G: ~ \forall g,g' \in G:~f(g \diamond g')=f(g) \circ f(g')$
- $\circ$ additiv / multiplikativ homomorph
- Schema $(M,C,K,E,D, +_M, _M, +_C, _C)$
- M Klartextmenge, C Chiffrenmenge, K Schlüsselmenge
- D,C Ver- & Entschl.alg.
- M, C bilden Ring $(M, +_M, _M),~(C, +_C, _C)$
- partiell homomorphe Verschlüsselung (PHE): $\forall~a,b \in M,k \in K$
- entweder $D_k(E_k(a)+_C E_K(b)) = D_k(E_k(a+_Mb))$
- oder $D_k(E_k(a) _C E_k(b)) = D_k(E_k(a _M b))$
- voll homomorphe Verschlüsselung (FHE)
- partiell mit beiden Teilen
- Noise-Problem: Vielzahl an Operationen verschlechtern Klartext-"Signal"
- Ineffizient
- Aktuelle Forschung: Somewhat homomorphic encryption
- Keine Entschlüsselung
- begrenzte Op-Anzahl
- Theoretisch auch für RSA gültig: ohne Padding homomorph unter Multiplikation
Post-Quantum-Kryptographie (PQC)
- Shor-Algorithmus: Factor./Disk.Log. in polynomial time
- => asymmetrische Verfahren alle gebrochen
- Grover-Algorithmus: Brute force bei symmetrisch doppelt so schnell
- => lange Schlüssel ausreichend
- Neue Algorithmen
- Code
- Gitter
- Hash
- Multivariate
- Supersingular
Fazit
- Vertraulichkeit: Verschlüsselung (RSA,AES,AEAD,ECC)
- Integrität: Hashfunktionen (SHA, AEC-CBC)
- Authentizität: MAC (SHA3, HMAC-SHA)
- Verbindlichkeit: Digitale Signatur (RSA,DSA)
Key management
Aufgabenbereiche
- Erzeugung
- Hierarchie (Perfect Forward Secrecy)
- Vereinbarung
- Zertifizierung
- Erneuerung
- Speicherung
Schlüsselerzeugung
- Hohe Entropie: RNG
- TRNG: Basiert auf physikalischer Entropiequelle
- PNG: (PRNG)
- Linear Congruental Generators (LCG)
- $X_{i+1} = (aX_i + b) ~ \mathrm{mod} ~ m; a,b,m$ konstant
- z.B ANSI-C
rand()
- Hybrid: PRNG Seed mit TRNG generieren
- CSPRNG: Kryptografisch sichere RNG
- Anforderungen
- Nicht vorhersagbar aufgrund vorheriger Folge
- kein Hinweis auf vorherige Folge
- statistisch gleich viele 0 und 1: nicht komprimierbar
- Beispiel
- Blockchiffre im CTR oder OFM Modus
- Nichtlinear rückgekoppelte Shift-Register
Schlüsselhierarchie
- Kontext: Verwendung verschiedener Schlüssel für verschiedene Aufgaben
- Anwendungen: TLS, WLAN
- Ebenen
- Ebene 0: Root-Key (selten verwendet) (WLAN: PMK)
- Ebene 1: Session-Key, persistent (WLAN: PTK)
- Ebene 2: Datei-/Object-Key, Kommunikationsschlüssel (WLAN: KCK, KEK, TK)
Schlüsselerneuerung
- Klassisches Verfahren
- gegeben Master-Key $K$
- Erneuerung / Verteilung von neuem Key $k'$ unter $A$ und $B$ unter Nutzung von $K$
- $c = E_K(k')$, Übertragung von $c$
- Problem: Nachverfolgbarkeit bei bekanntem $K$
- Perfect Forward Secrecy: "Folgelosigkeit"
- Unabhängigkeit neuer Schlüssel von vorherigen
Schlüsselvereinbarung
- Schlüsselaustausch
- Aufwändiger Austausch zwischen n Partnern
- Schlüsselverteilungscenter KDC (TTP)
- Besitz von Secret-Key $K_A$ mit jedem Partner $A$ oder pub.key von $A$
- Pre-shared master keys
- langlebig
- Master-Keys als Basis für Austausch von kurzlebigen Keys
- - keine ad-hoc p2p Kommunikation zwischen Partnern
- - keine Perfect Forward Secrecy
- - Single point of failure
- - Communication bottleneck
- + Authentifizierung von Partnern durch KDC
- Hybrid-Verfahren ohne TTP
- Sendung verschlüsselter Keys mithilfe von RSA/ECC
- RSA-KEM: Key encapsulation method
- Random z
- Partner A: $c = z^{eB} ~ \mathrm{mod} ~ n$
- $KEK = KDF(z, length)$ (KDF: Key Derivation Function)
- $WK = E_{KEK}(K_{AB})$ mit AES-128
- Nachricht: $EK = c | WK$ zu B
- $z = c^{dB} ~ \mathrm{mod} ~ n$
- $KEK = KDF(z, length)$
- $K_{AB} = E_{KEK}(WK)$
- + Verschlüsselung mit Random z
- + KEK nicht gebunden an n
- + KEK ist neu für jeden Key-Exchange
Schlüsselabsprache
- Diffie-Hellmann-Verfahren
- Ablauf
- Wähle großes $p$ prim (public)
- Wähle Generator-Element $g \in \mathbb{Z}_p^*$ (public)
- Jeder Partner (A bzw B): Wähle geheimes zufälliges $a \in [1,p-2]$, berechne öffentliches $A=g^a ~ \mathrm{mod} ~ n$
- Tausche $A$ mit Partner aus, erhalte $B$ ($A$ des Anderen)
- Berechne $k = B^a ~ \mathrm{mod} ~ p = g^{ba}$
- - Authentizität der Public-Keys ist nicht gewährleistet
- Attacke: Man in the middle
- Diffie-Hellmann auf elliptischer Kurve (ECDH)
- Analog zu DH
- Genau-so MitM möglich
- - Preisgeben des Private keys des Partners durch gezielte ungültige Ellipsenpunkte
Zertifikate
- Identitätsbindung an Public Key
- Standard-Format: X.509.v3
- Aussteller (Issuer)
- Zertifikatsinhaber (Subject)
- Erweiterungen
- Signatur
- Beschränkungen
- Problem: CA kann für jede Domain Zertifikat ausstellen
- Gegenmaßnahmen 2017:
- Certificate Transparency: revisionssicherer Log
- Certificate Logs
- Monitors
- Auditors
- Certification Authority Authorization (CAA): CA Pinning
- CAA-Record in DNS für berechtigte CAs
Public Key Infrastructure (PKI)
- Infrastruktur für Zertifikatausstellung und -prüfung
- Certification Authority
- Aussteller
- Online Certificate Status Protocol
- Registration Authority
- Bürgt für Verbindung von Key und Identität
- Verzeichnisdienst
- Zeitstempeldienst
- Personalisierung
Hierarchie von CAs
- Ausstellen von Zertifikaten für untergeordnete CAs
- Allgemeines Vertrauen in gewisse Root-CAs
- Zertifizierungspfad
- Cross-Zertifizierung: 2 CAs gegenseitig
Zertifikatvalidierung
- Signaturprüfung
- Pfadprüfung
- Signatur
- Aktuelle Verfahren
- Nicht zurückgerufen
- Gültigkeitsdatum
Zertifikatsrückruf
- Problem: offengelegter private key
- Naiver Ansatz: Certificate Revocation List
- Verbesserung: Online Certificate Status Protocol
- Weitere Verbesserung: OCSP Stapling (serverseitiges caching)
CA/Browser Forum
- Zusammenschluss von CAs und Browserherstellern
- Einheitliche Standards für Zertifikatsvergabe
- Anforderungsdefinitionen
- Technische & organisatorische Standardisierung
- Freiwillige Selbstkontrolle
- Validation levels
- Domain Validation
- Organization Validation
- Extended Validation
- Maximale Zertifikatsgültigkeit von 825 Tagen
- Verwendung von neueren Algorithmen als SHA1
- Ausstellungsverbot von Special-Use Domain Names (localhost, etc.)
Automatic Certificate Management Environment (ACME)
- Nachweis über Domainbesitz
- Schlüsselpaar (Authorization Key Pair) erzeugen, signierte Anfrage an CA
- 1 oder mehre Challenges von CA: HTTP Resource bereitstellen und Nonce signieren
- Zertifikatausstellung
- Certificate Sign Request (CSR) an CA zur Zertifizierung eines neuen Public Keys, signiert mit zugehörigem Private key
- CSR signiert mit Authorization Key
- Validierung und Zertifikatausstellung
Vertrauensdienstgesetz
- Europäische eIDAs-Verordnung 2016
- Elektronische Identifizierung
- Vertrauensdienste für elektronische Transaktionen im Binnenmarkt
- Elektronische Signatur
- Einfache Signatur
- Fortgeschrittene elek. Signatur
- PKI-basiert
- Zuordnung des Unterzeichners
- Identifizierung des Unterzeichners
- Erkennung von nachträglicher Modifikation der Daten
- Qualifizierte Signatur
- Fortgeschrittene elek. Signatur
- Ausgestellt von qualifizierter elek. Signaturerstellungseinheit
- Basiert auf qualifiziertem Zertifikat (von CA) nach ISO 15408
- Deutsches Vertrauensdienstgesetz 2017
- Ablösung des Signaturgesetzes
- Umsetzung der eIDAs-Verordnung
- Definition Vertrauensdienst: Dienst der Erstellung, Überprüfung und Validierung von elektronischen Signaturen, Siegeln und Zertifikaten
- Signaturen für natürliche Personen
- Siegel für juristische Personen
- elektronischer Zeitstempel
- Zustellung elektronischer Einschreiben
- Website-Authentifizierung
- Verschiedene Vertrauenslevel für Dienstanbieter
- Mitwirkungsverpflichtung für Dienstanbieter
- eIDAs Konformitätsnachweis
- Visuelles Vertrauenssiegel
Digitale Identität - Authentifikation
Authentisierungsfaktoren
- Wissen
- Besitz
- Biometrie
- Multi-Faktor
Authentifikation durch Wissen
- Challenge-Response-Verfahren (CR)
- Authentifikation eines Subjekts gegenüber einer Instanz
- Symmetrische Verschlüsselung
- Asymmetrische Verschlüsselung
- One-Time-Passwords (OTP)
- Software Token
- Lamport-Hash
- S/Key-Verfahren
- HMAC-based (HOTP)
- Zeitsynchronisiert (TOTP)
- CR-basiert
- Hardware Token
- Zeitsynchronisiert
- RSA SecureID-Token: token= AES(TokenID | Seed | Zeit)
- CR-basiert
- Zero-Knowledge-Verfahren (ZKP)
- Kenntnisnachweis eines Geheimnisses s gegenüber einem Dritten
- Ohne Kenntnis des Dritten vorab oder im Verlauf der Authentifizierung
- Nachrichten können offen einsehbar sein
- Einsatz: Kryptowährungen
- Fiat-Shamir-Verfahren
- Quadratwurzelziehung in $\mathbb{Z}_n$
- gegeben $n = p*q,~ v = s^2 ~ \mathrm{mod} ~ n$, gesucht $s$
- Verifizierung per $v$, ob $s$ korrekt angegeben
- Ablauf: A login bei B, Wiederholung $k$-mal
- A: Wähle $r\in\mathbb{Z}_n^2,~ x = r^2 ~ \mathrm{mod} ~ n$, sende $x$
- B: Sende Challenge $b = 0~\mathrm{oder}~ 1$
- A: Sende $y = r*s^b ~ \mathrm{mod} ~ n$
- B: Prüfung: $x*v^b ~ \mathrm{mod} ~ n = y^2 ~ \mathrm{mod} ~ n$
- Angriffe
- Vorausberechnung von $x = r^2/v$ Werten
- Response nur bei $b=1$ möglich, mit $y=r$
- Reused $r$
- Betrugswahrscheinlichkeit für große $k$: $1/2^k$
Authentifikation durch Besitz
- Verwendung in Multi-Faktor Validierung
- Schutz gegen MiTM
FIDO-U2F (Fast Identity Online)
- Universal Authentication Framework (UAF) Protocol
- Passwortlose Authentisierung (Gerät-PIN, Fingerprint)
- Besitz von Gerät mit installiertem UAF Stack
- Universal Second Factor (U2F) Protocol
- USB- / NFC-Dongle
- ECDH Schlüsselaustausch, ECC, SHA256, AES-CBC
- Signatur: ECDSA-SHA256
- Ablauf
- Registrierung
- Schlüsselerzeugung
- Dongle-Attestierung (GRM Hersteller-Zertifikat)
- Login
- Challenge und $K_C$ für sichere Kommunikation
- Browser: Evidence-Informationen zur Authentizität des Servers
- Nutzer: Präsenznachweis, Tastendruck
- Dongle: Origin-Prüfung, Responseerzeugung, Signierung
Elektronischer Personalausweis mit nPA
- hoheitliche Personenkontrolle (Polizei)
- eID: elektronisch prüfbare Identität
- Smartcard-Format ID-1 RFID-Chip
- Gespeicherte Daten
- Name, Geburtsdatum, Alter, Geschlecht, Nationalität
- Nur im Chip: Gesichtsbild, Fingerabdrücke
- 16 Datengruppen
- DG 1: Kopie der Machine Readable Zone (MRZ)
- DG 2: Digitales Gesichtsbild
- DG 3: Fingerabdruck (optional)
- Fälschungssicherheit
- Privater Chip-key (shielded)
- Signiert abgelegter Public Key
- Online-Authentisierung
- Benutzerdefinierte Datenübertragung an Anbieter
- Berechtigungszertifikat von Anbieter erforderlich
- Schutzziele
- Integrität und Authentizität
- SHA-1, digitale Signatur
- PACE-Algorithmus (BSI)
- Anti-Cloning
- Aktive Authentisierung durch den RFID-Chip
- DH, 224 bit ECDSA
- Vertraulichkeit
- AES-128
- TLS
- Kryptographischer Co-Prozessor auf Chip
- Terminal-Authentisierung
- Authentisierung des Anbieters
- Validierung des Berechtigungszertifikats
- Ablauf
- Übertragung des Berechtigungszertifikats
- Nutzerbestätigung: PIN
- nPA: PACE: PIN Prüfung
- nPA: Zertifikatsvalidierung
- nPA: RAND Challenge an Anbieter
- Anbieter: Result = $RSA_{d_S}(RAND)$
- nPA: DH-Key-Element, signiert von Bundesdruckerei
- Anbieter: DH-Key-Element
- nPA: $AES_{KCS}(\text{nPA-Daten})$, DH-Key K, Message-Key $K_{CS} = KDF(K, length)$
Password Authenticated Connection Establishment (PACE)
- ohne PKI, offline
- Passwort-geschütztes DH-Protokoll zwischen Chip und Lesegerät zur Schlüsselabsprache
- Varianten
- Passwort als Benutzer-PIN für eID-Funktion
- 6-stellig, im Chip des nPA gespeichert
- Eingabe an Lesegerät
- Passwort als Karten-PIN für hoheitliche Kontrollen
- 6-stellig, in MRZ auf der Karte, optisch auslesbar
- Nutzer-Authentisierung: Gesichtsbildvergleich
Authentifikation durch Biometrie
- personengebunden
- Vergleich mit Referenzwerten notwendig
- Anforderungen an biometrische Merkmale
- Universalität
- Eindeutigkeit
- Beständigkeit
- quantitative Erfassbarkeit
- Performance
- Akzeptanz
- Fälschungssicherheit
- Klassen
- physiologische Merkmale (statisch)
- Verhaltensmerkmale (dynamisch)
- Leistungsmaße
- False-Acceptance Rate (FAR)
- False-Rejection Rate (FRR)
- Equal Error Rate (ERR): Schnittpunkt von FAR und FRR
- Trade-Off
- Hinzunahme von Merkmalen vs. Error Rate
- viele Merkmale: high FRR, low FAR, wenig Komfort
- wenige Merkmale: low FRR, high FAR, hoher Komfort
Fingerabdruck
- Merkmale (Minutien)
- Crossover
- Core
- Bifurcation
- Ridge ending
- Island
- Delta
- Pore
- Darstellung als Tripel aus Ortskoordinaten und Linienwinkel $(x,y,\theta)$
- Minutienvergleich: Abstand und Winkeldifferenz
- Toleranzschwelle für Abstand und Winkeldifferenz
- Match-Score k, Mindestanzahl an übereinstimmenden Minutien
Verteile Authentisierung
- Trennung von Authentisierung und Verifikation
- Authentisierung: Zentrales KDC, Policy-Decision-Point (PDP)
- Prüfung auf Aktualität, Plausibilität, Zulässigkeit durch Server: Policy-Enforcement-Point (PEP)
- Schema
- Nutzungsanfrage von A an KDC
- Prüfung der Authentizität von A und Tokenausstellung
- Tokenübermittlung an A
- Tokenübertragung von A an Dienst-Server (PEP)
Kerberos-Protokoll
- Tickets als Zugang, ausgestellt von Kerberos-Ticket server (TGS)
- Authentisierte Nutzung von Services inn Unternehmensnetz
- KDC pro administrativer Domäne
- Vorab vereinbarte Master-Keys
- Für Nutzer: $K_A=KDF(hash(password), length)$
- $K_A$ mit KDC-Key $K_{KDC}$ verschlüsselt
- Authenticator: Berechtigungsnachweis zur Ticketnutzung
- Single-Sign-On (SSO)
- Ablauf
- User-Login
- Schlüsselanforderung bei KDC
- Erhalt von Ticket-Granting Ticket
- Für Verwendung eines Dienstes (Principal): TGS Server-Anfrage
- Erhalt von Principal-Ticket nach Eingabenprüfung durch TGS
OAuth 2.0
- Verbindung von Diensten ohne Austausch der Zugangsdaten
- Rollen
- Resource-Owner (RO): User
- Resource-Server (RS)
- Client (C): User-Programm
- Autorisierungsserver (AS)
- Ablauf
- Anforderung der Nutzungsberechtigung bei RO
- Erhalt von Authorization Grant
- Anforderung von Access Token bei AS mit Grant
- Anfrage auf Ressource bei RC mit Access Token
- Genehmigungsprozesse / -typen
- Authorization Code: Verwendung von AS
- Implicit: Vorab gespeichertes Access Token in C
- Resource Owner Password Credentials: C erhält Zugangsdaten von RO für Erhalt eines Access Tokens
- Client Credentials: Falls Ressource von C kontrolliert wird
- Access Token (AT)
- Scope, Dauer
- optional signiert
- einheitlicher Zugriffsberechtigungsmechanismus
- AT-Erneuerung: Refresh-Token, über AS
- Sicherheitsbetrachtung
- Tokens per TLS
- Komplexe Tokens
- Authentizitätsprüfung des Clients
- Vertrauliche Übertragung von Refresh-Token
- Beschränkte Gültigkeitsdauern
OpenIDConnect
- Erweiterung von OAuth 2.0 Protokoll
- Identity layer: Validierung der Nutzeridentität
- Datenübertragung mit JSON Web Tokens
- Relying Parties (RP): OAuth clients mit OpenID connect
Netzwerksicherheit
Firewall
- Netzwerkunterteilung in Segmente
- Firewall-Kontrollen an Segmentgrenzen
- Paketfilter-Firewall
- Analyse der Paketheader
- Stateful: Filterentscheidung basierend auf vorangegangenem Traffic und aktuellem Paket
- Stateless: Filterentscheidung allein basierend auf aktuellem Paket
- Deep Packet Inspection
- Analyse der Paketheader und Daten
- Prüfung auf Protokollverletzung und Malware
- Datenschutzimplikationen
- Missbrauchspotenzial: Zensur
- Application Layer Gateway (ALG)
- Statt lediglichem Filter: Verbindungsterminierung auf OSI-Schicht 7
- Zugriff auf kompletten Verbindungszustand
- Datenmodifikationsrechte
- Beispiel HTTPS: Unterbrechen der Verschlüsselungskette durch Installation selbstsignierter Stammzertifikate
Protokolle
- Sicherer Kanal: SSL/TLS
- Sicherung der Schutzziele gegenüber den höheren Protokollschichten
- Ende des Schutzes am Kanalende
- Handshake-Protokoll-Schritte
- Protokollabwicklung
- Vereinbarung von Security-Policy
- Dedizierte Aufgaben: Kerberos, OAuth
- Absicherung von Anwendungsobjekten: Signal
- Ziel: One-Step-Processing
- Verschlüsselung, Signatur pro Objekt
- Entkopplung von Datenempfang und kryptografischer Prüfung
SSL/TLS
- Sicherer Kanal über OSI-Schicht 4
- Verwendung in HTTP
- Schlüsselaustausch: ECDHE
- Perfect Forward Secrecy (PFS) statt statischem DH
- Abwehr von MitM durch signierte Schlüssel
- Verwendung temporärer DH-Keys
- Schutzziele
- Authentifikation: X509.v3
- Integrität: HMAC-SHA2
- Vertraulichkeit: TLS-AES-128-GCM-SHA256
- TLS-Handshake-Protokoll
- TLS 1.2
- Hello
- Austausch von $R_C$ und $R_S$
- Certificates
- Key Exchange
- $RSA_{\text{e_server}}(PRE)$ mit $PRE$ random
- Ableitung des Master-Keys aus $PRE, R_C, R_S$
- $Finished = MAC(k^{MAC}, \text{Handshake_msg})$
- Application Data
- Ableitung des Kommunikationsschlüssels $K_C$ aus Master-Key
- TLS 1.3
- Verwendung von AEAD
- Verbot veralteter Verfahren (SHA-1)
- TLS 1.3 1RTT
- ECDH für dezentrale Schlüsselberechnung
- Dynamische DH-Keys
- Signieren öffentlicher Schlüssel
- Senden von verschlüsselten Daten
- Schlüssel abgeleitet über HKDF aus DH-Key, $R_C, R_S$
- Optional mit Client-Authentisierung
- Client: Hello $R_C, g^C$:
- Server: Berechnung von DH-Key K
- Server: Hello $R_S, g^S$
- Server: Certificate, Signierter K, Application data
- Ableitung von $k^{MAX}, k^{enc}$
- Client: MAC
- Beide: $AEAD_{k_{enc}}(data)$ = Application data
- TLS 1.3 0RTT
- Caching von vorherigem Handshake-Key: PSK (Pre-Shared Key)
- Vorabsendung von Server Konfiguration
- Datentransfer direkt per Hello-Nachricht
IPsec
- Sichere Kommunikation auf IP-Ebene
- Authentizität des Datenursprungs
- Vertrauliche Datenübertragung
- Schutz vor Replay-Attacken
- Schlüsselmanagement
- Operationsmodi
- Transport-Modus
- Absichern des Payloads
- IP-Header - IPSec-Header - Payload
- Tunnel-Modus
- Kapselung des IP-Headers und des Payloads in jeweils IPsec-Paket
- IP-Header (gateway) - IPSec-Header - IP Header (real destination) - Payload
- Versandablauf von A nach B
- Lookup von Verbindung in SA von A
- Anwendung von definierter Verschlüsselung, Hash-Fkt, etc.
- Verwendung des gespeicherten SPI in IPSec-Header
- Konzepte
- Authentication-Header Protokoll (AH)
- Schutz vor Replay-Attacken durch Sequenznummern
- Payload- & Datenursprungsverifikation
- Encapsulating Security-Payload Protokoll (ESP)
- Vertraulichkeit
- symmetrische Blockchiffre
- HMAC Authentisierung des Payloads
- Security-Association Datenstruktur (SA)
- Unidirektionale Informationen über IPSec-Verbindung
- Pro Protokoll (AH / ESP)
- Vorab über IKE ausgehandelt
- Erzeugung bei erstmaligem Verbindungsaufbau
- SPI: Verweis auf SA-Eintrag des Empfängers in IPSec-Header
- Gespeicherte Daten
- IP des Empfängers
- Protokoll-Daten für AH & ESP
- Algorithmen
- Schlüssel
- Lebenszeiten
- Initialwerte
- SA Lebenszeit
- Sequenzzähler
- Modus
- Anti-Replay-Window
- Security-Level
- Security-Policy-Database (SPD)
- Lokal pro Teilnehmergerät
- Selektor-gesteuert
- Regeln für den Umgang mit inbound & outbound IP-Pakets
- bypass: Weiterreichen
- apply: Anwendung von IPSec mit Verweis auf SA
- discard: Paket-Vernichtung
- wenn outbound: bei Regelanwendung Etablierung von SAs
- wenn inbound: Verwerfen bei Fehlen von SA
- Internet-Key-Exchange Protokoll (IKE)
- Phase
- Sichere Aushandlung für zugrundeliegende IKE-Algorithmen
- DH-Berechnung
- Phase
- Authentifizierung der beteiligten Subjekte
- Validierung über signierte Nachrichten mit MAC
- Wechselseitige Etablierung der SA
- Nachteile
- Komplexe Konfiguration
- Hohe Anzahl an Freiheitsgraden: fehleranfällig
- Interoperabilitätsprobleme durch konfigurierbare Varianten
- Unzuverlässige Übertragung über UDP
- Konflikte mit Firewalls
VPNs
- Datenabsicherung durch kryptografische Verfahren
- Aufbau sicherer Kanäle
- Unsichtbar gegenüber höheren Schichten
- Einsatzmöglichkeiten
- End-to-Site VPN / Remote-Access VPN
- Site-to-Site VPN / Branch-Office VPN
Sichere Drahtloskommunikation
WLAN IEEE-Standard 802.11i (WPA 2)
- Sicherer Kommunikationskanal auf Schicht 2
- WPA 2 Handshake Protokoll
- PMK-Etablierung
- Pre-Shared (Passwort-basiert)
- 802.1X-Protokoll Kommunikation mit Radius-Server
- 4-Way-Handshake: Vereinbarung des PTK mithilfe PMK
- AP: Generieren und und Senden von ANonce
- Client
- Generieren von SNonce
- Berechnen $PTK = PRF(PMK, ANonce, SNonce, addr_{AP}, addr_{client});~ PTK=KCK~|~KEK~|~TK$
- Berechnen $MIC = AES-CBC_{KCK}(Handshake-msg)$
- Senden von SNonce, $MIC$
- AP
- Berechnen von $PTK$
- Prüfung von $MIC$ und Berechnung von $MIC'$
- Senden von "Activate", $ENC_{KEK}(GTK), MIC'$
- Client
- Prüfung von $MIC'$
- Senden von ACK, $MIC'$
- Schlüssel
- 256 bit Pairwise Master-Key (PMK)
- 384 bit Pairwise Transient Key (PTK)
- 128 bit Kommunikationsschlüssel TK
- 128 bit Integritätsschlüssel KCK
- 128 bit Key-Encrypting Key KEK
- 128 bit Gruppenschlüssel GTK: Von AP generiert
- Verschlüsselung
- AES-CCMP (Counter-Mode-CBC-MAC Protocol)
- 128 bit TK und AES-CTR
- 128 bit CBC-MAC-Hash des Klartextes mit 48 bit IV
- WPA 3
- Interoperable mit WPA 2
- Spezifische Features für Personal / Enterprise Netzwerke
- Personal: Stärkerer Schutz vor Passwort-Angriffen
- Enterprise: Unterstützung für höhere Schlüsselgrößen
- WPA 3 Personal
- Simultaneous Authentication of Equals (SAE)
- Ersatz für WPA 2 PSK
- Berechnung von PMK
- Variante des Dragonfly Handshake
- Password-Authenticated Key Agreement (PAKE)
- Schutz gegen Offline-Dictionary Attacks
- Wahlweise Elliptic Curve oder Finite Element Kryptographie
- Vorab ausgetauschte Kurvenparameter
- Phasen
- Commit-Phase: Ableitung des gemeinsamen Schlüssels
- Abbildung von Passwort auf Punkt P auf Elliptic Curve: Hash-to-Curve Algorithmus
- Schlüsselaustausch ähnlich ECDH
- maskierter Austausch von $P, r_A, r_B$
- $K = r_A (S_B P + E_B) = r_A r_B P$
- $K = r_B (S_A P + E_A) = r_B r_A P$
- Confirm-Phase: Cross-verification der Schlüssel
- Beide Partner: Hashen von K zum Erhalt von PMK
- Austausch von HMAC der Handshake Variablen
- HMAC Validation
- Normaler 4-Way Handshake mit PMK
- Optional: Enhanced Open
- Opportunistic Encryption
- Durchführung von ECDH vor 4-Way Handshake für PMK-Aushandlung
- Individueller Kommunikationsschlüssel je Teilnehmer
- WPA 3 Enterprise
- Erweiterung von WPA 2
- Authenticated Encryption: 256 bit Galois / CTR Protokoll
- Key derivation and confirmation: 3HMAC-SHA384
- Key establishment and authentication: 384 bit ECDH und ECDSA
Mobilfunk
- GSM (2G)
- 9600 bit/s
- Komponenten
- Mobile Stationen (MS): Mobilfunktelefon, Datenkarte
- SIM-Karte (Subscriber Identity Module)
- Zugangsberechtigung zum Mobilfunknetz
- Sicherheitskritische Daten gespeichert
- 15 Stellen IMSI (International Mobile Subscriber Number)
- LAI (LocationArea Identification), PUK, TMSI
- 128 bit Schlüssel $K_i$ (Individueller Subscriber Identification Key)
- Algorithmus A3 für CR-Authentifikation
- Algorithmus A8 zur Generierung von $K_C$
- Base-Transceiver-Station (BTS)
- Signalverarbeitung und Kommunikation
- 10 -100 BTS angeschlossen an einem BSC
- gemietete Leitungen (PCM30 / 2MBit/s)
- Richtfunkstrecken (7GHz)
- Base-Station-Controller (BSC)
- BTS-Verwaltung
- Handover-Steuerung
- Bündelung des Mobilfunkverkehrs
- Mobile-Switching-Center (MSC)
- Vermittlungsstelle
- Home-Location-Register (HLR): Speicherung der Kundendaten und Rufumleitung
- Visitor-Location-Register (VLR)
- Verwaltung von Nutzern in räumlichem Abschnitt
- 5 - 10 VLR / Provider
- Location-Area, Handystandort, Rufzustellung
- Mapping IMSI <-> TMSI
- TMSI: Temporary mobile subscriber identity
- lokale Gültigkeit (Verfall bei Handover)
- Verschlüsselter Transfer zu SIM
- Authentication-Center (AuC)
- Speziell geschützte Gebäude
- Verwaltung sicherheitsrelevanter Daten
- Gateway-MSC (GMSC): Übergang in andere Netze
- Sicherheitsarchitektur
- Authentisierung der Teilnehmer beim Netzzugang an BTS
- Verschlüsseln der Luftschnittstelle
- Nahtloser Zellenwechsel (handover)
- Pre-Shared Key $K_i$ auf SIM, auch gespeichert bei Provider in AuC
- Symmetrisches Challenge-Response bei Login
- Algorithmus A5 zur Verschlüsselung: Hardware Stromchiffre
- Offene Implementationen, keine Security by Obscurity
- Protokollablauf
- SIM: Einbuchen an BTS mit IMSI
- BTS: Triplet-Anfrage an Provider mit IMSI
- Provider: Antwort mit $RAND,~SRES = A3_{K_i}(RAND),~K_C=A8_{K_I}(RAND)$
- BTS: Antwort mit $RAND$
- SIM: $K_C=A8_{K_I}(RAND)$, Senden von $SRES' = A3_{K_i}(RAND)$
- BTS: Prüfung $SRES' = SRES$
Anwendungssicherheit
Sichere Mail
Pretty Good Privacy (PGP)
- Verschlüsselung symmetrischer Schlüssel: RSA, ElGamel
- (Mail-)Verschlüsselung: symmetrische Blockchiffre: AES, 3DES, DES, CAST, Twofish
- Datenintegrität und Authentizität: SHA, RSA, DSA
- Nachrichtenformat
- Verschlüsselungskomponente
- Schlüssel-ID der verwendeten Empfänger-Schlüssel $e_B$
- Verschlüsselter Mailschlüssel $K_{AB}$ (von Empfänger)
- Signaturkomponente
- Zeitstempel des Erstellungszeitpunkts
- Schlüssel-ID des Signierers $e_A$
- Signierter Hashwert der Mail
- Nachrichtenkomponente
- Schlüsselverwaltung
- Einmalschlüssel: Symmetrischer Mailschlüssel
- Mehrere öffentliche Schlüssel pro Teilnehmer
- Verschlüsselungsschlüssel
- Verwaltung mehrerer asymmetrischer Schlüsselpaare
- Zu großer Overhead bei zufälliger Erzeugung der Schlüssel-ID
- Ableitung der Schlüssel-ID aus Schlüssel
- 64 bit ID = $e ~ \mathrm{mod} ~ 2^{64}$
- Nutzung von Key-Rings
- Key-Rings
- Private-Key-Ring
- Verwaltung eigener Schlüsselpaare
- Erzeugung über PGP-Bibliotheksfunktionen
- Erfasste Daten
- Zeitpunkt der Schlüsselerzeugung
- Schlüssel-ID
- Öffentlicher Schlüssel
- Verschlüsselter Privater Schlüssel
- Benutzer-ID (E-Mail Adresse)
- Public-Key-Ring
- Public-Key pro Kommunikationspartner
- Erfasste Daten
- Zeitpunkt der Schlüsselerzeugung
- Schlüssel-ID
- Öffentlicher Schlüssel
- Benutzer-ID (E-Mail Adresse)
- Key-Legitimation-Field (KLF): Web of Trust
- Vertrauensgrad
- Symmetrische Verschlüsselungsschlüssel $K_{AB}$
- Erzeugt über PRNG
- Seed: Verzögerung von Tasteneingaben
- Schutz des Private Keys $d$
- Benutzerdefinierte Passphrase: Mantra
- 160 bit Hash $H$ des Mantras
- $K = KDF(H)$
- Verschlüsselung von Private Key $d' = E_K(d)$
- Mailversand
- Nachricht hashen
- Private Key mit Passphrase entschlüsseln
- Nachricht mit Private Key signieren
- $ID_A$ an Nachricht anhängen
- $K_{AB}$ generieren
- Nachricht verschlüsseln
- $K_{AB}$ mit $e_B$ (Public Key von Partner) verschlüsseln
- $K_{AB}'$ und $ID_B$ an Nachricht anhängen
- Mailempfang
- Private Key Lookup über $ID_B$
- Private Key mit Passphrase entschlüsseln
- $K_{AB}$ mit Private Key entschlüsseln
- Nachricht mit $K_{AB}$ entschlüsseln
- Public Key Lookup über $ID_A$
- Signatur mit $e_A$ verifizieren
- Nachricht hashen und mit Signatur vergleichen
- Web of Trust
- Dezentrale Vertrauensinstanz
- Benutzerinterpretierbare Vertrauenslevel
- Signaturserver als Archive
- Nutzerbasiertes Signieren von Keys
- - Signatur Spamming: DoS bei Verarbeitung von langen Signaturketten
Probleme
- Fehlende Inoperabilität von S/MIME and PGP
- Zunehmende Nutzung von Webmail
- Flexibilität für Unternehmensspezifische Sicherheitspolice
Messaging-Dienste
Signal Protocol
- E2E Verschlüsselung
- Erkennen von Wiedereinspielungen, geänderten Nachrichtenreihenfolgen, gelöschten Nachrichten
- Double-Ratchet Protokoll: PFS: Generierung neuen Schlüssels für jede Nachricht
- Wechselseitige Authentisierung und Vereinbarung eines Shared Secrets $SK$ über X3DH Protokoll
Extended Triple Diffie-Hellmann Protokoll (X3DH)
- Gegenseitige Authentifizierung
- Offline-Möglichkeit von Kommunikationspartner
- PFS
- Unabstreitbarkeit der Kommunikation gegenüber der Partner
- Server mit minimalen Vertrauensanforderungen
- ECDH mit kryptographischer Hashfunktion
- Asnyc-Kommunikation
- Offline-Schlüsselvereinbarung
- Öffentliche Ablage von $(IK, SPK, \{OPK_1, OPK_2, ...\})$
- Periodische Erneuerung von $SPK$
- Schlüssel
- Identity Key $IK$: Langlebige Identität
- Ephemeral Key $EK$: Flüchtiger DH Key
- Signed Prekey $SPK$: Kurzlebiger signierter Schlüssel
- One-Time Prekey $OPK$: Einmal-DH-Key
- Ablauf
- B: Veröffentlichung von Prekeys & Signatur $Sig = XEdDSA_{IK_{B,priv}}(SPK_B)$
- A: Verarbeiten von Prekeys
- Erzeugung von flüchtigem Schlüsselpaar $(EK_A, EK_{A,priv})$
- Validieren von $Sig:~ SPK_B = XEdDSA_{IK_B}(Sig)$
- Berechnung von $SK$ mittels 3-4 facher DH Anwendung (eigene Private Keys, Partner-Public Keys)
- $DH1 = DH(IK_{A,priv}, SPK_B)$
- $DH2 = DH(EK_{A,priv}, IK_B)$
- $DH3 = DH(EK_{A,priv}, SPK_B)$
- $DH4 = DH(EK_{A,priv}, OPK_{B,i})$
- $SK = KDF(DH1 ~|~ DH2 ~|~ DH3 ~[|~ DH4])$
- A: Nachrichtenversand
- Ableitung von Associated Data $AD = IK_A ~|~ IK_B$
- $c = \mathrm{AES-GCM}_{SK}(msg, AD)$
- Übertragung der Nachricht $M = IK_A, EK_A, c, ID(SPK_B) | ID(OPK_{B,i})$
- B: Nachrichtenempfang
- Extrahieren von $IK_A, EK_A$
- Prekey-Laden über die IDs
- Berechnung von $SK$, analog der Berechnung von A
Double-Ratchet Protokoll
- Symmetrische Verschlüsselung einzelner Nachrichten
- PFS
- ECDH mit Curve25519
- HMAC-SHA-256
- Symmetrische Verschlüsselung mit AES-GCM (AEAD)
- symmetrisches Ratchet: Berechnen eines Message Keys
- DH-Ratchet: Etablieren von Session Keys zur Verwendung von symmetrischem Ratchet
- Datenstrukturen
- 3 KDF-Ketten (Key Derivation Function): DH-, Sender- & Empfängerkette
- Input: Secret Chain-Key, Data
- Output: neuer Chain-Key, Output-Key
- Initialisierung
- SK als initialer Chain-Key
- Erzeugung des initialen DH-Ratchet Schlüsselpaars
- Gegenseitige Senderkette und Empfängerkette stets synchron
- Ablauf
- Berechnung von Nachrichtenschlüssel $A_i ~ \text{mit} ~ (CK, A_i) = KDF(0x01, CK)$
- Nachrichtenversand von $(e_A, N, PN, c_i)$
- $e_A$ aktueller DH-Ratchet-Key von A
- $N$ laufende Nummer der Nachrichten aus Sendekette von A
- $PN$ Anzahl der Nachrichtenschlüssel aus der vorherigen Sendekette
- $c_i = AES-GCM_{A,i}(mA_i)$ Verschlüsselte Nachricht
- Senderkette aktualisieren
- Nachrichtenempfang
- Prüfung anhand von $N$ und $PN$, ob DH-Ratchet oder symmetrisches Ratchet nötig
- Symmetrisches Ratchet
- Schlüsselberechnung für alle ausstehenden Nachrichten bis zu aktuellem Nachrichtenschlüssel
- Erforderliche Anzahl $s$ an Ratchet-Berechnungen mit $LR$ Länge der Empfängerkette
- $s = N-LR$ wenn Session
- sonst $s = PN - LR$
- DH-Ratchet
- Nachricht von A mit neuem Ratchet-Key -> Erzeugen von neuem Key notwendig
- Berechnung eines neuen CK-Keys für Empfängerkette: $DH = ECDH(d_B,e_A),~ (CK, RK_{neu}) = KDF(DH, RK),~RK$ Chain key der Rootkette
- Erzeugung eines neuen Ratchet-Keypairs
- Berechnung eines neuen DH-Keys, $RK$, $CK$ der Senderkette
- Empfängerkette aktualisieren
Telegram Messenger
- eigenes Protokoll MTProto
- Eigenschaften
- AES-IGE-256 (kein AEAD)
- DH statt ECDH, RSA Signaturen
- Cloud Chats: Verschlüsselte Nachrichtenablage auf Server
- Secret Chats: E2E Encryption, nur wenn beide Partner online
- Transport Obfuscation Protokoll statt TLS
- Ablauf
- Clientregistrierung beim Server
- Anmeldung mit Telefonnummer, Validierung über SMS
- DH-Key Exchange, Serverkey signiert
- Server sendet $p, q$ prim
- Proof-of-work: Clientseitige Faktorisierung von $p*q<2^{63}-1$
- Client erzeugt temp. Secret $NN_C$ mit $p,q$
- DH-Key-Erzeugung unter Verwendung von $NN_C$ als MitM-Detection
- Zeit-Synchronisation
- Statt PKI: App enthält public key des Servers
- Ableiten des 2048 bit Authentication Keys $auth_key$
- Chatverschlüsselung
- 128 bit Message hash: mittlere 128 bit des SHA-256 des Nachrichtentextes
- Berechnen des 256 bit AES Nachrichtenschlüssels $K = KDF(auth_key~|~msg)$
- Unkonventionelle Verwendung von Crypto
- IVs als vertrauliche Information, erzeugt mit Schlüsselmaterial aus Hash der Nachricht
- Salt als Replay-Schutz
- AES-IGE zur Erkennung von Ciphertext-Manipulation mit zusätzlicher MAC-Verschlüsselung (äquivalent zu AES-GCM-AEAD)
- AES-IGE
- Infinite Garble Extension
- Cipher IV und Message IV
- $c_i = f(m_i \oplus c_{i-1}) \oplus m_{i-1}$
- Fehler breiten sich über gesamte Nachricht aus
- Erschwerung von gezieltem Modifizieren
- Wenig verbreitet
Systemsicherheit
Allgemeine Design-Prinzipien
- Erlaubnisprinzip (fail-safe defaults): Zugriff standardmäßig verweigert
- Vollständigkeitsprinzip (complete mediation): Kontrollpflicht jedes Zugriffs
- Prinzip der minimalen Rechte (need-to-know)
- Prinzip des offenen Entwurfs (open design): No security through obscurity
- Benutzerakzeptanz (economy of mechanism)
Modelle der Systemsicherheit
- Anforderungen
- Separation of Duty
- Vier Augen Prinzip
- Informationsklassifikation
- Modellierungsklassen
- Discretionary Access Control (DAC): benutzerbestimmbar
- Mandatory Access Control (MAC): systembestimmt
- Usage Control (UCON), DRM-artig
- Zugriffsmodell-Matrix
- Spalte: Datei (Objekte)
- Zeile: User / Prozess (Subjekte)
- Zelle: Rechte
- Dynamik: Kommandos für Rechtemanagement
- Role-based Access-Control (RBAC)
- Zuordnung von $n$ Rollen pro Subjekt (Nutzer)
- Zuordnung von Rechten an Rollen
- Session: aktiv eingeloggte Rolle(n)
- Erweiterungen
- Statische Aufgabentrennung: Wechselseitiger Ausschluss von Rollenmitgliedschaften
- Dynamische Aufgabentrennung: Wechselseitiger Ausschluss von Rollenaktivitäten
- Bell-LaPadula Modell (BLP)
- Menge von Sicherheitsklassen (top-secret, etc..)
- Menge von Zugriffsrechten
- Menge von Kategorien (Rollen)
- BLP-MAC-Policy
- no-read-up: Kein Lesen höherer Sicherheitsklasse
- no-write-down: Kein Schreiben in niedrigere Sicherheitsklasse
- tranquility (optional): Statische Nutzerrechte zur Laufzeit
- Grenzen
- Sukzessiver Anstieg der Sicherheitsklasse von Daten
- Einführung von Trusted-Subjects: Dürfen Sicherheitseinstufungen ändern
- Blindes Schreiben: kein read-up aber write möglich
- Chinese Wall Modell
- Interessenkonfliktsklassen
- Zugriffe abhängig von Zugriffshistorie: Ausschluss aller Nachbarknoten auf gleicher Ebene unter konflikt-Parent
- Usage Control: Attributbasierte Zugriffskontrolle
- DRM
- Modellierung
- Rechtefestlegung
- Permissions
- Constraints
- Obligations
- Rechtekontrolle
- verschlüsselte Inhalte
- Lizenzen
- Allgemeiner Ablauf
- Übertragung verschlüsselter Inhalte
- Erwerb der Lizenz
- Entschlüsseln in kontrollierter Umgebung
- $UCON_{ABC}$ Modellfamilie
- Uniform Access Controll Modell
- Entscheidungskomponenten
- Autorisierung
- OBligation
- Condition
- Komponenten
- Subjekte mit Attributen
- Objekte mit Attributen
- Generische Rechte
- Kontinuierliche Prüfung
- Änderbare Attributwerte
- Boolsche Ausdrücke & Temporal-Logik
- Aktionen
- tryaccess
- permitaccess
- preupdate
- Prädikate
- $dominate$: $\leq$ Ordnung auf Sicherheitsklassen
- $permit(s,o,r)$: $r$-Zugriff von $s$ auf $o$ ist erlaubt
- Operatoren
- $\square F$ (always): F gilt in jedem Zustand
- $\lozenge F$ (eventually): Es gibt einen Zustand, in dem F gilt
- $\bigcirc F$ (next): Nachfolgezustand, wenn F erfüllt
- $\blacksquare F$ (has always been): F hat in allen Zuständen gegolten
- $\blacklozenge F$ (once): es gab einen Zustand, in dem F galt
Speicherschutzkonzepte
- Stack-Shielding: Stack Canary
- Vom compiler eingefügter Wert im Stack
- Vergleich mit Referenzwert
- Trotzdem kein Schutz vor ROP
- Data Execution Prevention
- nur .text Segment sollte ausführbarer Code sein
- CPU Feature NX-bit (no eXecute)
- Seiten als nicht ausführbar markieren
- Zusätzlich auch als nicht schreibbar
- Kein Schutz vor ROP
- Address Space Layout Randomization (ASLR)
- Randomisierung von Addressen je Programmstart
- Verhinderung von ROP innerhalb Code-Segments
- Dennoch Rücksprung in Datensegment möglich
Virtualisierung
- Virtual Machine-Monitor (VMM) / Hypervisor
- Software für VM-Ausführung
- Typen
- Typ 1: Direkt auf Hardware ausgeführt
- Typ 2: Verwendung der Dienste des Host-OS
- Sicherheitsrelevante Eigenschaften
- Isolation
- Überwachung
- Kontrolle
- OS-Level Virtualisierung: Container
- Bessere Ressourcenaufteilung unter Sandboxen als beim VMM
- Wahlweise Teil-Isolation
- Sandboxing durch Host-OS
Festplattenverschlüsselung
- Schutz vor physischem Diebstahl
- Ansätze
- Verschlüsselung durch Anwendungen
- Benötigt für jede Anwendung
- Verschieden zwischen Anwendungen
- Verschlüsselung durch Dateisystem
- Verschlüsselung durch Device-Mapper
- Blockweise Verschlüsselung zwischen Festplatten- und Dateisystemtreiber
- Keine Unterstützung des FS notwendig
- Kein vollwertiger Integritätsschutz möglich
- Verfahren
- Notwendigkeit der Unterstützung von wahlfreiem Zugriff
- CBC-Chiffre
- Copy-Paste Attack
- Bitfehler zerstören Block und erlauben deterministische Fehler in Folgeblock
- CTR-Chiffre
- Decryption mithilfe zweier Snapshots (XOR)
- AES-XTS
- Miteinbezug der Daten auf der Festplatte
- Blockweise Verschlüsselung
- Basis: AES-XEX (ECB)
- Traffic-Analyse
- Replay-Attacken
- Problematisch bei Synchronisation mit Cloud-Speicher
- Beispiel: Microsoft EFS
- AES-256-DESX
- Ableitung von priv. key aus Nutzerpasswort
Hardware-basierte Sicherheit
- Trusted Computing
- Building blocks
- Trusted platform module TPM: Hardware chip
- Core root of trust for measurement: BIOS-Erweiterung für sicheres Booten
- Trusted Software Stack TSS: Software für TPM-Zugriff
- Trusted network connect: Netzwerk-Protokolle
Trusted platform module (TPM)
- Zentrale Konzepte
- Messen: Hashwerte von Binär-Code berechnen
- Attestieren: Prüfen der berechneten Hashwerte
- Sealing: Binden gemessener Werte an eine Plattform
- TPM 1.2
- Smartcard-ähnlich
- Fest an motherboard gebunden
- Platform configuration register PCR
- Schlüssel
- spezielle Typen
- Endorsement Key $EK$
- Eindeutige Identität des TPM
- Verschlüsselt mit Owner authentication key $OAK$: Abgeleitet aus Nutzerpasswort
- priv. key nicht exportierbar aus chip
- Storage-Root-Key $SRK$
- gespeichert in nicht flüchtigem Speicher
- generiert bei Besitzerübernahme
- Attestation-Identity-Key $AIK$
- Zertifikat: Bezug von Attestation Identity-Credential (IC) von nutzerbestimmten Privacy-CA
- allgemeine Typen
- Storage
- Signing
- Binding
- Legacy
- Auth-change
- Endorsement-Credential $EC$
- Zertifikat für $EK$
- Bescheinigung über korrekte $EK$-Erzeugung
- Speicherung von Herstellername und public key
- Signiert von TPM-Hersteller
- Aufgaben
- Anbieten von Crypto-Diensten
- Keygen
- Hardware RNG
- Crypto-Algorithmen
- Shielded Speicher
- PCR: flüchtiges Register zum Speichern von Hashes
- Hardwarebasierte Zugriffskontrolle: Verschlüsselung geschützter Daten mit $OAK$
- Integritätsmessung & Attestierung
- Berechnen von Hashwerten
- Signieren von PCR-Werten mit $AIK$
- Auslagern & Binding
- Externe Verschlüsselung von Daten
- Verschlüsselte Ablage der Schlüssel in TPM
- Sealing
- Verschlüsselung von Daten zusammen mit PCR-Registern
- Entschlüsselung nur in TPM möglich
- Opt-In
- Zugangskontrolle: Nur autorisierte Benutzer
- Nachweis der Kenntnis über das Benutzerpasswort
- Probleme
- Ungeeignet für embedded
- Key-Backup-Problem: Löschen aller Schlüssel bei Owner-Wechsel
- Kein Nachladen neuerer kryptographischer Algorithmen
- Unvollständige Boot-Vertrauenskette
- Schwache Zugriffskontrolle: HMAC-Password, physikalische Präsenz
- Manuelle Aktivierung in BIOS notwendig
- TPM 2.0
- Kein Opt-in, TPM aktiv by-default
- Erweiterte Einsatzumgebung: embedded, automotive
- Neuere Crypto-Algorithmen
- Policy-Unterstützung durch AND / OR Regeln
- Policy Sessions: (räumlich) beschränkter Schlüsselzugriff
- Implementierungsvarianten
- Discrete ~: TPM-Chip, max security
- Integrated ~: Teil eines anderen Chips
- Firmware ~: Softwarebasiert im Kernelspace
- Software ~: Emulator von TPM
- Virtual ~: Hypervisor-basiert
- TPM Remote Attestierungsprotokoll
- Interaktion von TPM mit Server (Verifier)
- Ablauf
- Verifier: Angabe gewünschter PCR-Register
- TPM: Attest-Erstellung
- Nonce als Frischenachweis
- Signieren von report über Registerwerte und Nonce mit $d_{AIK}$
- Senden von report und AIK-Zertifikat
- Verifier: Prüfung
- Prüfung AIK-Zertifikat mit pub key der Privacy CA
- Signaturprüfung des Reports mit $e_{AIK}$ aus Zertifikat
- Prüfen der attestierten PCR-Daten gegenüber Referenzwerten
- TPM-basiertes Measured Boot
- Erkennung von manipulierter Systemkonfiguration
- Aufbauen von Vertrauenskette, beginnend bei BIOS-Boot-Block, CRTM
- Schrittweises Hashen von Komponenten und Speicherung in PCR
- Integritätsmessungen vor Laden von Firm- & Software
- Inkrementelles Vorgehen: Verknüpfung und hashen neuer Daten mit bisherigen PCR-Werten
- TPM 1.2
- Lediglich Berechnung der Hashes, keine Vertrauensprüfung
- Reines Mechanismus-Angebot, unterliegt OS-Policy
Trusted Execution Environment (TEE)
- Vor Hard- und Softwaremanipulation geschützte Umgebung zur Prozessorausführung
- Authentizität des ausgeführten Codes
- Integrität und Vertraulichkeit des persistenten Speichers
- Remote Attestation: Vertrauenswürdigkeit gegenüber Dritten
- Anwendungsbereiche
- DRM
- Secure Remote Computations
- Umsetzung mittels manipulationssicherer Hardware
- Varianten
- Intel Software Guard Extensions (Intel SGX)
- CPU-Befehlssatzerweiterung
- Enklaven mit eigenen, verschlüsselten Pages
- Prüfung auf veränderten Code durch Remote Attestation
- Kommunikation analog syscalls
- ARM TrustZone
- Secure World mit eigenen Privilegienstufen
- Sicheres OS, geschützte Apps
Angriffe auf aktuelle Prozessor-Architekturen
- Umgehen von Speicherisolierung
- Unautorisierter Informationsfluss
- Ursachen
- Out-of-order Execution
- Speculative execution
- Branch prediction
- Angriffsmuster
- Ausnutzen des L1 Cache und der Zeitunterschiede bei Datenzugriff je nach Speicherort (Cache-Miss)
- Side-Channel: Kommunikation über Kanal, der nicht für Kommunikation vorgesehen ist → Timing-Unterschiede
- Spectre
- Variante 1: Bounds Check Bypass
- Lesen von nicht User-mode Daten des eigenen Prozessraums
- Auslesen der spekulativ geladenen Daten im L1 Cache
- Variante 2: Branch Target Injection
- Meltdown
- Umgehen der Hardwareisolation
- Zugang zu Kernel-Pages über Side-Channel-Rekonstruktion
- Gegenmaßnahmen
- KASLR (Kernel Address Space Layout Randomization)
- KAISER-Prinzip
- Trennung der Adressbereiche von Kernel und User-space
- Flush von TLB bei Kontextwechsel
- Integration in OS: Linux Kernel Page-Table Isolation (KPTI)
Security Engineering
- Integration von Sicherheit in alle Lifecycle Phasen
- Design
- Development
- Deployment
- Maintenance
- Security by Design
- Einbinden von Sicherheitskonzepte in SW-Architektur
- Secure Coding: OWASP
- Systematische Härtung und Absicherung von live-Systemen
- PDCA-Zyklus
- Plan
- Von Problemstellung zu Maßnahmen
- Anforderungen und Risiken
- Do
- Von Maßnahmen zum funktionsfähigen System
- Realisierung
- Check
- Vom funktionsfähigen System zur Bewertung
- Messung und Validierung
- Act
- Von Bewertung zur Problemstellung
- Verbesserung
Phasen-Modelle
- Generell
- Strukturanalyse und Pflichtenheft
- Ermittlung des Schutzbedarfs
- Bedrohungsanalyse
- Risikoanalyse: quantitativ oder qualitativ
- Sicherheitspolicy & Sicherheitskonzept
- Systemmodellierung
- Systemarchitekturentwurf
- Feinentwurf und Implementierung
- Validierung und Evaluation
- Wartung und Überprüfung im Betrieb
- Microsoft SDL (Security Development Lifecycle)
- Bewusstmachen und Schulung
- Projektinitialisierung und Schutzbedarfsdefinition
- Kosteneinschätzung für Sicherheitsmaßnahmen
- Entwurfsvorgaben und Best Practices
- Risikoanalyse für Design
- Dokumentation für sichere Anwendung der Software
- Umsetzen der Best Practices, Sichere Programmierung
- Überprüfung von Sicherheit und Datenschutz
- Security Push: Letzte intensive Suche nach Sicherheitslücken
- Datenschutz-Review
- Planung für Eintreten von Sicherheitsvorfällen
- Letzte Sicherheits- und Datenschutzreviews inklusive Abnahme
- Auslieferung der Software
- Reagieren auf Sicherheitsvorfälle
- BSI Sicherheitsprozess
BSI Sicherheitsprozess
- Strategische Ebene: Initiierung
- Sicherheitsleitlinie
- Sicherheitsmanagement
- Taktische Ebene: Sicherheitskonzept
- Strukturanalyse
- Systemfunktionalität
- Pflichtenheft
- Netztopologieplan
- Schutzbedarfsfeststellung
- Realisierungsplanung
- Operative Ebene
- Umsetzung
- Aufrechterhaltung im Betrieb
Schutzbedarfsfeststellung
- Ermessen anhand von Schadensszenarien
- Verstoß gegen Gesetze
- Datenschutz
- Persönliche Unversehrtheit
- Beeinträchtigung der Aufgabenerfüllung
- Negative Innen- oder Außenwirkung
- Finanzielle Auswirkungen
- niedrig / mittel
- hoher Schutzbedarf
- Bedrohungsanalyse
- Attack tree
- STRIDE (Microsoft SDL)
- Spoofing identify
- Tampering with data
- Repudiation
- Information disclosure
- Denial of service
- Elevation of privilege
- Risikoanalyse
- Maßnahmen
Risikoanalyse
- Risikoberechnung $R = S * E$
- Schadenshöhe $S$
- Primäre Schäden
- Produktivitätsausfall
- Wiederbeschaffungskosten
- Personalkosten
- Sekundäre Schäden
- Schwer zu klassifizieren
- Imageverlust
- Vertrauensverlust der Kunden
- Eintrittswahrscheinlichkeit $E$
- Eigene Erfahrung
- Öffentliche Statistiken (CERT (Computer emergency response team))
- Einschätzung des Nutzens für Angreifer
- Einschätzung des Angriffsaufwands: Angreifermodelle
- Angreifertyp
- Budget
- Kenntnisse
- Ziele
- DREAD-Methode (Microsoft SDL)
- Damage
- Reproducibility
- Exploitability
- Affected
- Discoverability
- Einzelbewertung 1 - 3
- Gesamtrisiko aus Summe
- gering (5-7)
- mittel (8-11)
- hoch (12-15)
- Penetrationstest
Bewertung der IT-Sicherheit
- OWASP Secure coding Practices
- Input Validation
- Output Encoding
- Error Handling and Logging
- Access Control
- ...
- Kriterien zur Bewertung der IT-Sicherheit
- Maßnahmenkatalog
- (Umsetzungs-)Qualität
- Güte (der verwendeten Mechanismen)
- Evaluation und Zertifizierung
- Leitlinien für Hersteller
- Leitlinien für Anwender bei Produktwahl
Entwicklungsstufen der wichtigsten Kriterienkataloge
- Trusted Computer system Evaluation Criteria (Orange Book)
- Deutsche IT-Kriterien (Grünbuch)
- Internationale Common Criteria (CC) for Information Technology Security Evaluation
- Target of Evaluation (TOE): Evaluationsgegenstand (EVG1)
- Security Target (ST): Menge der grundlegenden Sicherheitsanforderungen
- Protection Profile (PP)
- TOE Security Policy (TSP)
- TOE Security Function (TSF): Hard-& Software zur Durchsetzung der TSP
- Evaluation Assurance Level (EAL)
- 8 Klassen: 0 - 7 (aufsteigende Anforderungen)
- Teildokumente
- Part 1: Introduction and general model
- Part 2: Security functional requirements
- 11 Funktionsklassen mit funktionellen Familien
- Klassenkomponenten: konkrete Anforderungen
- Widerspiegeln von Best Practices
- Empfohlen zur Funktionalitätsbeschreibung von Systemen
- Part 3: Security assurance requirements
Schutzprofile (Protection Profiles)
- Implementierungsunabhängige Menge von Sicherheitsanforderungen
- Beschreibung von Sicherheitskonzept
- Anwendersicht: Vergleichbarkeit verschiedener Produkte
- Herstellersicht: Bescheinigung von erfolgreichem Sicherheitsprodukt
- Aufbau
- Einführung: Identifikation & Übersicht
- EVG-Beschreibung
- EVG-Sicherheitsumgebung
- Annahmen
- Bedrohungen
- organisatorische Sicherheitspolitiken
- Sicherheitsziele
- IT-Sicherheitsanforderungen
- EVG-Sicherheitsanforderungen
- Funktionalität
- Vertrauenswürdigkeit
- Sicherheitsanforderung an IT-Umgebung
- PP-Anwendungsbemerkungen
- Erklärungen
- der Sicherheitsziele
- der Sicherheitsanforderungen