Lecture

Assuming we have physical security, this network is secure

1. Passive attacks (= “observation”)

2. Active attacks (= “observation + manipulation”)

• Eavesdropping of packets/messages (Eavesdropping = “Abhören“)

• Traffic Analysis

• All passive attacks

• Modify a packet/message

• Replay a packet/message

• Delay a packet/message

• Delete a packet/message

• Forge a packet/message (create a new one)

• attacker is or owns the network (all routers, switches, connections)

• But: The attacker has no control over end systems

• The attacker can perform any active and passive attack

• But: The attacker cannot break cryptographic primitives (encryption, signing, hashing, etc.)

• attacker can perform any active/passive attack on you

• defend against this attacker -> Establish a secure tunnel to a server in the Internet and Route all your packets over the secure tunnel

• attacker can now perform only DoS (Denial Of Service) attacks against you, collect meta data, etc

• Internet: Best effort packet switching

• End-user/attacker has no control how packets are routed → “Lottery of Doom”

• NSA/GCHQ/ have black boxes basically everywhere → only end-to-end encryption helps...

• The attacker could try to perform timing attacks against your server

• Work by measuring how long certain operations (operation successfully completed, operation failed) take at your server

  —> the attacker might be able to break a security service, deduce a secret key, etc.

• Only works if the service is vulnerable to side-channel attacks

• Such measurements are usually not possible/difficult over the Internet, as latencies/delays make it difficult to get good measurements

• AS can announce manipulated BGP prefixes and re-route ("hijack") traffic

• ISP might alter "unprotected" packets:

  • “Value-added service 1”: ISP places ads on the websites you are visiting (e.g. aircraft WiFi networks)

  • “Value-added service 2”: ISP reduces quality of images to save bandwidth (e.g. mobile networks)

  • “Value-added service 3”: ISP redirects requests to non-existent or mistyped websites to their own portal with ads

• Confidentiality

• Data Integrity

• Authenticity (of data/of a communication partner)

• Controlled Access

• Accountability

• Availability

  
  

• German: “Vertraulichkeit”

• Information must be concealed → Attacker cannot read/understand information

• Example: Encrypt information with a symmetric cipher

• German: “Datenintegrität”

• Changes to data must be noticeable → Attacker cannot modify data without being detected

• Example: Hash value (“fingerprint”) of a file stored on a public server.

  The fingerprint is stored at some secure location

• German: “Echtheit”

• We must know who the originator of data is/who our communication partner is

• Example: Digital mail signature authenticates the mail/a challenge/response protocol authenticates our communication partner

• German: “Zugriffskontrolle”

• Only authorized entities can access certain services or information

• Example: Employ an access control system, firewall, etc.

• German: “Zurechenbarkeit”

• Identify the entity responsible for a (communication) event/change at a file/...

• Example: Employ a logging system of some sort

• German: “Verfügbarkeit”

• Services/data/... must be available and function correctly

• Example: Important services/data shall be replicated/stored redundandly

• Integrity: "Proves that data item did not change"

• Authenticity: "Proves that data item was created by user x"

• Authenticity of data implies integrity

• Authentication: "Authenticity of user, i.e., find out identity of user"

• Authorization: "Find out whether a user is allowed to perform an action"

• Access control systems enforce controlled access

• Step 1: Authenticate user

• Step 2: Authorize user

• Prevents that someone can claim that they did not do something, like changing/deleting a file

• (German “Nicht-Abstreitbarkeit”)

• Needs authentication and accountability (“logging”)

• Prevents that someone does something nasty, like changing/deleting a file

• (German “Abschreckung”)

• Caused by non-repudiation and fear of prosecution

A threat in a communication network is any possible event or sequence of actions that might exploit a vulnerability, leading to a violation of one or more security goals

Threats can be more or less "problematic" or "critical"

• Likelihood: Can the attack be implemented efficiently, which makes it more likely and hence more critical?

• Resulting damage: Is the attacked target a critical component, which makes the attack more critical

An entity claims to be another entity (also called “masquerade”)

An entity creates new information in the name of another entity

Data is being altered or destroyed

An entity falsely denies its participation in a communication act

An entity reads information it is not intended to read

An entity uses a service or resources it is not intended to use

Any action that aims to reduce the availability and / or correct functioning of services or systems

• Impersonation

• Forgery of information

• Modification or loss of (transmitted) information

• Repudiation

• Eavesdropping

• Authorization Violation

• Denial of Service (Sabotage)

• Yes

• Yes, if the attacker is or owns the whole network (Dolev-Yao model)

• No, cause he doesn’t know the seqeunce number from Bob

The attacker tries many connections with forged source addresses

->Bob creates a new entry for every Connection in his Connection-Table and waits for a response

->Bob’s connection table fills up with many half-opened connections

->Legitimate users can not establish new TCP connection

• SYN Cookies

• Bob generates the initial sequence number α:

  • α = h(K , Ssyn)

  • K is a secret key

  • Ssyn denotes the source address of the SYN packet

  • h is a one-way function

• At arrival of the ACK message, Bob calculates α again

Advantages:

• Server does not need to allocate resources after the first SYN packet

• Client does not need to be aware that the server is using SYN cookies

• SYN cookies don’t requires changes in the specification of the TCP protocol

Disadvantages:

• Calculating α may be CPU consuming

  • Moved vulnerability from memory to CPU

• ACK/SEQ number are only 32 Bit long

• Efficient implementation (fast but insecure crypto) may be vulnerable to cryptoanalysis after receiving a sufficient number of cookies

  • overcome by including a timestamp

• TCP options cannot be regularly negotiated (e.g. large window option) using cookies, in all implementations

• Calculating α may be CPU consuming?

  • Highly efficient. CPU-local, barely any cache misses

• TCP options cannot be negotiated?

  • Window size (here MSS) up a certain value hacked into cookie

  • SYN Cookies are only dynamically enabled if net.ipv4.tcp_max_syn_backlog is exceeded

• Efficient implementation vulnerable to cryptoanalysis?

  • using SipHash is a proper one-way function (non-cryptographic, keyed hash function)

  • A counter is updated every minute

Any intermediary box, performing functions apart from standard functions of an IP

router on the data path between a source host and destination host

example functions:

• Filtering

• Inspection

• …

• Protocol Layer - on which layer or layers (cross-layer - e.g firewalls) does the box work?

• Functional vs. Optimizing - explicitly needed function (SMTP, SIP) or optimization (NAT)?

• Soft-State vs. Hard-State - if box loses state, can session continue (in degraded) state or does it fail?

• Firewalls:

  • Filter traffic based on a set of rules by a network administrator

