Übungen

1. Confidentiality

2. (Data) Integrity

3. Authenticity

4. Availability

5. Accountability

6. Controlled Access

• two related concepts that address the trustworthiness of data, that we, for instance, have received over the internet

• Data integrity focuses on the content of the data and prevents unauthorized modifications

• Data authenticity verifies the source/origin of the data

• when data integrity is compromised, data loses its authenticit as well

• In practive both concepts ised in combination to provide comprehensive data security

• practical Example:

  • digital signature where we sign a file’s hash value (“Fingerprint”)

• no universal answer, depends on the scenario and security requirement that can be derived from it

• Example:

  • someone wants to send secret information over the Internet, their primary concern is to prevent that these secrets leak

  • someone downlaods software from the internet, their primary concern is that the software os authentic (and has integrity), dont want to use a potentially modified application

    
    

Imagine we are controlling some large-scale Cyber-Physical System (CPS) remotely over Internet for instance, a network of solar power plants.

• Confidentiality:

  • Control messages should be encrypted to prevent some third party from gaining inside knowledge about our system and business logic

• Integrity:

  • We need to make sure that modifications to the control messages can be spotted beform the command is executed and causes harm

• Authenticity:

  • Devices inside our CPS should only accept control messages created by known/authentic and authorized entities

• Availability:

  • The log server that logs the control messages must be able to perform its duty constantly

• Controlled Access:

  • All interfaces of the CPS to the outside world can only be used by authorized knwon entities

individual security goals are related, used in conjunction, and support each other!

main differences:

• for offline application, the only limitation is the attacker’s resources. For example the attacker has stolen someone’s hard drive and wants to decrypt it, the only limitations is the attacker’s hardware’s ability to generate and test passwords

• for online Appliactions, the limit is the defender’s resources and, to some extent, the network itself

more thoughts:

Online appliactions induce a delay for attacker due to the need for the server to respond (network latency, network bandwidth and server CPU) While the attacker cannot change network bandwidth and the server’s resources, they can send multiple login attemps in parallel

Online appliactions can (and should) defend against brute force attacks.

Possible defenses are:

• Limit logins per IP -> Does not work when the attacker has acces to dynamic IPs, multiple VPN endpoints, of even a botnet with hunderds of devices

• Limit logins per user account -> The attacker might impersonate a benign (= gutartig) user and send “bad“ requests. The benign user might get blocked quickly

• During a (possible) attack, limit logins to humans -> Accessicility? Not everyone can solve captchas

• Block entire network -> There might also be honest users that get blocked

• Two-factor authentication -> Increased effort on user side

• Monitor login attempts -> The amound of log messages might be overwhelming

Getting a login page right is highly complicates. Needs a carefully selected and monitored implementation of the mentiened measures. Every defense can also introduce problems and has potential to make the system less user-friendly

1. The amount of permutations n of a password of length l and alphabet a can be computed with this formular:

1. From math we know that the exponent (l) has a much more significant impact on a function’s growth than its base (a). So the length of the password is the more important factor than the size of its alphabet

   How many chracters do both alphabets have?

   • a1 : 95 printable ASCII characters

   • a2: 26 lower case letters

2. We assume Password 2 (longer, but smaller alphabet) is stronger that Password 1 (shorter, but more alphabet characters)

   • furthermore compute the number of permutations of Password 2 and try to find the alphabet size x of an 8-character password with similar strength:

We would have to use a 133-character alphabet for an 8-character password to get a higher security level than Password 2 -> Password 2 is stronger cause PW 1 only uses 95-chars

• passive attackers

• active attackers

Passive attacker:

• Eavesdrop

• Traffic analysis

Active attacker:

• (all passive attacks)

• modify messages

• replay messages

• delay messages

• delete messages

• forge messages

• Eavesdropping and traffic analyses are entirely passive and can thus not be detected

• Delaying messages my be detectable to a certain degree. However, the delay may also be induced due to unreliable transfer over the Internet

• The same holds for dropping of messages

• If no additional security services are used, like digital signatures, it may be hard to differentialte between random transmission errors and random-looking malicious message modification

