Title: Test 1

Front: Authenticity
Back: Users really are who they claim to be

Front: Integrity
Back: Messages are not tampered with

Front: Availability
Back: Services are available for normal usage/users
Data is accessible

Front: Confidentiality
Back: Messages are not leaked to third party

Front: Nonrepudiation
Back: Actions cannot be hidden/removed after they have been done
Cannot deny responsibility

Front: Accountability
Back: Any operation can be traced back to a individual

Front: CVE
Back: Common Vulnerability Exposures
Websites that list and categorize common threats found in software
Agencies are CNAs

Front: CVSS
Back: Common Vulnerability Severity Score
CVE are often subjective (depend on policies, some software not governable). Scoring system allows for measuring “uniformly” how bad it really is
4 levels

Front: Security Principles
Back: - Simplicity
- Open Design = Open Source is more sEcUrE because everyone can check
- Compartmentalization = Split system into isolated parts. if one is compromised the others still work
- Minimum Exposure = allow access only to those resources that are needed, nothing more. Reduce external interfaces
- Least priviliges = give each user only the permissions they need
- Minimum Trust = don’t trust input, minimize expectations about system
- Maximum Trustworthyness = try to check as best as possible, validate assumptions, prove system acts like it should
- Use Fail-Safe Defaults = system starts and terminates in a secure state
- Complete Mediation = monitor/control access to relevant ressources (access control)
- Defense in Depth = use multiple defenses, attacks come from multiple vectors
- Traceability = be able to understand actions in the system, logging is important
- Generate Secure Secrets = maximize (shannon) entropy
- Usability = keep system usable while maintaining security (tradeoff)

Front: Attacks in Classical Encryption
Back: - Bruteforce
- Probabilistic lookup (letter occurence)
- heuristic optimization methods

Front: Perfect Secrecy
Back: cypertext doesn’t reveal any information about plaintext
\(P(M = m \mid C = c) = P(M = m)\) P ( M = m ∣ C = c) = P ( M = m)﻿ …whatever that means

Front: One-Time-Pad
Back: Message xor key = ciphertext
ciphertext xor key = message
perfect secrecy but key can only be used once

Front: One-Time-Pad Issues
Back: If key is reused: c1 = Enc(k1, m1), c2 = Enc(k2, m2) ⇒ c1 xor c2 = m1 xor m2
⇒ m1 = c1 xor c2 xor m2

Front: Malleability
Back: The ability to change the ciphertext such that it decripts to a message bearing some information about the original message
homomorphic schemes

Front: Stream Cipher
Back: - generate pseudorandom bitstream using key
- xor stream with message
- synchronous = next state depends only on current
- self-synchronizing = next state depends on current state and prev plain/ciphertexts

Front: Stream Cipher vulnerabilities
Back: - malleability
- if you can guess next PRG output + part of plaintext known ⇒ whole stream is compromized

Front: Block Cipher
Back: - split message into blocks
- last block is padded (if < blocksize)
- mode determines security
- often multiple rounds for increased sEcUrIty

Front: AES
Back: for each round:
- AddRoundKey = xor bits with subkey matrix (key is derived some way beforehand)
- SubBytes = substitute every byte using some lookup table
- ShiftRows = shift each row by its index (every column contains one bit from each row)
- MixColumns = multiply each column with some fixed matrix
Confidentiality: ECB, CBC, CTR, …
Integrity, Authenticity, Confidentiality: GCM, CCM, EAX

Front: Operation Mode Properties
Back: - Parallelization = how fast can we encrypt/decrypt
- Error Propagation = how do bit flips affect ciphertext
- Random read access = can we decrypt one block without decrypting the whole ciphertext

Front: ECB Mode
Back: - each block is encrypted individually
- bad if meassage > block size
- keep traces of original message
- strong malleability: peace together prev blocks of prev observed ciphertexts
- parallel
- bit flip only affects its own block