• Intrusion Detextion Systems (IDS)

  • Monitor traffic and collect data for (offline) analysis for securtity anomalies

  • Capable of more complex inspection than Firewalls

A security policy, a specific statement of what is and is not allowed, defines the systems security

Security Mechanisims enforce the policies; their goal is to ensure that the system never enters a disallowed state

• Example: IPsec gateways, Firewalls, SSL, …

• The policy defines security. the security mechanisms enforces it.

A system is secure if, started in an allowed state, always stays in states that are allowed.

• Security Goals/Requirements

  • Define security goals

  • Confidentiality, Data Integrity, Authenticity, Controlled Access, Availability, Accountability

  • “What do we want?”

• Security Policy

  • Rules to implement the requirements

  • “How to get there?”

• Security Mechanisms

  • Enforce the policy

  • “What tools do we use?

    
    

Network firewalls protect entire networks.

Desktop firewall only protects the local computer.

• Firewall = Packet filter enforcing security policies

• controlled Acces at the network level

• Installed where a protected subnetwork is connected to a less trusted network

  • normally placed between Internet and local network

View 1 ("outside view by admin of the LAN")

• Incoming: from the Internet to the local network

• Outgoing: from the local network to the Internet

View 2 ("inside view from the firewall")

• On each interface, there are incoming and outgoing packets

• By default nothing

  -> needs to be configured

Default deny strategy:

• Everything not explicitly allowed (= whitelisted/allowlisted) is denied

• increased security; you know what applications are allowed to communicate

• Users that use non-standard applications/protocols will complain

Default permit strategy:

• Everything not explicitly blocked (= blacklisted/blocklisted) is permitted

• Less secure

• Less hassle with users

Bestpractice: Default Deny

Mix: Default deny for inbound traffic, default permit for outbound traffic

• configured by a ruleset/rulelist

• For every packet, the ruleset is processed sequentially from top to bottom until a matching rule is found

Rule have actions and Match conditions:

Actions:

• Accept

• Drop (no answer at all; connection attempt times out)

• Reject (actively reject a connection; “more graceful drop“)

• Log accepted/dropped/rejected connections

Match conditions:

• Incoming interface (from firewall viewpoint)

• All layer 2-4 packet fields (MAC adress, IP addresses, protocol, prots, flags …)

• Stateful matches -> Firewall tracks connections for you

• Geofence (firewall uses knowledge which (source) Ip ranges are used in which countries) -> can be bypassed by a tunnel into allowed country (e. g. VPN tunnel)

• Futher advanced conditions (rate limiting, locally tagged packets, …)

L2 - Link Layer - Ethernet:

• Ethernettype -> IPv4 or IPv6

• Ethernet MAC Adress (easyly spoofable)

L3 - Network layer - Ipv4:

• IP-Adress

• Tramsport protocol

• Flags: Ip-fragment

L4 - Transportlayer - TCP/UDP:

• Ports (Determine the communicationg applications/service)

  • Well known ports (0- 1023) [HTTP(80), DNS (53), HTTPS (443)]

  • Registered Ports(1024-491511) [IRC (6667)]

  • Ephemeral Ports (49152- 65535) [ports meant to be used temporarily by clients]

• Flags:

  • SYN: only set in the first two segments

  • ACK: set in every segmment of a connection but the very first

  • RST: close/reject a connection

L5-7 - Appliaction Protocol:

• Deep Packet inspection (DPI) [encryption obviously prevents DPI]

• usually not done by firewalls

• easier to realize in proxy systems

• First packet of connection may generate a state (“memorized meta data“) in the firewall

  • State is the IP-5-tuple (Src IP, Dst IP, Proto, Src Port, Dst Port) which identifies “known“ connections

  • Keeping state/connection tracking simplifies firewalling

  • Tearing down connection (FIN) clears state; alternatively timer runs out

• States (“conditions“) of a connection [not the same state as in the point before]

  • NEW: Firtst paket of a connection (no state (meta data) in the firewall yet)

  • ESTABLISHED: All following packets (state (meta data) exists in firewall)

• Optinal State tracking (depending on your firewall)

  • TCP sequence and ack numbers

  • ICMP sequence numbers and request/response tracking

  • Idea: numbers must grow monotonously (till they wrap around)

• UDP is stateless, no connections exist

  • Approximation of UDP connection tracking possible using a timer

• No state information is generated when processing a packet

• Only operates on the rules and each individual packet

• Why? Keeping state is expensive and needs fast memory

Rule number:

• only few rules ->stateless filtering may be faster

• many rules -> stateful filtering may be faster

DOS attacks:

• Stateless FW: Send more packets than the FW can match -> perferably such matched very late

• Stateful: Exhaust the FW’s memory with useless state

Rule of thumb:

• Stateless firewalls are more complex to configure

• which makes configuration errors more likely

• Whenever possible use stateful firewalls (Hardware costs < rist of disasterous security incidents)

• you can approximate the state of the connection

  • cause the flag is set in every TCP segment except the frist one

• ACK flag set ≈ not NEW

• Protocols such as UDP don’t have state information

  • Not possible to differentiate between initiator and responder.

• sending packets using a source IP address that is not yours

Outgoing (to the Internet):

• only allow source IPs which belong to you

• Don’t be an operator who facilitates spoofed DOS attacks to the Internet

Incoming (from the Internet):

• Only allow ‘valid‘ source IPs

• For a varying definition of ‘valid‘

• IPs which belong to you are not valid

• Local and special purpose IPs are not valid

• Rule of thumb: UNIV\ (Your Ips ∪ special Purpose IPs)

Except filtering for special purpose IPs, it is only possible to filter sproofed packets close to sender or reveiver:

• Only “Sender’s firewall“ knows its local network’s IP range and can drop spoofed outgoing traffic

• Only “receiver’s firewall“ knows its local network’s IP range and can drop spoofed incoming traffic

• Other firewalls cannot differentiate

• reachability of the firewall management interface

  • From the internet? From the complete internal network?

• What is allowed over the internet?

  • dont allow: NetBios, NFS, RPC, Telnet (no security at all)

• IPv4 and IPv6

  • Do you need both? Are the rule sets compliant?

• Outbond rule ANY?

  • Even private IP ranges or IP ranges that don’t belong to you?

• Policy’s vs. Firewall understanding of Inbound and Outbound?

Shadowing refers to the case where all the packets one rule intends to deny (accept) have been accepted (denied)0 by precending rules

A firewall:

• cannot protect against malicious insiders

• cannnot protect against connections that don’t go through it

• connot protect against completely new threats

• connot fully protect against viruses

• does not perform cryptographic operations, e. g. message authentication

• cannot set itself up correctly

