IN0042_ITSEC: Create seperate decks for each topic

IN0042_ITSEC/Hashfunktionen.yaml

@@ -0,0 +1,14 @@
+title: Hashfunktionen
+author: Hugo Melder
+id: 1709156765
+cards:
+
+- type: md_basic
+  front: Wie wird ein HMAC gebildet, wenn m die Nachricht, K der secret key und H die Hashfunktion ist?
+  back: |
+    innerHash = H(K' xor ipad) | m)
+    HMAC(K. m) = H((K' xor opad) | innerHash)
+
+    Wobei K' ein vom Secret Key abgeleiteter Schlüssel mit fester Blockgröße ist.
+
+    "|" ist hierbei die Konkatenierung von Strings.

IN0042_ITSEC/Kryptographie.yaml

@@ -0,0 +1,39 @@
+title: Hashfunktionen
+author: Hugo Melder
+id: 1709157560
+cards:
+
+- type: md_basic
+  front: Was kann bei DH schieflaufen?
+  back: |
+    Das Shared Secret sollte **niemals** selber als Schlüssel
+    verwendet werden, da es nicht gleichverteilt ist.
+    Stattdessen leitet man einen symmetrischen Schlüssel von dem
+    DH shared secret ab.
+
+- type: md_basic
+  front: Was ist ein Beispiel für eine KDF?
+  back: |
+    HKDF (HMAC-based Key Derivation Function)
+
+- type: md_basic
+  front: |
+    Was ist die erforderliche Anzahl an Nachrichten, um mit
+    Wahrscheinlichkeit > 0.5 eine Kollision zu erzeugen?
+  back: |
+    sqrt(2^n) also 2^(n/2), bei n-bit Hashwerten
+
+- type: md_basic
+  front: |
+    Bei einer Hashfunktion mit 80-bit Hashwerten, wie viele Berechnungen
+    erfordert ca. ein Kollisionsangriff?
+  back: |
+    Ungefähr 2^40 Hashwert-Berechnungen. n = 80 ist also zu klein!
+
+- type: md_basic
+  front: Nenne zwei dedizierte Signaturverfahren
+  back: DSA, ECDSA
+
+- type: md_basic
+  front: Nenne ein Verfahren zur Festplattenverschlüsselung.
+  back: AES-XTS

IN0042_ITSEC/PKS.yaml

@@ -0,0 +1,116 @@
+title: PKS
+author: Hugo Melder
+id: 1708962331
+cards:
+
+- type: md_basic
+  front: Was sind die Komponenten einer PKI?
+  back:  |
+    1. **Registration Authority (RA)**: bürgt für die Verbindung zw.
+    öffentlichem Schlüssel und Identitäten/Attributen
+    2. **Certification Authority (CA)**: Stellt Zertifikate aus
+    3. **Validierungsstelle (VA): Überprüfung von Zertifikaten
+    4. **Verzeichnisdienst**: Verzeichnis mit ausgestellten Zertifikaten
+    5. **Personal Security Environment (PSE)**: Sichere Speicherung des privaten
+    Schlüssels
+
+- type: md_basic
+  front: Wer signiert Root Zertifikate?
+  back: |
+    Root Zertifikate sind **selbstsigniert**.
+
+- type: md_basic
+  front: Was ist ein Trust Anchor?
+  back: |
+    Ein Trust Anchor (Vertrauensanker) ist eine autoritative Entität,
+    repräsentiert durch einen öffentlichen Schlüssel und eine zugehörige Identität
+    (wie eine Root-Zertifizierungsstelle (CA)), der Benutzer und Systeme inhärent
+    vertrauen.
+
+- type: md_basic
+  front: Wo werden Root CAs gespeichert?
+  back: |
+    - Betriebsystem
+    - Browser
+
+- type: md_basic
+  front: Wie wird die Gültigkeit der Signatur überprüft?
+  back: |
+    Jedes Zertifikat auf dem Pfad muss überprüft werden: d.h
+    - Signatur überprüfen
+    - Verwendete Algorithmen mit Blacklist abgleichen
+    - Zertifikat wurde nicht zurückgerufen
+    - Zertifikat nicht abgelaufen
+    - Root CA wird vertraut
+
+- type: md_basic
+  front: Wie funktioniert das asymmetrische Challenge Response (CR)-Verfahren
+  back: |
+    - d_A ist der private Signaturschlüssel
+    - e_A ist der öffentliche Validierungsschlüssel
+
+    Alice besitzt (e_A, d_A) und ein Zertifikat(e_A), was die Herkunft von e_A bestätigt.
+
+    1. Loginanfrage mit Zertifikat (Alice -> Server)
+    2. Server prüft Zertifikat und schickt eine Nonce zurück
+    3. Alice berechnet E_dA(Nonce) und sendet sie dem Server zurück
+    4. Server prüft Signatur und gibt Status zurück
+
+- type: md_basic
+  front: Wie kann der Client feststellen, ob ein Zertifikat rückgerufen wurde?
+  back: |
+    Lösung liefert das **O**nline **C**ertificate **S**tatus **P**rotocol (**OCSP**).
+    
+    Durch eine Anfrage kann die Gültigkeit des Zertifikats abgefragt werden, ohne eine große
+    Revokationliste lokal zu verwalten.
+
+- type: md_basic
+  front: Was ist der grundlegende Aufbau einer SSO Lösung?
+  back: |
+    - **Authentisierung** durch **Policy Decision-Point** (PDP)
+    - Prüfung auf **Gültigkeit** durch **Service** (z.B. S1): das
+    ist ein Policy-Enforcement-Point, PEP
+
+- type: md_basic
+  front: Nenne drei SSO-Protokolle, die in der Praxis verwendet werden
+  back: |
+    - Unternehmensnetzwerk: Kerberos-Protokoll
+    - Web-Anwendungen: OpenID Connect und OAuth
+    - Web-basiert, Akademia: Shibboleth (auch TUM)
+
+- type: md_basic
+  front: Wie ist der KDC (In der Vorlesung auch AuC genannt) bei Kerberos aufgeteilt?
+  back: |
+     - Authentication Service (AS)
+     - Ticket-Granting Service (TGS)
+
+- type: md_basic
+  front: Wird asymmetrische Kryptographie im Kerberos-Protokoll eingesetzt?
+  back: Nein. Kerberos verwendet im Standard nur symmetrische Kryptographie.
+
+- type: md_basic
+  front: Was sind die 2 Kern-Konzepte von Kerberos?
+  back: |
+    - **Ticket**: für Zugriff auf einen Service wird ein Ticket benötigt.
+    - **Authentikator**: Nachweis des berechtigten Ticket-Besitzes.
+
+- type: md_basic
+  front: Beschreibe den Aufbau des Ticket Granting Services
+  back: |
+    Ticket für A und Service S:
+    `T^(A,S) = (S, A, addr, timestamp, lifetime, k_AS)`
+
+- type: md_basic
+  front: Wie wird das Ticket T^(A, S) verschlüsselt?
+  back: |
+    Ticket wird von TGS mit Master-Key k_S von Service S verschlüsselt:
+    i.d.R wird AES verwendet: AES_ks(T^(A,S)).
+
+- type: md_basic
+  front: Was versteht man unter TOFU?
+  back: |
+    Bei diesem Modell wird einem Schlüssel oder einem Zertifikat beim ersten
+    Gebrauch vertraut, und dieser initial etablierte Vertrauensanker wird für
+    zukünftige Verbindungen oder Transaktionen verwendet.
+
+    TOFU findet zum Beispiel im SSH Protokol Verwendung.

IN0042_ITSEC/Systemsicherheit.yaml

@@ -0,0 +1,48 @@
+title: Systemsicherheit
+author: Hugo Melder
+id: 1709159552
+cards:
+
+- type: md_basic
+  front: Randomisiert Address space layout randomization (ASLR) alle Segmente?
+  back: |
+    Nein! Zum Beispiel wird die Basisadresse des Codesegmentes nicht randomiziert,
+    außer die Executable wird explizit mit `-fpie` kompiliert.
+
+- type: md_basic
+  front: Was versteht unter der Trusted Computing Base (TCB)?
+  back: |
+    - Menge der Software- und Hardwarekomponenten und Kontrollen, die
+    zusammenwirken, um die Sicherheitsdienste des Systems durchzusetzen.
+    - Fasst die sicherheitskritischen Funktionen der Hardware und des BS
+    zusammen.
+
+- type: md_basic
+  front: Kann ASLR _return-to-libc_ Angriffe verhindern?
+  back: |
+    Es kann sie zumindest erschweren, da die Adresse sich
+    regelmäßig ändern (Hängt von ASLR Implementierung ab. Jeder Prozessstart bei
+    Linux).
+
+- type: md_basic
+  front: Welche Rechte haben Heap, Stack, und Data, wenn DEP aktiviert ist?
+  back: |
+    `rw-`
+
+- type: md_basic
+  front: Was versteht man unter DEP?
+  back: |
+    DEP (Data Execution Prevention) restriktiert die Ausführbarkeit von
+    Code auf Seiten. Dabei bietet sich an alles außer das text Segment
+    als nicht-ausführbar zu markieren.
+
+- type: md_basic
+  front: (Extra) Was kann man mit der `mprotect` function auf einer Seite ändern? 
+  back: |
+    `mprotect`kontrolliert den Schutz von einzelnen Seiten. Zur Auswahl stehen:
+    - PROT_NONE
+    - PROT_READ
+    - PROT_WRITE
+    - PROT_EXEC
+
+    Eine Seite kann mehrere dieser Attribute gleichzeitig haben.

IN0042_ITSEC/TLS.yaml

@@ -0,0 +1,44 @@
+title: TLS
+author: Hugo Melder
+id: 1708962331
+cards:
+
+- type: md_basic
+  front: Wann ist eine TLS Verbindung kompromitiert?
+  back:  |
+    Die Authenitizität des Servers basiert auf der Certificate Chain.
+    Beispielsweise würde die TLS Verbindung durch eine **kompromitierte
+    Certificate Authority (CA)** nicht mehr sicher sein.
+
+    Jedoch hilft eine intakte Certificate Chain nicht, wenn der
+    **Server kompromitiert** wurde.
+
+- type: md_basic
+  front: |
+    Ein Angreifer hat alle Nachrichten eines TLS-Handshakes abgefangen. Er
+    maskiert sich nun als Server und sendet dem Client beim nächsten Handshake in
+    jedem Schritt die entsprechende Nachricht der vorherigen Aufzeichnung zurück.
+    In welchem Schritt des Handshakes und woran erkennt der Client den Angriff?
+  back: |
+    Der Client erkennt den Replay-Angriff beim Überprüfen von ServerHello. Der
+    Server wird hier eine Nachricht zurückspielen, die nicht den aktuellen Nonce
+    Rc des Clients im MAC berücksichtigt.
+
+- type: md_basic
+  front: |
+    Kann der Server auch ein Zertifikat vom Client bei TLS erwarten?
+  back: |
+    Ja, hierbei überträgt der Client das angeforderte Zertifikat
+    nachdem er ServerHello empfangen, und die Anfrage übersetzt hat.
+
+    Die Authentizität wird mithilfe einer Signatur über alle bisherigen
+    Nachrichten mit dem um Zertifikat gehörenden privaten Schlüssel
+    signiert.
+
+- type: md_basic
+  front: Angenommen eine stateful request wird via 0-RTT TLS an den Server
+  verschickt. Zu welchen Problem kann es hierbei kommen?
+  back: |
+     Da 0-RTT-Daten ohne vollständige Verhandlung gesendet werden, kann ein
+     Angreifer diese Daten abfangen und erneut an den Server senden. Der Server
+     könnte diese erneut gesendeten Daten als neue, legitime Anfragen behandeln.

IN0042_ITSEC/WebSecurity.yaml

@@ -0,0 +1,59 @@
+title: Hashfunktionen
+author: Hugo Melder
+id: 1709158524
+cards:
+
+- type: md_basic
+  front: Was macht das `Secure` Attribut bei einem Cookie?
+  back: |
+    Der Cookie wird nur gesendet, wenn die Anfrage über einen
+    sicheren Kanal versendet wird.
+
+- type: md_basic
+  front: Was macht das `HTTPOnly` Attribut bei einem Cookie?
+  back: |
+    Wenn `HTTPOnly` gesetzt ist, wird der Zugang via ein Client-side
+    Script verwehrt.
+
+- type: md_basic
+  front: Welche Optionen gibt es beim SameSite Attribut?
+  back: |
+    - strict
+    - lax
+    - none
+
+- type: md_basic
+  front: Was gilt, wenn SameSite=Strict bei einem Cookie gesetzt ist?
+  back: |
+    Der Cookie wird nur gesendet, wenn es eine direkte, nutzer-initiierte
+    Anfrage ist (z.B von der Browser URL bar).
+
+- type: md_basic
+  front: Was gilt, wenn SameSite=Lax bei einem Cookie gesetzt ist?
+  back: |
+    Cookie wird bei Cross-Site-Anfragen nicht gesendet, außer, die Anfrage
+    erfolgt durch eine "Top-Level-Navigation" und ist eine GET oder HEAD Anfrage. z.B:
+    - Bei normalen Links von einer externen Site zur Website
+
+    Jedoch **nicht** bei anderen Arten von Cross-Site-Anfragen wie
+    POST-Methoden, Bildern in <img>-Tags oder in AJAX-Requests.
+
+- type: md_basic
+  front: Was ist die Same-Origin-Policy (SOP)?
+  back: |
+    Die SOP restriktiert Script-initiierte Anfragen zu dem gleichen Ursprung.
+    Das Triplet aus (Schema, Host, und Port) müssen hierbei Übereinstimmen, damit
+    die Anfrage erfolgreich durchgeführt werden darf.
+
+- type: md_basic
+  front: Wann greift die Same-Origin-Policy (SOP) nicht?
+  back: |
+    Bei Nutzer-initiierten Aktionen wie das versenden von Formularen!
+
+- type: md_basic
+  front: Was ist der Unterschied zwischen *persistent* und *reflective* XSS?
+  back: |
+    Bei persistentem XSS wird Schadcode in die Datenbank einer Website
+    eingefügt und bei jedem Aufruf der Seite dargestellt.
+    Bei reflektiertem XSS wird der Code direkt über die URL oder in einem Formular
+    gesendet und sofort ausgeführt.