Front: CBC Mode
Back: - xor message with enc output (first step xor with InitVector ⇒ introduces non-determinism)
- not parallelizable in encryption
- parallel and random read in decryption possible (xor after enc so each ciphertext block can be decrypted simultaneously)
- non-deterministic

Front: CTR Mode
Back: - stream cipher mode
- use RANDOM nonce + counter for encryption
- xor output with message
- nonce must be securely transmitted
- parallelizable
- bit flip in ciphertext ⇒ same position in plaintext

Front: Padding
Back: add to end of last block number of missing bytes
if last block is full add empty block and pad with block size

Front: Hash functions
Back: - one way function
- infeasible to trace output back to input
- no collisions (different input = same output) wanted
- usually some modulus operation

Front: Hash Propertie
Back: - One-way
- Uniformity: no specific distribution about mapping
- Diffusion: non-deterministic mapping (input bit affect as much output as possible)
- Collision resistance

Front: MAC
Back: - add code to message that verifies authenticity
- keys need to be securely transmitted

Front: Problem with regular MAC

Front: CBCMAC
Back: Block Cipher CBC mode
MAC is output of last Enc
fixed length messages only

Front: CBC MAC Attack
Back: - use variable length messages both of which are known to attacker
- MACS are also known
- append message blocks ⇒ equal to MAC
solution
- encrypted MACs
- work for var length too
- encrypt output again with other key

Front: HMAC
Back: - key xor with some byte sequences
- append to message
- hash
- append
- hash

Front: Authenticated Encryption
Back: - Encrypt then MAC: use different keys but works for any combination of algorithms
- MAC then Encrypt: MAC based on plaintext, only for CBC or CTR mode ⇒ or padding-oracle attack
- Encrypt and MAC: also not secure for stream ciphers
nowadays auth encrpytion mods ⇒ tls

Front: Why asymmetric
Back: - less keys (N pairs instead of N(N-1)/2 for N participants)
- slower but much easier for symmetric key exchange

Front: How to asymmetric
Back: - integer factorization (product of primes is difficult to factorize)
- discrete logarithms exponent of \(g^x \mod p\) g x mod p﻿ is difficult to compute
  - used in Diffie-Hellman

Front: RSA Algorithm
Back: - take two large primes p, q (Miller Robin test = div small primes with random odd number, repeat r times ⇒ prob of false positive \(1/4^r\)1/4 r ﻿)
- N = p * q is the modulus
- using \(\phi\)ϕ﻿ function (how many primes smalles than N)
\(\phi(N) = (p-1) (q-1)\)ϕ( N ) = (p − 1)( q − 1)﻿
- public exponent e (coprime to \(\phi(N)\)ϕ( N )﻿)
- private exponent d is mod inverse of \(e \mod \phi(N)\)e mod ϕ( N )﻿
Encrypt: \(m^{e} \mod N\)m e mod N ﻿
Decrypt: \(m^{d} \mod N\)m d mod N ﻿

Front: RSA Vulnerabilities
Back: - small primes ⇒ bruteforce or factortables
- totient value known ⇒ N, e known ⇒ just solve equation system for p, q
- Deterministic = same message and key ⇒ same ciphertext
- Small messages and public exponent
  - \(m^{e} = c + kN\)m e = c + k N ﻿ is not much larger than N
  - brute force values for k
  - compute e-th root ⇒ get m
- Solution: padding (OEAP recommended)

Front: Signatures
Back: Provide:
- Integrity
- Authenticity
- public verfication
- nonrepudiation

Front: RSA Signature
Back: Signing: \(s = m^d \mod N\)s = m d mod N ﻿
Verification: \(m^d \mod N = m\)m d mod N = m﻿ check