A bastion host is a host that is more exposed to the host of an external network than the other hosts of the network it protects.

Purposes:

• packet filtering

• providing proxy services

• a combination of both

• keep it simple

• perpare for the bastion host to be compromised

• connect in such a way that it cannot sniff internal traffic

• extensive and tamper-resistant logging

• disable ssh password login (onyl public key login)

• disable user accounts

• monitor the machine closely (reboots, usage/load patterns, …)

• Regular backups

A packet filtering router or firewall with two interfaces

Dual-Homed: Host is part of two networks (has two NICs)

Bastion Host is Firewall + Application Proxy

Drawbacks:

• Bastion Host is bottleneck

• Compromised (gefährdeter) Bastion Host is worst-case scenario

Pacjet filter protects network and Bastion Host

Bastion Host is Proxy (may be accessible from the Internet)

• Compromised Bastion Host compromises the internal network

Demilitarized Zone (DMZ): perimeter network

HOsts Bastion Host (Proxy) and publicly accessible servers

Second packet filter in case they are compromised - >Protection for the internal network

Requires two firewalls or one firewall with at least 3 NICs

A: simple packet filter architecture

B: Dual- Homed Host Architecture

C: Screened Host Architecture

D: Screend subnet Architecture - DMZ

Most systems have vulnerabilities

• can be known and unknown

• vulns my potentially be used to carry out attacks

Attackers can be detected by being aware of

• unusual or suspicious actions

• unusual or suspicious alterations of stored information

We want to detect:

• Intrusion preambles (probes)

• Intrusion accesses from the outside

• Abusive behaviour from the inside

• compromise of a defined Security Requirement

• manifestation through e.g. unauthorized or abnomral acitvities or data

• Software that has the funciton to detect and identify instrusions

• Not all IDS take countermeasures

• IDS that also take countermeasures are IDPS (Intrusion Detection and Prevention Systems)

Intrusion Detection and Prevention Systems

Honeypot:

• Closely monitored computing resource which is intended to be compromised

• allows for in-depth examination of conducted exploits

• provides early-warning about new attack trends

• Distracts adversariues from more valuable targets

• Can be used as origin for further attacks

• Store signatures of attacks in a database

• Monitor traffic for signatures

• Frequently update signature database

• Model a normal or expected state of a system

• Compare the current state to the model

• Raise alarm if the current state differs more than a certain threshold

Difficulties:

• Diurnal patters:

  • Time of day (few users at night)

  • Day of the week (Few users on weekends)

  • Time of year, Random events

• Long-term patterns

  • Number of users will grow over time

• many applications encrypt their traffic

• plaintext is handled at some point

• Even with end-to-end crypto

• Read communiction data from process memory while in plaintext form

• unauthorized network access

• Reconnaissance (e.g. network scans)

• Abuse of bandwidth resources (e.g. DoS)

• Network protocol violations

  • Improperly formatted packets

  • Spoofing-Attempts

  • Acutal exploit payloads

  • …

• Privilege Abuse

• Accidentally assigned privileges

• Account compromise

• Access and modification of critical data

• Information leakage

Real-time detection:

• Data and control flows are intercepted

• Information processing while target system is running

• Short detection time

• Interferes with system performance

A posteriori:

• Information is logged

• Processing and analysis conducted later

• Longer detection time

• Easily parallelized

Passive:

• only detect and report the results

• Logging and record creation

Active:

• Response mechanism to the attacks

• Close Connections: TCP RST

• Perform system or operational modifications like reconfiguration of routers, firewalls, …

• avoid automated responses -> always a human in the loop

• Reasoning is that false/too strict reactions might cause more damage than the incident that triggered it

• autonomous behavior is difficult to be vertified

Individual:

• only one IDS installed

• Reported incidents are sighted by SOC (Security Operations Center) personnel

• Involves further analysis before system is reconfigured, patched, etc.

Cooperative:

• Several IDSs work in parallel

• Normally involves a SIEM (Security Incident Event Management System) that receives reports from all IDSs

• Data exchanged in standardized formmat

• SIEM can offer added features like prioritizing, filtering and correlation of reported incidents

• Info from different systems ca be quite insightful

• SOC personell sights and further processes incidents

Symmetrc encryption uses shared secret symmetric key k

Assumpitons:

• k is shared between two (Alice and Bob) or more (group) participants

• Besides these participants, nobody else knows k → k is secret

• k is used to encrypt and decrypt → k is symmetric

Condifendiallity -> Yes

Integrity? -> No. an attacker can modify c -> Dec(c) will most probaly yield grabled text -> Receiver can only assume that the message was modified but not prove it

Authenticity? -> No. Attacker could just send some random c and spoof Alice’s IP address

Decryption will yield grabled text. Receiver can only assume that the message is not authentic but not prove it

“The cipher method must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience“

Consequences:

• The cipher, i. e. the encryption algorithm, can be public (should be!)

• if the cipher is public, security depends on the key, which must be kept secret

Benefits:

• If securitly would depend on the cipher’s obscurity and the cipher leaks we would need to build a new one

• You don’t have to come up with a new cipher for each communication partner; selecting a new key is sufficient

• If the cipher does not need to be hidden, we can perform review procedures that increase confidence in the cipher

• AES (block cipher)

• 3DES (block cipher)

• ChaCha20 (stream cipher)

• One-Time-Pad (stream cipher)

Why can we trust them?

• ciphers are published

• they have been publicly reviewed/analyzed by cryptographers

• they are standardized

Do’s:

• do use standardized ciphers from your library

• be aware of the dangers

  • unlikely: cipher is broken or backdoored

  • likely: Wrong usage of the cipher compromises security (conjunction with other crypto’s)

Don’ts:

• Don’t implement your own cipher

• Don’t claim “it’s encrypted, it is secure”

  • Encyption != Security

• Key management is difficult and highly important and shouldn’t be neglected (vernachlässigt)

Goal: given c, learn something about m and/or k

If something about k can be learned the attack is already successful

• We can repeat the attack and learn more about k

• Knowing a couple of bits of k might allow us to brute-force the rest

Ciphertext-only-attack:

• Attacker only knows c and tries to learn something about m or k

• weakest attak type

• E.g. try to guess k, statistical attacks, …

Known-plaintext attack:

• The attacker knows a ciphertext/plaintext pair (m, c) and tries to learn something about k

• attack on other ciphertexts

Chosen-plaintext or chosen-ciphertext attack:

• Requires that there is some service which knows k and can be exploited by the attacker

• Attacker sends chosen plaintext or chosen ciphertext to oracle

• Attacker evaluates oracle’s response and tries to learn something about m or k

• Strongest attack type