The important takeaway of this is that various attacks can look like random errors and it is difficult to determine the reason for the observed problem

Correct: 2,3

Wrong:

• 1: a client cannot compute the cookie, a client just sends back the cookie (+1). If a client were able to compute the cookie, an attacker could lanch a DDoS against the server because the attacker could compute the handshake without beeing able to receive the SYN, ACK packets

• 4: the whole point of this protection is that the server does not allocate resources for spoofed requests

1. cookie = K, src

   An attacker initiates one normal 3-way handshake and now has the key. Now the attacker can calculate all cookies for spoofed requests

2. cookie = h(src)

   There is no secret in the cookie, the attacker can just calculate the cookie for all spoofed requests

3. cookie = h(K)

   The cookie is the same for every spoofed source address and the cookie never changes. An attacker initiates one normal 3-way handshake and now has the cookie

If we can guarentee integrity of, for example, a data item, we achieve that this data item cannot be changed without us noticing. However, we do not know that, for instance, Alice is the origin of the data item.

Outlook: Integrity is often achieved by hashing data which creates a checksum (hash)

If we can guarentee authenticity of a data item, we know that, for instance, Alice has created it. however, if Bob changes the data item, its origin has changed, and its authenticity is voided.

Outlook: In practice, authenticity is often achieved by combining hashing and signing

Authorization and Authentication are often needed in scenarios where we want to achieve fine-grained access control.

For instance, we want to create an access control system that enforces that Alice may create, read and modify files in a file system.

However, Bob can only read the files Alice, and other users have created. In the first step. such an access control system must authenticate the user; in the second step, it can determine (and enforce) the user’s access rights.

For instance, a network firewall. It works on IPs, ports and protocols but usually does not (need to) authenticate communicating parties. However, it authorizes some communication events based on a rule list and discards others

• Security Requirements

• Security Policy

• Security Mechanisms

• Security Requirements: Corporate secrets, Confidentiality

• Security Policy: Block Facebook

• Security Mechanisms: Firewall

Rule A: The source address is not specified. Your IP range is 192.168.1.0/24, however, your clients might spoof arbitrary IPs.

Rule B: This interface is not specified. The Internet can send arbitrary spoofed packets to your Zone 1

Rule C: This rule is completly shadowed by rule A. Thuss, SSH is allowed by rule A

Rule D: There is no problem with the correctness of rule D, although placing it at the top of the firewall configuration might result in better performance. This is the case if a majority of the traffic is exchanged in established connecitons, as matched by the rule D, and no other rule is the table need to be processed before matching.

Finally, a default rule at the end is missing. It should obviously “deny everything that did not match“ in this scenario

a)

• Rule 1 implies that Zone 1 can access the mail server on ports 80 and 443. Contradicts rule 3. Rule 3 should take precedence

• Rule 4 directly contradics rule 3. We assume that rule 4 is an exception to rule 3. Rule 4 should take precendence

Inreality, with this setop, most users will be helpless because we don’t allow DNS. Furthermore. a mail server which is not allowed to initiate connections to other mail servers can not send but only receive mails.

b)

c)

a) A NIDS could be placed in Zone 1 to look over the protected network. Assuming that the NIDS would be connected to the network switch, it could detect a compromised workstation which performs port scans or sends payloads, containing predefined signatures.

b) One HIDS could be running on the Web Server and another one on the Mail Server

The HIDS could monitor the machines for attacks that compromise configuration integrity on the server itself. However running a HIDS would add performance drawbacks by real-time monitoring of the host activity.

False positive -> An alarm was raised but no intrusion took place

False negative -> No alarm was raised although an intrusion took place

Misuse Detection: Knowledge-based scanning for predefined signatures. Fast detection of known attacks. False positive error rate typically very low.

Anomaly Detection: Behaviour-driven comparison between a prdefined normal system state and the current state. System is able to detect new attacks but typically has a higher false positive error rate.

There is no (central) server mentined in the system and if you want confidentiality between all participants, then every user must have a key with exactly every other user. As keys are symmetric this yields n(n-1)/2 keys, which is in O(n^2). If you want one key per direction it is still in O(n^2).

