IntroSec

Added contents of Lecture 6 (Certificates, PKI, Diffie-Hellman).

1 files changed, 122 insertions, 0 deletions

diff --git a/en_GB/Introduction to Information Security/introduction_to_information_security.md b/en_GB/Introduction to Information Security/introduction_to_information_security.md
index 60dfd2a..4234a8c 100644
--- a/en_GB/Introduction to Information Security/introduction_to_information_security.md
+++ b/en_GB/Introduction to Information Security/introduction_to_information_security.md
@@ -111,6 +111,19 @@ $$
 \text{digest} = \text{h}(\text{h}(\text{username}:\text{realm}:\text{password}):\text{nonce}:\text{h}(\text{method}:\text{digest-uri}))
 $$, $\text{h}$ being a one-way-function, $\text{:}$ being the concatenation operator.
 
+### HTTP Session authentication
+
+Authenticating every single *POST* and *GET* request is inefficient.
+Therefore, authentication is done at the beginning of the session and remains until the end of the session.
+
+#### Unilateral Authentication
+
+Only one party is authenticated, while the other is an anonymous entity. This is common practice in the web with HTTPS.
+
+#### Mutual Authentication
+
+Every communication party is authenticated to each other.
+
 ### Biometrics
 
 #### Use cases
@@ -189,6 +202,7 @@ Probability of some sample to match at least one of the entries in the database.
 $$
 \text{FPIR} = (1 - \text{FTA}) \times (1 - (1 - \text{FMR})^{n})
 $$
+, $\text{n}$ being the database size.
 
 #### Biometrics in remote authentication
 
@@ -238,6 +252,91 @@ Compared to *MAC*, it does not rely on shared secret keys. Instead, it uses *Pri
 2. Sender sends message and appends signature $\text{sig}$.
 3. Receiver verifies signature $\text{sig}$ using *Public Key* of the sender.
 