A cipher is secure if the best known attack is brute-forcing all keys

128 Bit -> 2^128 tries

exhaustively testing all keys by decrypting c with the k-candidate;

We assume to have found the “right” key when decryption result “looks reasonable“

Assumes: shared symmetric k of fixed length

Block cipher:

• Encrypts and decrypts inputs of length n to outputs of length n

• block length n

Stream Ciphers:

• Generattes a random bit stream, called key stream

AES:

• Fast 200 MBit/s in software and > 2 GB/s with Intel AES-NI

• Hardware implementations for embedded devices available

• Secure

• AES seems to be the best we have, and it is among the most researched algorithms

Modes of Encryption

• Electronic Code Book Mode – ECB

• Cipher Block Chaining Mode – CBC

• Output Feedback Mode – OFB

• Counter Mode – CTR

Drawbacks:

• Ciphertext blocks do not have any connection with each other

• For this reason, an attacker can…

  • reoreder blocks

  • repeat blocks

  • delete blcoks

• Ciphertext can even be decrypted, possibly to reasonable plaintext

Encryption

Decryption:

IV = Initialization vector:

IV must not be kept secret, cause security depends on k

IV must be fresh, cause Identical plaintext messages are encrypted to non-identical ciphertexts as plaintext is “masked“ with IV or previous ciphertext blocks -> huge benefit

Drawbacks and Benefits:

• Identicalk plaintext blocks are encrypted to non identical ciphertext -> huge benefit

• Decrypting a blcok depends on the previous block’s ciphertext. In case of a transmission error in cipohertext block ci the decryption of ci+1 yields grabled data -> Drawback, however we can deal with transmission erros -> TCP

• For same reason, reordering, repeating or deleting ciphertext blocks typically causes that decryption results in grabled data -> seems like advantage, but CBC encryption does not provide integrity protection

Encryption:

Decryption:

• Transforms a block cipher into a stream cipher

• IV may be public but must be fresh.

Pros:

• Decryption does not depend on previous blocks. A transmission error in ciphertext block ci only affects decryption of this block

• Reoredering, repeating or deleting of ciphertext blocks impossible due to feedback

Encryption:

Decryption:

• Transforms a block cipher into a stream cipher.

• IV may be public but must be fresh

Pros and Cons:

• Decryption does not depend on previaous blocks A transmission error in ciphertext block ci only affects decryption of this block

• Reordering, repeating or deleting of cipher text blocks impossible due to counter

• If n is too small, the key stream repeats itself -> Use new IV for a fresh key stream

A function h is called a has function if:

• Compression: h maps an input x of arbitraty length to an output h(x) of fixed length n:

  • h:{0,1}* -> {0,1}^n

  • Ease of computation: Given h and x it is easy to compute h(x)

    
    

A function h is called one-way-function if:

• h is a hash function

• For all pre-specified outputs y it is computationally infeasible to find an x with h(x) = y

• "For any hash value y, I cannot efficiently find any input x which has this hash value."

1. 1st pre-impage resistance:

   • H is a one way function

2. 2nd pre-impage resistance

   • Given x it is computationally infeasible to find any second input x’ with x != x’ that H(x) = H(x’)

   • “Given a message x, Icannot efficiently find a different message x’ which has the same hash value“

3. Collision restistance

   • It is computationally infeasible to find any pair (x, x’) with x != x’ such that H(x) = H(x’)

   • “I cannot efficiently find a pair of different input calues x and x’ that have the same hash value“

4. Random oracle property

   • It is computationally infeasible to distinguish H(x) from a random n-bit value

• No, Appliying (only) a hash function is not sufficient to secure a message against intentional manipulation: hash functions are public and the attacker knows m

Mesage authenticaiton Code:

• mutal authentication can be achieved by a 2nd exchange in opposite directions

• Another type of challenge response is, if BOb signs the challenge “rA” with his private key

• Note: The challenge response protocol would allow chosen-message attacks that might allow an attacker to learn about k

Secure Hash Algorithm 2 (ShA-2):

• invented by NSA

• The SHA-2 family consists of six hash functions with digests (hash values)

• current NIST standard

Secure Hash Algorithm 3 (ShA-3):

• current NIST standard, alternative to SHA-2

No!

Message Authentication Code

• MACs include a secret key K in addition to the message m they aim to protect

  • Only the persons with knowledge of K can (re-) compute the MAC

• Do prove message integrity

• do detect tampering (manipulation)

• cannot be forged

• can be replayed (for same m)

Depends on scenario:

• If k is shared between Alice and Bob, Alice (Bob) knows that Bob (Alice) must have computed MACk(m); comparable to challenge/response authentication

• If k is a shared group key used by Alice, Bob, Cesar, …; Alice knows that MACk(m) was computed by a group member but not by which one

• Also an external observer cannot validate MACk(m) as k is unknown

• Added redundancy (error detection code ~ check value) defends against errors on the wire

• Cannot defend against intended attacks as attacker can change m to m’ and also “fix“ error detection code

Families of MAC constructions:

• based on cryptographic hash functions: HMAC

• based on block ciphers: CBC-MAC/CMAC

Reasons for constructing MACs from cryptographic hash functions:

• Cryptographic hash functions generally execute faster than symmetric block ciphers

Basic idea of Hash-based MACs:

• “mix“ a secret key K with the input and cumpute a hash value

• Hash MAC (HMAC)

• Cipher Block Chaining MAC (CBC-MAC)

• Cipher based MAC (CMAC)

• Poly1305

• length of the key K is first extended to the block length required for the input of the hash function H by appending zero bytes

• Then it is xor’ed respectively with two constants opad and ipad

• The hash function is applied twice in a nested way

• Currently no attacks have been discovered on this MAC function

CBC-MAC is computed by encrypting a message in CBC Mode and taking the last ciphertext block or a part of it as the MAC:

• This MAC need not to be mixed with a secret any further, as it has already been produced using a shared secret K

• This shceme works with any block cipher

• It is used, e.g. WLAN, many modes in SSL/IPSec

• CBC-MAC must NOT be used with the same key as for the encryption

• if CBC mode is used for encryption and CBC-MAC for authenticity with the same key, the MAC will be equal to the last cipher text block

• If the length of a message is unknown or no other protection exists, CBC-MAC can be prone to length extension attacks CMAC resolves the issue

public fixed IV:

• The IV is often part of the packet header and not protected

• An attacker that exploits this vulnerarability could then modify m1 to m1’ without changing cn (the MAC)

• The attacker only needs to modify IV and use IV’ so that m1’ + IV’ = IV +m1

• Older symmetric block ciphers require more somputing effort than dedicated cryptographic hash functions