Front: RSA Signature Issues
Back: - Malleability: if two signatures for two known messages are obtained ⇒ concat to get new signature for m1 * m2
- get signature of some message \(m' = m r^{r} \mod N\)m ′ = m r r mod N ﻿ ⇒ derive signature of m
- only sign messages < N
- splitting slow
- signature length = message length
- missing connection between individual signatures

Front: Diffie-Hellman Key exchange
Back: - both parties generate some private random number \(p_{priv}\)p p r i v ​﻿
- send \(pub = g^{p_{priv}} \mod N\)pub = g p p r i v ​ mod N ﻿ to other
- compute symmetric key \(pub^{p_{priv}} \mod N\)pub p p r i v ​ mod N ﻿

Front: DHKE Vulnerabilities
Back: the random values cannot be 1 (pub_a = g ⇒ S = pub_b) or p - 1 (pub_a = 1 ⇒ S = 1)
MITM attacks because no authentication

Front: Certificates
Back: Public Key Certificate
Prove authenticity of public key
Content:
- key
- usage
- subject
- alt names
- issuer
- signature (sign with private key of authority)
- validiy (timeframe)

Front: Certificate Authorities and Chain
Back: - verify signature with issuing CAs public key
- escalate certificate list until root authority
- self-signed certificates dont provide any trust value

Front: PKI
Back: Public Key Infra
Issue, Maintain, Revoke certs
- reg authority
- revokation list
- validation service
- certificate authority
- directory service
- certificate policies

Front: Registration Authority
Back: entity to which we apply for certificates
we get certificates if our personal data is correct (verification)

Front: Verification Process
Back: Depending on Trust Level
- domain validated = only prove domain is yours
- organization validated = prove the organization owning the domain exists
- extended = more detailed checks

Front: Revocation list
Back: maintain list of certificates that are no longer valid
problem: not so frequently updated, list is very large

Front: Validation
Back: query status of certificate
using directory service (certs issued by authority)

Front: Policies
Back: analyze PKI trustworthyness
lists all components and entities and their roles in the PKI

Front: Certificate Transparency
Back: problem with false/fake certificates
solution:
- public append only logs
- authority sends pre-cert (all info + poison extension) to log
- log checks chain and sends back timeframe in which cert is added
- CA sends cert and timestamp to user

Front: Interleaving Attacks
Back: use some message to tamper with another ongoing session

Front: Reflection Attacks
Back: send back messages
sender cannot verify that message doesnt come from legit sender
attacker doesn’t need any decryption or knowledge of key
Solution: add identification of sender inside the message

Front: Replay Attacks
Back: Capture message and send it multiple times to recipient
solution: issue challenge response nonce and include it in the message

Front: TLS Security
Back: Confidentiality
Integrity
Authentication

Front: Identification
Back: prove your identity

Front: Authentication
Back: verify identity of individual
- knowledge (passwords)
- possession (OTP, Challenge-Respones, TAN)
- inherence (biometrics)

Front: Online vs Offline Attacks
Back: - online = directly interact with service you want to enter
- offline = have password list, try to recover passwords

Front: Attacks for passwords
Back: - dictionary attacks
  - search for common passwords/phrases
  - more sophisticated with SE and password variations
- Brute-Force (only reasonable for offline attacks)

Front: Attacks for hashed storage
Back: - offline attacks / brute force
- rainbow tables
  - table of known collisions and common passwords

Front: Salt and Pepper
Back: - append salt and pepper to string then hash
- salt is random for every user and stored in the list
- pepper is secret and securely stored
Effect
- salt prevents rainbow tables (precompute common password hashes for each possible salt ⇒ infeasible)
- salt hides password reuse to show up in list
- pepper needs to be secure but prevents cracking even a single hash

Front: Password based key derivation
Back: - generate key based on password
- PBKDF2
  - concat key block id to salt
  - repeatedly compute HMAC of that Salt + id and the password
  - xor outputs

Front: Linux password storage
Back: /etc/shadow
- each line on user, fields separated by :
- password field
  - id
  - rounds
  - salt
  - some others

Front: OTP
Back: - prevent replay attacks
- first usage needs to be secure
- TAN Lists, OTP Generators \(h(Time || S_X)\)h( T ime∣∣ S X ​)﻿ or \(Enc(S_X, Time)\) E nc( S X ​, T ime)﻿
- Server maintains valid OTPs for some timeframe ⇒ access if any matches

Front: Challenge-Response
Back: - Server send Challenge
- Hash, Encr or Sign challenge and send back
- proves possession of some secret S

Front: Issues with Hardware Tokens
Back: - Expensive
- Bring device
- threat of getting stolen

Front: Types of Biometrics
Back: - passive
- active

Front: Characteristics of Biometrics
Back: - universality
- uniqueness
- measurability
- permanence
- unforgeability
- performance

Front: Biometric Error Measures
Back: False Acceptance \(False Accept \over Impostor Attempts\) I mpost or Attempts F a l seAccept ​﻿
False Rejection \(Wrong Rejections \over Legit Attempts\) Le g itAttempts W ron g R e j ections ​﻿
if both is about equal ⇒ good tradeoff

Front: Issues with Biometrics
Back: - steal trait (fingerprint, etc.) ⇒ solution liveness detection
- privacy (dont share you biometrics on the internet)
- reliability
- revocation (if stolen cannot really be revoked)

Front: MFA
Back: Use multiple DIFFERENT types of authentication
Risk based Authentication: increase amount of methods depending on location, time, device, severity of action, etc.

Front: SSO
Back: - send request to service
- redirect to to identity provider
  - url of service after authentication
  - id of service provider
- authenticate user at identity provider
- redirect
  - authorisation code (can be exchanged for an identity token containing user info)
- get identity token

Front: Definition Access Control
Back: Permit/Deny someone access to system(-ressources)/objects
subject = someone
object = ressources
access right = what can someone do with ressource (rwx etc.)

Front: Reference Monitor
Back: - get access requests
- approve/deny requests

Front: Security Policy
Back: - rules for who has what rights
- how and who can add/change rules?

Front: Reference Monitor Properties
Back: - non-bypassable = all requests go through monitor
- verifiable = check if monitor does its job correctly
- tamper-proof = monitor cant be compromised

Front: Storing Access Rights
Back: - Matrix: Users x Object = Right
- ACL: each object has list. if user is in list see permissions
  - needs user authentication
- Capabilities: tokens that allow certain permissions for one subject
  - no user authentication
  - monitor checks validity of token

Front: Delegation/Revocation
Back: Delegation:
- ACL = difficult
- Capabilities = just transfer token
Revocation:
- modify ACL for object
- bookkeeping needed

Front: MAC vs DAC
Back: MAC = Mandatory AC
- admin sets permissions
- users cannot change/delegate
DAC = Discretionary AC
- delegate/revoke/modify permissions within certain range (set by admin)

Front: Role Based AC
Back: - roles are defined hierarchical
- higher roles have all permissions lower roles have + more
- only define differential for new role
- users are assigned to role(s)

Front: Bell-LaPadula
Back: - for confidentiality
- sec level + category
- read
  - userlevel ≥ level and usercat ⊇ category
- write
  - userlevel ≤ level and usercat ⊆ category

Front: Linux permission escalation
Back: for user take best fitting triad and apply permissions
if user is owner ⇒ use owner (even if group has more permissions)

Front: User Identifiers
Back: - RUID
  - who started process
  - inherited from parent process (shell typically starts all)
- EUID
  - for permissions
  - inherited from parent unless s bit is set
- SUID
  - prev RUID and EUID if changed on runtime

Front: Setuid Bit
Back: if set the EUID is set to owner of binary
s = bit set + exec
S = bit set + not exec

Front: Change User Identifiers
Back: - EUID: seteuid(val)
  - privileged: any vaulue
  - unprivileged: current RUID, EUID, SUID
- UID: setuid(val)
  - privileged: change RUID and SUID too
  - drop root priv, no going back

Front: Linux Containers
Back: - classical OS has a kernel and processes making system calls to kernel
  - perform some OS operations
- Linux Containers
  - are containerized processes managed by docker, podman, etc.
  - containerd makes syscalls to kernel
  - run “parallel” to regular processes

Front: System Calls
Back: - namespaces
  - unshare command
  - isolated abstraction
  - process has its own isolated space
- chroot
  - changes root directory
  - chroot jail
- cgroups
  - control groups
  - organize processes hierarchically
  - limit/monitor ressource use
- seccomp
  - one way transition into secure state
  - can’t make any system calls that are not allowed
  - strict mode
    - r, w, e, sigreturn
  - filtered mode
    - manually define what is allowed
- capabilites
  - further distinguish what privileges processes can do
  - reduce number of setuid binaries
  - setcap, readcap
  - a list of capabilities can be enabled/disabled

Front: Hypervisors
Back: - needs to control ring 0 ⇒ more privileges
- extra ring -1

Front: TCP/IP Stack + Applications
Back: - Application + DNS, HTTP, …
- Transport + TCP, UDP, …
- Internet + IP, ICMP, …
- Physical Network + Ethernet, ARP??….

Front: ARP Spoofing
Back: - ARP is not authenticated
- respond to ARP requests faster than real host

Front: ARP Spoofing Solution
Back: - Switching table easily detects multiple MACs for same IP

Front: BGP Hijacking
Back: - BGP routes packets between AS
- Advertise malicious AS as fastest route to goal
- Packets get rerouted

Front: BGP Hijacking Solution
Back: - Route filtering
  - check request against ACL
  - policy that some address range always get routed to some AS
- S-BGP
  - Authentication and Authorization
  - use PKI
  - encrypt advertisements and prevent modifications
- Route Origin Authorization
  - use PKI to make source AS to announce prefix
  - check announcements against known ROAs
  - prevent fake origin announcements

Front: SYN Flooding
Back: - send huge amount of SYN messages
- don’t need resources on sender side
- consume many resources on server side

Front: SYN Flooding Defense
Back: - SYN Cookies
- use TCP Seq number to save state
- only open connection when ACK with cookie comes in

Front: TCP Injection/Hijacking
Back: - TCP Packets are not authenticated
- attacker guesses SEQ Number

Front: DNS Cache
Back: DNS architecture
- Stub resolver (local machine)
- Recursive resolver (some intermediate server)
- Authorative Name Servers
for faster resolving, requests are cached

Front: IP Spoofing by in band attacker
Back: - DNS is using UDP (not authenticated)
- send message as auth NS with route to malicious service
- be faster than auth NS

Front: DNS Response Spoofing
Back: - ask for resolution
- predict source of auth. NS
- send message as auth. NS faster than it can
- advertise resolving to malicious service

Front: Out-of-bailiwick responses
Back: - DNS sends requests to multiple auth. NS
- if recursive resolver thinks attacker is auth. NS send malicious resolving

Front: Defenses for DNS
Back: - DNSSEC
  - authenticity
  - integrity
  - uses signaturea
- DoT
  - DNS over TLS use TCP
- DoH
  - shared https port ⇒ deniability

Front: Amplification Attacks
Back: - Common idea: act like some service requesting things to many clients, service receives a bunch of replies, service dead
- SMURF
  - send ICMP ping via broadcast but set sender ip to the service
- NTP reflection
  - ask hosts for time resolution
  - replies have a lot of information
  - service gets all replies
- DNS Amplification
  - ask hosts for dns resolution

Front: Portscanning
Back: - send a bunch of pings to different ports
- see which ones reply
- maybe some open services are vulnerable

Front: Package Filter Firewalls
Back: - set policies
- block some direction, some protocol, on some port, etc.
- not stateful
- doesn’t identify related traffic

Front: Stateful Inspection Firewall
Back: - solves Package Filter Firewall issues
- maintain connection directory
- each connection has a state too

Front: Bypass Firewalls
Back: - DNS Rebinding
  - have a malicious website and dns server
  - client in firewall make dns resolution
  - dns server resolves to website which then executes malicious js code on the client
- Server Side Request Forgery

Front: VPN Security
Back: - Confidentiality
- Authentication
- Integrity