In public-key cryptography, every user has a public key that everyone else can know and use, plus one secret private key. This means there are 2n keys, which is in O(n)

A block cipher operates on input data of a fixed length, called block. Input block and key produce an output block of the same length as the input block.

simpleHash is not a cryptographic hash function.

Counterexample: not collision resistant. simpleHash(00010000) = simpleHash(0) = 0

a) Screened Subnet Architecture (DMZ). Both are okay

b) Matching rule + action: D −→ Permit

State: (Alice, 1.2.3.4, 52000, 80, TCP)

c) matching rule: I −→ Permit

State: – “ –

d) matching rule: G −→ Permit

State: – “ – ++ (WebSrv, 141.30.13.20, 55000, 80, TCP)

e) matching rule: H −→ Drop State: – “ –

f) matching rule: C −→ Permit State: – “ – ++ (Alice, 8.8.8.8, 49152, 53, UDP)

g) matching rule: J −→ Drop State: – “ –

• 11 bit is simply so small that we can easily brute-force collisions

Hash function must be deterministic. For example, we could not decrypt RSA-OAEP if G and H were not deterministic.

• SHA256 is a cryptographic hash function → it is a oneway function. The one-way property ensures: If the password file got stolen, an attacker cannot reverse SHA256 to get back the plaintext passwords.

Unfortunately, this does not help much (for weak passwords). The common way to crack stored

password hashes a dictionary attack.

1. Get a dictionary of commonly used password, words, l337-sp34k-substitutions, brute force, ...

2. Hash them all

3. Check the hashes against the stolen password hashes

More efficient technique: Rainbow Tables (Google is your friend), trade space-efficience against longer lookup time

a) This method is called salting. Every user gets his own random r.

Several goals are achieved with this.

• If two users use the same password, the random r will guarantee that the hashes are not the same.

• It protects users with weak passwords against pre-computation. Try it yourself: Calculate the hash of a weak password and google the hash. If your password was weak, you should be able to ‘reverse’ the hash by googling. Add a salt. Now, it should be impossible to google the hash.

• An attacker would need to compute a dictionary attack for each r.

• An attacker would need to construct a rainbow table for each r.

b) Assume r is at least 128bit. r will likely be not in your dictionary.

No attacker will pre-compute rainbow tables for all combinations. It is thus unlikely that a pre-computed rainbow table already exists for a given r.

• An attacker would need to compute a dictionary attack for each r.

• An attacker would need to construct a rainbow table for each r.

Two observations:

• General-purpose hash functions are designed to be computed efficiently.

• Users are choosing weak passwords.

If an attacker gets a password file, the attacker can just brute-force the hashes. One can never prevent this but one can try to slow down an attacker.

Special functions to store passwords are very similar to hash functions (1st/2nd pre-image resistance, collision resistance and random oracle property), but slower and more memory intensive.

Those functions are carefully designed that they also do not parallelize well, even with special hardware. They – of course – also use salting! You could implement such a function for example by applying SHA256 a few thousand times: SHA25610000(r ∥ password).

You should however use an established library function whenever possible (as the above suggestion is not particularly strong).

a) Public Key: (3127, 3)

Private Key: (3127, 2011) (or just (2011) )

b) p,q

c)Obviously, the key length is way too small!

bin(3127) = ’110000110111’

length = 12 bit!

d)

The private key does not exist in a central form but is split into n fragments or partial keys. A threshold signature can only be computed if at least t partial keys are involved.

• The private key is more difficult to compromise, as the attacker needs at least t partial key in order to successfully compute a signature.

• As the key resides on n different nodes, a threshold-cryptography-based signing system can still work if at least t nodes remain online.

• For the same reason, it is less likely that the private key gets lost.

• "Decision" whether to sign something or not can be distributed (e.g. distributed system)

• With DKG, the key never exists in its combined/centralized form.

• The dealer might keep a copy of the key split into fragments and use it for adversarial purposes.

• There is none!

• In both worlds, the signature can be verified using the public key that corresponds to the centralized or distributed private key