• However newer symmetric block ciphers (AES) is faster than conventional cryptographic hash functions

  -> AES-CBC-MAC is becoming popular

• Compute k1 and k2 from shared key k

• Within the CBC processing

  • XOR complete blocks before encryption with k1

  • XOR incomplete blocks before encryption with k2

  • k is used for the block encryption

• Output is the last encrypted block or the most significant bits of the last block

• Challenges (nonces) used in challenge-response protocols

• Initialization vector (IV) for block cipher modes of operation (CBC, OTF, CTR)

• Secret keys for symmetric ciphers

• Secret keys for MACs

• Generation of asymmetric keys used by SSH

• Session keys in cookies to identify web sessions

• …

• “Randomess“ can be described by unpredictability and unpredictability is good for security

• A measure for “unpredictability“ is “entropy”

• Let X be a random variable which outputs a sequence of n bits

• Entropy is maximized for a uniform distribution

  -> truely random

Hardware-based:

• radioactive decay

• thermal noise from a semiconductor diode

• frequenncy instability of a free running oscillator

• lava lamps

• noise of microphone or camera

Software-based:

• user input (mouse movement, keystrokes)

• OS stats (CPU load, network)

• Content of buffers

Attackers must not be able to guess/influence the collected values

• getting entropy is expensive

• Deterministic algorithm

• Input: small amout of initial entropy, ideally from a hardware RNG

• Output: Sequence of random-looking numbers calculated using the seed as input

• Advantage: “cheap“ randomness

• disadvantage mostly predictable to a certain point

• The length of the seed should be large enough to make brute-force search over all seeds infeasible

• output should be indistinguishable from truly random sequences

  • No polynomial-time algorithm can correctly distinguish between an output sequence of the generator and a truly random sequence

• The output should be unpredictable for an attacker with limited resources, without knowledge of the seed

• Introduced ciphers and authentication mechanisms require a common, pre-shared, secret key

• Out-of-band sharing is not always an option

• Key exchange needs to be conducted securely

• Symmetric machnaisms require a considerable amount of keys in the system:

Assume n parties, only unique keys and symmetric crypto:

• Every party needs to keep n-1 keys secret

• One symmetric key for every pair in the system

• Amount of secret keys in the system: n(n-1)

Assume n parties only unique keys and asymmetric crypto:

• Every party has a public and private key

• every party keeps their own provate key secret

• every party publishes their public key

• Amount of scret keys in the system n

• Benefits of asysmmetric encryption encryption mechanisms include:

  • Number of keys needed in a communication system is reduced

  • Public keys are not required to be exchanged between participants of the communication systems via a secure channel that guarantees confidentiality of the key

• But integrity and authenticity cannot be guaranteed

Now assume p,q to be two distinct prime numbers and n = p * q

-> Φ(n) = (p − 1) · (q − 1)

1. Randomly choose distinct, large primes p,q

   • Large primes -> hunderds of bits

2. Compute:

   • n = p * q

   • Φ(n) = (p − 1) · (q − 1)

3. Pick e such that:

   • 1 < e < Φ(n)

   • e relatively prime to Φ(n)

4. Find d using the Euclidean Algorithm such that:

   • e · d ≡ 1 mod Φ(n)

   • d is the multiplicative inverse of e modulo Φ(n)

Security of the scheme based on hardness of prime factorizing n in p and q which allows to compute Φ(n) and subsequently the private exponent d

Encryption:

• m is an integer that represents our message

• m is to be encrypted to a ciphertext c

• 0 < m < n

Decryption:

(Only for understanding)

• Pure Textbook RSA is deterministic

• same inputs correspond to same outputs

• Chosen- plaintext Attack scenario:

• What if m = 0? -> c = 0

• What if m^e < n?

Solutions:

• Employ Padding (“enlarges m“)

• Add random bits (“adds non-determinism“, “avoids 0“)

• Schemes PKCS, OAEP

(only for understaning)

• Very expensive

• Orders of magnitude slower than symmetric crypto or hashing

• Unsuitable to encrypt larger amounts of data

Idea:

• Hybrid Encryption Scheme

• Use public key cryptography to securely exchange (ephemeral) symmetric key

• Use symmetric cryptography to encrypt the actual payload data

• A key agreement protocol is used to establish a shared key

• Authenticate the entities

• Provide additional communication protection

• Diffie-Hellman key exchange protocol

• the Dieffie-Hellman coinstruction contains weak values e.g. a = 0 b = 0

• certain combinations of g and p

• There is also Dieffie_hellman based on elliptic Curves called ECDH

• the protocol only protects against passive attacks

• there can be an acive Man/Machine in the MIddle, that performs two DH key exchanges -> is able to decrypt and re-encrypt and forward messages to Bob and alice

• Importatnt: integrity and authenticity of DH key exchange messages must be protected with digital signature -> This is called Authenticated DH

Alice sends messages to Bob, messages are encrypted with a session key, attacker eavesdrops all messages (including key exchange-related ones) and saves them for later (ab)use..

Scenario 1:

Each session key is picked by Alice and sent to Bob encrypted with Bob’s public key.

(Old session keys are deleted.)

• If the attacker gets access to Bob’s private key (long-term key), ...

• ... they can decrypt saved old and new key exchange messages and ...

• ... they can decrypt saved old and new messages using the obtained session keys!

Scenario 2:(Perfect forward Secrecy)

For every new session a new session key is agreed on using authenticated Diffie-Hellman.

(Old session keys and DH parameters are deleted.)

• If the attacker gets access to Bob’s private key (long-term key), ...

• ... they cannot compute old session keys (and decrypt messages) as the security of session keys does

not depend on the long-term key but on the DH problem!

• (But: an active attacker can impersonate Bob in future runs of the authenticated DH key exchange

protocol!)

• Long-Term Data Security ("Store now, decrypt later - attack")

  • An attacker who has harvested data can now decrypt it.

  • Company and state secrets, medical data, etc., are often "interesting" for an attacker for a very long time!

  • Instead: Use PQC sooner rather than later to mitigate this attack!

• Public key infrastructures and similar structures (DNSSEC, BGPSec, ...)

  • Current PKI and similar structures have become insecure. We must replace them with new ones.

  • How can we establish a new PKI without being able to authenticate the new PQC PKI’s certificate?

  • Instead: use current structures and their update mechanisms to transition to PQC keys, e.g.

    - PQC Root CAs are introduced by major browser manufacturers via the "root store" - mechanism

    - PQC Intermediate CAs can be authenticated by PQC Root CAs and other PQC Intermediate CAs.

• Competition

  • Your product becomes useless as it is insecure. Nobody buys it anymore.

  • Instead: Upgrade and use cryptography to manufacture a future-proof produc