+## Sessions
+
+### TLS Sessions
+
+1. Client proposes a suite of ciphersuites to the server.
+2. Server picks a ciphersuite and sends the certificate (containing the public key of the server) to the client.
+3. Client generates *pre-master-secret*, encrypts it with the servers public key and sends it to the server.
+4. Only the server can decrypt the *pre-master-secret* with his private key (authentication).
+5. Session is established and symmetrically encrypted using shared but secret key.
+
+### Forward Secrecy
+
+*Forward Secrecy* ensures that even if the private key of the server gets compromised, old session keys are not compromised.
+Therefore, secure sessions remain secure, even with revealed private keys afterwards.  
+TLS provides *Forward Secrecy*, because with a compromised public key, new sessions can be forged, but old sessions are not compromised,
+because they are encrypted with *master-secret*.
+
+### Diffie-Hellman Key Agreement
+
+#### Principle
+
+1. *A* has a secret box, applies a lock on it and sends it to *B*.
+2. *B* adds his lock to the package and sends the result to *A*.
+3. *A* removes his lock and sends the result to *B*.
+4. *B* removes his lock and has the secret box.
+
+#### Discrete Logarithm Problem (DLP)
+
+Group $(\text{G}, \circ)$, Generator $\text{g}$ so that $\forall \text{g'} \in \text{G} : \exists \text{n} \in \mathbb{N} : \text{g'} = \text{g}^{\text{n}} = \text{g} \circ ... \circ \text{g}$.
+
+- Discrete exponentiation (calculating $\text{g}^\text{n}$) is easy.
+- Taking discrete logarithm (calculating $\text{x}$ for given $\text{g'} = \text{g}^\text{x}$) is computationally infeasable.
+- Normally, $\text{G} = \mathbb{Z}/\mathbb{Z}_\text{p}$ (elements of $\mathbb{Z}$ modulo some prime $\text{p}$).
+- Exponention modulo $\text{p}$ is commutative: $(\text{g}^\text{x})^\text{y} \mod \text{p} = \text{g}^{\text{x}\text{y}} \mod \text{p} = (\text{g}^\text{y})^\text{x} \mod \text{p}$.
+- Order of *g*: Smallest number *n*, so that $\text{g}^\text{n} = 1$.
+
+#### Algorithm
+
+1. *A* and *B* agree on primes *p*, *q* and a generator *g* of order *q*.
+2. *A* picks random number *x*, sends $\text{X} = \text{g}^\text{x} \mod \text{p}$ to *B*.
+3. *B* picks random number *y*, sends $\text{Y} = \text{g}^\text{y} \mod \text{p}$ to *A*.
+4. *B* computes shared secret $\text{X}^\text{y} = \text{g}^{\text{x}\text{y}} \mod \text{p}$.
+5. *A* comoutes shared secret $\text{Y}^\text{x} = \text{g}^{\text{y}\text{x}} \mod \text{p}$.
+6. *A* and *B* now have the same shared secret, since $\text{X}^\text{y} = (\text{g}^\text{x})^\text{y} \mod \text{p} = \text{g}^{\text{x}\text{y}} \mod \text{p} = (\text{g}^\text{y})^\text{x} \mod \text{p} = \text{Y}^\text{x}$.
+
+#### Remarks
+
+Diffie-Hellman does not provide authentication. When establishing a connection between *A* and *B*, an attacker *C* could intercept the connection during
+key agreement and distribute his own keys to *A* and *B* respectively.  
+In TLS, the Diffie-Hellman values coming from Server to Client are signed with the servers public key to prevent this.
+
+### HTTP sessions
+
+HTTP sessions per se do no end with TCP connections.  
+To check for Man-In-The-Middle attacks, TCP session state is included in the HTTP digest.
+Then the server also checks against his session state. If they are not equal, there is a MitM.
+
+## Certificates
+
+*Certificates* are used for authentication, mostly by the server in TLS sessions.  
+They contain the public key of the owner amongst other information (issue date, expiration date etc.).
+By default, public keys are not bound to real world entities. To create this binding, some kind of authority of trust has to propagate it.
+To do so, *Certificates* contain a signature of the *Certificate Authority* (CA). *Certificate Authorities* also have their own certificates,
+signed by an above *Certificate Authority*. This forms a hierarchy of authorization, with *Root Certificate Authorities* on top.
+*Certificates* for those are pre-installed on the machines.
+
+### X.509
+
+*X.500* is a global repository of named entities (people, computers etc.).  
+*X.509* is a certificate format binding public keys to those database entries. This is the de facto industry standard.
+
+### Public Key Infrastructure (PKI)
+
+Infrastructure providing the service of public key distribution.
+
+#### Certificate Classes
+
+- Domain Validated SSL Certificate (DV cert)  
+  Cheap. Verify owner of domain via *whois* and DNS records. There are reserved email addresses (e.g. postmaster@example.com),
+  which can be used aswell. This is a potential security issue! MX delegation to anonymous email services has to be carefully minded!
+- Organization Validation SSL Certificate (OV cert)
+  Medium. CA checks same as *DV* + company identity checked by third parties.
+- Extended Validation SSL Certificate (EV cert)
+  Expensive. CA checks same as *OV* + official record matching.
+
 ## Threat scenarios
 
 No security issues without threat models! E.g. a password is considered safe without any provided threat model.
@@ -248,6 +347,15 @@ Attacker sends out ICMP ping request with spoofed sender IP address of the victi
 All recipients will answer the ping, and send the answer packets to the IP address they think was the sender, which is the victims IP address.
 In a network with 100 nodes, a single broadcast ICMP request results in 100 answers sent to the victim, causing a denial of service.
 
+### TCP session hijacking
+
+Attacker pretends to be a trusted host.
+
+1. Attacker sends *SYN* packet with spoofed address of the trusted host to the server.
+2. Server replies with *SYN ACK*, with some sequence number *y*, but sends the response to the trusted host he thinks sent the *SYN*.
+3. Attacker now has to guess the sequence number *y* in order to reply with an *ACK* and sequence number *y + 1*.
+4. If guessed correctly, the attacker can send TCP packets as trusted host.
+
 ### Password compromise
 
 Old threat model: One machine, one password. One compromised password means one compromised machine.
@@ -263,3 +371,17 @@ Victim enters his password and the attacker captures the data forwarded by the f
 - System authentication to the user
 - Display number of failed logins  
   Indicates compromised password to the user.
+
+### Cookie poisoning
+
+1. Session begins, server issues session ID (SID), which gets stored as a client cookie.
+2. A client changes his own SID cookie according to a SID of another client, therefore hijacking the session and being able to do everything the other client can do.  
+   He can do this by  
+2.1 Brute-force.
+2.2 Having access to the cookie and simply reading it out (security failure).
+
+#### Countermeasures
+
+- Picking random, hard to guess SIDs
+- Storing cookies in a safe place
+- Include a MAC with the SID to check for integrity