Without any help, we do not know who owns which public key. A certificate solves this issue by creating a verifiable/authentifiable binding between an entity’s identity (name, email address, URL, etc.) (person, server, service, etc.) and a public key owned by that entity.

The public key in the certificate can be trusted

1) if we trust the CA that issued the certificate,

2) if we can verify the signature of the certificate (which probably means that we have to check a whole certificate chain!),

3) if we are inside the "time window" in which the certificate is valid,

4) if the certificate has not been revoked.

Root CAs are the trust anchors of a PKI.

This also means that there are no other CAs in the PKI hierarchy "above" Root CAs.

This also means that no other CAs could sign a Root CA’s certificate to establish trust in it.

Hence, Root Certificates need to be deployed via Root Stores.

In case the sub-CA’s private key sksub is compromised, the sub-CA’s certificate can be revoked by the Root CA, and a new key pair can be created and certified by the Root CA as described above.

Certificate revocation means a certificate is marked as being invalid before it expires.

Revocation can be helpful in situations where the private key skx that belongs to the certified

public key pkx is lost or compromised. A certificate can also be revoked if the ownership of the

certified identity changes, e.g., company/URL/... is sold to someone else, etc.

CRL means that a CA periodically publishes a list of revoked certificates.

The browser downloads this list and checks that the certificate it received from the server (actually, all certificates in the certificate chain!) is not revoked (i.e., it is not on the list). Downloading and checking the CRL is a time-consuming task.

Other problems are that the CRL needs to be fresh, and the browser needs to be able to download it - attackers might block the download. If the CRL cannot be loaded, browsers often skip the check without warning the user.

OCSP is a challenge/response protocol where the browser asks the OCSP server if a certificate is still valid. OCSP has the same freshness problem as CRLs. Furthermore, an attacker can block requests, and browsers will most likely soft-fail. Finally, the OCSP server learns what sites the browser (= user) visits, which is a privacy issue.

The overall approach is that a computer has a list of "expected" certificates/public keys of websites. If the website presents an unexpected certificate, the browser can stop the connection attempt and warn the user.

There are two types of pinning:

static pinning and dynamic pinning.

Static pinning can mean that the browser creates "pins" when it first visits the website ("user-driven pinning"), or the browser comes "pre-loaded" with pins of the most important sites.

With dynamic pinning, the browser can request pins from other browsers/other computers on the fly.

User-driven pinning has the "trust on first use" problem, i.e., the browser does not know if the certificate it pins is authentic. The same applies to pins dynamically requested from other entities.

Pre-loaded pins would solve these issues, but browsers cannot deliver pins for all websites (scalabil- ity problem). Pinning is also problematic, as certificates can change for legitimate reasons like renewal.

Note: User-driven and dynamic pinning have lost relevancy since Certificate Transparency was introduced.

a)

b)

c)

d)

e)

a) “issue ;” forbids all CA to issue.

b) You are permitted to issue. Lack of record implies no restrictions.

c) You are permitted to issue. netsec.top is in the list of permitted CAs.

d)

a) DNS is a fundamental component for many applications in the WWW. For many services the authenticity and integrity of DNS information is essential. However, the original design of DNS did not include any security features. In order to prevent MitM and spoofing attacks, DNSSEC adds authenticity and integrity protection to DNS replies.

b) DNS resource records (RRs) are grouped into RRsets based upon their type. The resulting RRset is digitally signed, using public key cryptography. The signatures are stored in a new record type (RRSIG) alongside the existing records for a zone.

c)

d)

a)

b) Padding (only for block-cipher modes, not CTR and OFB).

c)

a) With different IVs, identical plaintexts are encrypted to different ciphertexts.

b) No. It is just a random initialization value, not a secret. Secrecy of message depends on secret key.

c) Yes, otherwise, identical plaintexts are encrypted to identical ciphertexts.

d) Yes! Think about how CBC decryption works. If an attacker can flip bits unnoticed in the IV, the attacker can completely influence the first decrypted plaintext block.

a) OCB, GCM

b)

c)

d)

e)

OFB, CTR

a)

a)

b)

c)

d)

e)

a)

b)

c)

d)

a)

b)

c)

a)

b)

c)

a)

b)

c)

d)

e)