• Global coordination and standardization

• Interoperability between old and new systems

• Performance considerations

• Impact on Computer Networks

• Training and upskilling of professionals

• Identified challenges with classical public key cryptography

  • What if the Ksec key gets compromised?

  • What if the node that stores Ksec is not available or gets destroyed?

  • What if we need more than one entity to sign, think "distributed system"?

• Threshold signature ensures Ksec confidentiality

• Allows for better availability and distribution of power among involved parties

Variety of interesting use-cases:

• Cryptographic wallets – both custodial and private wallets

• Public key infrastructure (PKI), e.g. to protect the private key of a certificate authority (CA)

• Byzantine Fault Tolerant (BFT) protocols

• …

1. Key generation (Setup)

   • Trusted setup – relies on (centralized) trusted 3rd party

   • Untrusted setup – Distributed Key Generation (DKG)

2. Signing

   • Is always distributed

   • Varies for different threshold signing schemes – ECC based or RSA based

   • Deterministic signature e.g., BLS [1] are easier to implement than non-deterministic schemes e.g., ECDSA [2]

   • Challenges with non-deterministic schemes comes due to generation of random nonces

3. Verification

   • Nothing changes compared to classic public key cryptography, i.e.:

   • The entities that posess the public key of the distributed crypto system can verify its threshold signatures

(For understanding)

A:

• Confidentiality, Integrity, Authenticity

• Messages received in correct order

• No duplicates/replayed messages (Bonus: we know which messages are missing)

B:

• Virual private network protocols (VPN), like OpenVPN, IPSec, Wireguard

• Transport layer security protocols like TLS, DTLS

• Secure messenger applications like Signal

• Using a symmetric cipher and a MAC algorithm

• We have several options to construct possible protocol designs that differ in the order of applicaiton of MAC and encryption algorithms

Note:

• Security differs between the options

• We are using different keys for encryption and integrity protection: k -int and k -enc

• k -int and k -enc can be derived from a session key k using a key derivation function (KDF)

• “We first create the MAC of m, then we encrypt m and the MAC together“ (Encryption does not provide any message authenticity/integrity)

  
  

• Attacker can modify c to c2

• Receiver decrypts c2 to m2 and MAC2

• Verifying the integrity of m2 with MAC2 will fail

• Was used by the TLS precursor SSL

• Many SSL attacks are/were a result of this scheme

• “We independently encrypt m and compute a MAC of m“

• Not better than MAC-then-Enc

• Can be attacked when MAC is weak

• Scheme is considered the weakest of our three options

• Used by (at least) old SSH version

• “We first encrypt m, then we compute a MAC over the ciphertext c“

• Considered secure

• Integrity of ciphertext is verified before decryption

• Allows to discard messages where the verification failed (non-authentic messages)

  • Don’t process non-authentic data

  • Don’t waste CPU power

• Used by IPSec, SIgnal, TLS

• Currently considered the stronges of our options

• Message numbering

• Encryption

• Authentication

• n ∈ N

• Increased monotonically for each valid message

• n must be unique for every message

• Remember last message n(last) and only accept n > n(last)

• Detect replay attacks

• Guarentee correct order of messages

• Detect lost messages

• Number overflow -> rekeying

  Otherwise replay attacks would be possible

• Runtime of equality test of two strings differs

• Longs runtime for equal strings

• Shorter runtime for different strings (function returns after first different byte!)

• Different runtimes can be attack vector for timing/side channel attacks!

• (See padding oracle attack)

Solution:

• Ensure that runtime of equality test of two strings is the same for identical and different strings

• E.g. byte-wise XOR of both strings; results in 00..00 when strings are identical

1)

• One pass encrytion and MAC calculation for payload including “associated data“

2)

• Addidional non-encrypted but authenticated (header) data

• e. G. IV, sequencenumber, …

3)

• Security: AEAD algorithms correctly combine message encryption and authentication and are standardized; errors by inexperienced programmers can be avoided

• Performance: AEAD algorithms only need one pass over the data

Examples:

• Galois/Counter Mode (GCM)

• Offset Codebook Mode (OCB)

• Encryption (selection of the right cipher and mode of operation)

• Integrity protection/authentication (selection of the right MAC construction)

• Using the crypto primitives in the right order

possible problems:

• Design and/or implementation errors

• Performance (toy example, data first as plaintext, then the ciphertext had to be processed, better would be a on pass solution)

Authenticated Encryption with associated Data (AEAD)

• contains a finite number of elements -> finite field

• Multiplication and summation of elements of a Galois field results in an element of the same field

• GF(2^4) cpmtaoms 1011 that can be interpreted as the polinomial x^3 + x +1

• Coefficients of the polynomial can only be 0 and 1

Example:

• Stream cipher

• Padding oracle

• if the IV- vector is reused for a second encryption like:

->

• Attacker can compute P1 and P2, threw C1 and C2

• Statistical properties of plaintext can be used if plaintext is not-random looking. That means if entropy of P1+P2 is low

• Operation

  • P and MAC are encrypted and hidden in the ciphertext

  • Receiver first, Decrypts P then decrypts MAC and then computes and checks MAC

• Consequence

  • MAC does not protect the ciphertext

  • Integrity check can only be done once everthing is decrypted

  • As a consequence, receiver will detect malicious messages at the end of the secure channel processing and not earlier

• if we use blockcipher, we have to ensure that the message encoding fits to the blocksize of the cipher

• Therefore we need to add a padding (see slide)

• Orales are functions that give cheap access to information that would otherwise be hard to compute

• In cryptography, an attacker can trigger some participant O in a protocol or communication to leak infomation that might or might not be useful

• e.G.

• A general class of attacks where the attacker gains information from aspects of the physical implementation of a cryptosystem

• Can be based on: Timing, Power Consumption, Radiation,…

• The oracle tells the attacker if the padding in the message was correct

• This may be due to a message with the infromation

• It can also be due side challel like response time

• Attacker sees unknown ciphertext C =

that was sent from Alice to Bob

• To decrypt the ciphertext, the attacker modifies C and sends it to Bob

• It is unlikely that the MAC and padding are correct. So, Bob will send an error back to Alice (and the attacker)

• In earlier versions of TLS, Bob sent back different error messages for padding errors and for MAC errors

• Using CBC with Encode-then-Encrypt-then-MAC

  • cause MAC check would fail first, process would be aborted and padding problems would then not be leaked

• Advantage of asymmetric crypto: Public keys are not required to be kept secret

• This allows users to distribute public keys via arbitrary channels e.g.

  • Alice retrieves Bob’s public key from a mail sent to Bob

  • Bob downloads Alice’s public key from her web site

• Problem:

  • Who ever utilizes another entities public key must be sure that this public key really belongs to this entity -> is authentic -> can be trusted

    
    

• Manual trust establishment: Alice and Bob exchange their keys via some Method

  • Then they validate, if they have received the correct keys in a secure manner

  • Extra cautious persons will also identify each other using a official ID document

  • Authenticity of a received key can be verified by comparing the key’s fingerprint

  • High effort

• Usa a PKI instead (simplified, generic data):

  • “Notary“ verifies the identity of the entity who owns a public/private key pair

  • Notary creates data structure that binds the public key to the identity of the entity

  • Notary signs this data structure that binds the public key to make it verifiable -> certificate

  • Who ever wants to use the cert and trusts the notaries assertions and can verify her signatures can trust the public key contained in the certificate

A certificate is adigitally signed binding of an identifier of an entity and the public key of an asymmetric key pair owned by that entity

• The identifier often refers to a person, business While much less common the identifier may also indicate some attribute with which the key is associated

• Always necessary: Verification that identifier and corresponding key belong together

• If the identifier is a name: verify that the entity behind the name is the entity it claims to be

• by issuing certificates between entities

• Who are the issuers?

• Which issuers must be trusted = which TTPs exist?

Exkurs terminologhy:

• issuer -> can have different words

• in hierarchical PKIs: “Certification Authority“ (CA)

• non-hierarchical PKIs: “Endorser“

• hint for the role/power of the issuer

Registration Authorities (RAs):

• operating systems and software like browsers come pre-configured with a set of trusted CAs

Web of trust

• X.509 is a ITU standard that defines the format of public key certificates

Root stores: contains certificates of trusted Root CAs

• Root certificates are “self-signed“

• Every application that uses X.509 has to have a root store, i.e. a set of certificates of "trusted" CA (trusted to issue certificates to the correct entities)

• Operating Systems have root stores: Windows, Apple, Linux

• Browsers use root stores: Mozilla ships their own, IE uses Windows’ root store, etc.

Intermediate certs: part of a certificate chain, but neither a root certificate nor an end-entity certificate.

Sub-CA/intermediate certs have the same signing authority as Root CA/root certs:

• Example: Russian Sub-CA might sign certificate of Ukrainian web site

• DNS restrictions (name spaces a CA is responsible for/allowed to sign) are in the standard

• The restriction must be supported on client-side

• This feature is little used

SSL proxies

• SSL proxies allow the transparent rewriting of certificate chains – a classic Man-in-the middle attack

• Using SSL proxies, end-to-end protected traffic can be monitored

• Used by companies in order to avert industrial espionage, etc. (but also by state level attackers)

• Worst: the holder of the sub-CA is suddenly as powerful as all CAs in the root store

• Since outing of first such CA, Mozilla requires practice to be disclosed, and stopped

Cross Signing: A (Sub-)CA signs a root or signing certificate of another (Sub-)CA

• A special case of intermediate cert

• Cross signing is able to subvert control of the root store vendor:

  • Example: Entrust (US CA) has signed CNNIC (Chinese CA) long before CNNIC became part of the root store in Mozilla

  • CNNIC-issued certificates suddenly became valid

  • For the WWW, it completely breaks the root store model

• In a business-to-business model, this makes sense:

  • Two businesses wishing to cooperate cross-sign each other

  • Makes it easy to design business processes that access each others’ resources via SSL/TLS

• Your browser or your OS chooses the ‘trusted CAs’. Not you.

• All CAs have equal signing authority (there are efforts to change this)

• Any CA may issue a certificate for any domain.

• DNS path restrictions are a possibility; must be set by the CA in their signing cert

• A globally operating CA cannot feasibly set such restrictions in their root cert

The weakest CA determines the strength of the whole PKI. This is also true if the CA is a sub CA

• Domain Validation (DV): proves ownership of the domain:

  • Publish a CA-specified nonce in a DNS TXT record

  • Publish a CA-specified nonce on the web server

  • CA sends mail to mail address specified in domain’s whois info; respond to this mail

  • CA sends mail to "protected" mail address (admin@...); respond to this mail

  • Note: Let’s Encrypt issues DV certificates

  • Not checked: Does a Domain Name/WebSite and Company “fit toghether“

• Extended Validation (EV):

  • Additionally requires (strong) legal documentation of the claimed identity

• Organizational Validation (rare):

  • Between DV and EV; less documentation

Standard approach of domain validation:

• Generate RSA key

• Generate Certificate Signing Request (CSR)

• Log into the CA’s awesome web interface

• Fill out the ordering form, upload CSR

• Verify domain with one of many vendor-specific verification methods (Mail to ca-admin@domain, http- Textfile, TXT DNS record, ...)

• Pay some sum of money

• Receive and install the certificate

• to certify a server automatically -> no need to repeat the checking for security manually -> save money

• JSON protocol for unsupervised certificate issuance

• Step 0: ACME Client creates an “account key” (asymmetric cryptography key pair)

  • Can now send signed messages with JSON Web Signature (JWS) (RFC7515

  • Required to register account: [ToS Agreement, contact info] signed with client privkey

  • Account key can be used for multiple domains

• Step 1: Authorize account key for domain

• Step 2: Request server certificate for this domain

Revocation is crucial—yet often neglected in discussions

• Problem: Certificates typically have a specified lifetime; X.509: Not Before / Not After fields

• We need confirmation that a certificate is valid at the moment of interest, not some time in the past

• There are several cases when an already issued certificate must be withdrawn. Examples:

  • Corresponding private key compromised/lost

  • Certificate owner does not operate service any longer

  • Key ownership has changed

• No certificate can be considered valid without a revocation check

• Two options: CRLs and OCSP

A CRL is a list of certificates that are considered revoked

• They are (should be) issued, updated and maintained by every CA

  • Certificates are identified by serial number

  • A reason for revocation can be given

  • Every CRL must be timestamped and signed

• There are further entries, like time of next update

• Technically, a browser (client) should download CRL (and update it after the given time), and lookup a host certificate every time it connects to a server

CRLs have a number of problems

• Intermediate certs should be checked, too – induces load and network activity

• There is a time interval between two updates (window for attack)

• CRLs can grow large

  • Response to this: Delta CRLs that contain only latest updates

  • Requires server side support—very rarely used

• Downloads of CRLs can be blocked by a Man-in-the-middle

• For these reasons, browsers have never activated CRLs by default

OCSP allows live revocation checks over the network

• Query-response model

• Query = lookup of a certificate in a server-side CRL-like data structure

  • Query by several hash values and cert’s serial number

  • Replay protection with nonces

  • Query may be signed

  • Does not require encryption

• Response:

  • Contains cert status: good, revoked, unknown

  • Must be signed

There are a number of issues with OCSP:

• Lookups go over the network – induces latency

• OCSP information must be fresh. Not just from CRLs.

• OCSP servers must have high availability

• OCSP can be blocked by a Man-in-the-middle—many browser will ‘soft-fail’ = show no error

• Privacy! OCSP servers know which sites users access

• Browsers ‘accept as good’ if no OCSP response received

• “[OCSP was] designed as a fully bug-compatible stand-in for CRLs” – P. Gutmann

• In-browser revocation lists:

  • Browsers pre-load a list of revoked certificates for the most common and important domains

  • Updates are distributed via the browser’s update mechanism

  • This counters the devastating attacks where traffic to the CA is dropped—but the scalability is not good

• Short-lived certificates

  • Give certificates a very short validity period (1 hour–1 day)

  • Replace certificates fast, do not attempt any other revocation

  • Works well and gives very clearly defined window of attack

  • Problem: certification becomes a frequent and ‘live’ operation—shunned so far for the Web

Revocation is crucial—but no silver bullet so far

• It is probably safe to say that CRLs never worked and are of very limited use

• OCSP checks are expensive, too (latency, load)—and not sufficient against an attacker who drops traffic to the CA

• OCSP stapling is an improvement

• Revocation is an unsolved problem

Addresses several problems of OCSP

• The idea is thus that servers request fresh OCSP ‘proof’ from CA: ‘this certificate is still considered valid’

• This can be done at regular intervals

• The ‘proof’ is ‘stapled’ to the certificate that the server sends in the SSL/TLS handshake

• Although around for a long time, the idea is only now gaining traction

• Reduces load on CA, reduces overall web page loading time, solves privacy problem

Aim: defend against malicious certs

• Idea: browser "pins" the certificate a Web server presented on first contact

• Can be achieved by storing the public key or hash of the public key

• If the server later presents a different certificate, the browser can warn the user or stop the connection attempt

This type of user-driven pinning assumes a secure first connection

• Inherent bootstrapping problem: who can guarantee the cert’s authentifity on first use?

• Browser might pin the malicious certificate...!

Variants:

1. Thus also known as trust-on-first-use ("TOFU")

2. Static pinning

   • User-driven pinning: as discussed on the previous slide; normally realized as add-on for browsers

   • Pre-loaded pins: Google Chrome, Mozilla Firefox store a smallish number of "Pins" of the most important Web sites

3. Dynamic pinning

   • Idea: the browser dynamically requests Pins from other entities (e.g. other browsers, central database, etc.)

   • Normally realized as add-on for browsers

TOFU problem:

• Problematic in countries that spy on their people

• Browser cannot know if the certificate is authentic

Life-cycle problem

• Servers may (legitimately) update/upgrade their keys

• Browser cannot know if the presented certificate is malicious or just a new one

Scalability problem

• Browsers cannot come pre-loaded with pins of all sites, and keep them up to date

The attacker is the network, i.e., they can eavesdrop, intercept, replay, ... messages.

• The attacker might try to trick participants into communicating with them.

• The cryptographic primitives are secure.

• The nodes that participate in the cryptographic protocol are secure.

When we try to break a protocol, we do this on the layers of the cryptographic protocol.

When we try to mitigate a vulnerability, we do this on the layers of the cryptographic protocol

Participants of cryptographic protocols include:

• Entities that are normal participants of the protocol. We call them Alice (A), Bob (B), . . .

• Special-purpose entities that have a special role, like an Authentication Server (AS), . . .

• Synonyms for participant: principal, entity, . . .

Further roles:

• Initiator: The principal that starts the protocol by sending the first message.

• Responder(s): The principal/the principals that did not start the protocol.

this attempt fail:

• The password is sent in clear text → Now it can be used by everyone.

• The password does not protect the authenticity of the DH parameters

• → Man-in-the-middle still possible

Entity Authentication

• An authentication protocol is run and in the end, participants are ensured of the identity of other participants.

  • Types:

    • Authenticity of one entity is shown

    • Authenticity of both entities is shown: mutual authentication

Key Establishment

• An key establishment protocol is run and in the end, participants have a session key only they know.

  • Types:

    • Key Transport/Key Encapsulation: Some entity creates the key and sends it to other entities.

    • Key Agreement: Multiple entities contribute to the generation of the key.

Note:

• In practice, Entity Authentication and Key Establishment are often closely intertwined

• Entity Authentication is often realized as authenticating key exchange (and other) parameter

• The reasons why protocols "Try 1" (Textbook DH) and "Try 2" (DH + password) failed were, that after a protocol run, neither Alice nor Bob know with whom they actually have exchanged a key and the exchanged key was not authenticated!

• In general, key establishment without entity and message authentication is not a good idea

Example use case: Authorization

• Authentication is the basis for authorization. In some cases no session key is needed.

• Example: Modern buildings use cryptographic dongles to unlock doors.

  No session key is needed for further actions.

Step 1: Authentication of the web server of the bank

• Web browser verifies the identity of the web server via HTTPS using asymmetric encryption and X.509 certificates

• A shared session key KA ,B is generated as part of the server authentication

• A secure channel between web browser and web server is established

Step 2: Authentication of the client/user:

• Uses the secure channel to the web server

• The web server authenticates Alice based on her account Nr./user name and PIN/password

• No additional secret key is established

Note:

• TLS (HTTPS) can be configured to do mutual authentication. However in this case also the client needs a certificate, which is for most use cases too expensive.

Another possible replay attack:

Solution for replay Attacks:

• Modification: Attacker alters messages sent.

• Preplay: The attacker takes part in a protocol run prior to a protocol run.

• Denial of Service: The attacker hinders legitimate principals to complete the protocol.

• Certificate Manipulation: Attacks using manipulated or wrongly-obtained certificates.

• Reflection: Related to Oracle attacks. The attacker sends back protocol messages to principals who sent them.

• The Needham-Schroeder Protocol is a protocol for mutual authentication and key establishment

• It aims to establish a session key between two users (or a user and an application server, e.g. email server) over an insecure network

Ticket Reuse Issues and Forward Secrecy

Client Certificate Authentication

• 0-RTT (Round-Trip-Time)

  • LS1.2 required another RTT on top of TCP setup before sending data

  • This negatively affected user experience

  • TLS1.3 offers 0-RTT connections for known hosts

• Removal of static key use

  • TLS1.3 aimed to remove static key use to enforce Perfect Forward Secrecy (PFS)

  • Pushback from network monitoring community

  • Highly controversial