1 What is network security (8.1)

Network security consists of:

confidentiality: only the sender and the intended receiver should “understand” the message contents. This is achieved through encryption.
End-point authentication: the sender and the receiver want to confirm the identity of each other.
message integrity: the sender and the receiver want to ensure that message is not altered, in transit or afterwards, without detection.
Operational security: access and availability: services must be accessible and available to the users.

1.1 Actors: Alice, Bob, Trudy

Bob and Alice want to communicate securely, but Trudy may intercept, delete and add messages. Trudy listens on the channel that Alice and Bob use to communicate.
Bob and Alice are every couple of hosts on the internet that want to communicate.

1.1.1 Trudy

Trudy can:

eavesdrop: intercept messages
insert messages
impersonification: spoofing the source address of a packet
hijacking: take over an ongoing connection by taking the place of either the sender or the receiver
denial of service: prevent the service from being used by others, for example by overloading resources

2 Principles of cryptography (8.2)

See Crittografia.

2.1 Language of cryptography

Alice’s plaintext gets encrypted by a encryption algorithm using Alice’s encryption key. The ciphertext travels through the channel and gets delivered to Bob, then gets decrypted into plaintext by a decryption algorithm using Bob’s decryption key.

m : plaintext message K_{A} (m) : ciphertext, encrypted with the key K_{A} m = K_{B} (K_{A} (m))

2.2 Breaking encryption

There are different ways encryption can be broken depending on the information available to Trudy:

Trudy only has the plaintext transmitted over the insecure channel, they need to decrypt it, there are two approaches to do so:
- brute force
- statistical analysis
known plaintext: Trudy knows some (plaintext , ciphertext) pairs

2.3 Symmetric Key cryptography (8.2.1)

In Symmetric key cryptography Bob and Alice share the same key $k$ (hence “symmetric”). $K_{A} = K_{B} = K$ .
Alice and Bob need to agree on the value of the key, without leaking it to third parties.

2.3.1 Stream ciphers

In this approach we encrypt one bit at a time.
Used for SSL/TLS connections, bluetooth connections and cellular and 4G connections.

Substitution cipher

Substituting letters:

Monoalphabetic cipher: substitute one letter for another. here the encryption key is the mapping between letters

2.3.2 Block Ciphers

In this approach plaintext messages get broken into equal-size blocks, then each block gets encrypted as a unit.

DES: data encryption standard

This is the US encryption standard. It uses a 56-bit symmetric key and 64-bit plaintext input, it is a block cipher with cipher block chaining.
It has been brute forced in less than a day, but there is no known good analytic attack.
It gets more secure with …

AES: advanced encryption standard

This is a symmetric-key NIST standard that replaced DES in November 2001.
Blocks are 128-bit wide.
Keys can be 128, 192 or 256 bit.
Brute force decryption that takes one second on DES, takes 149 trillion years on AES.

2.3.3 How entities establish a key

Symmetric key cryptography algorithms need the two communicating entities to establish a shared secret key.
Possible solutions are:

direct exchange
key distribution center (KDC): a trusted entity acts as an intermediary between the two entities
using public key cryptography for communicating the key

Key distribution center

Alice and Bob know their own symmetric key ( $K_{A - KD C}$ and $K_{B - KD C}$ ) for communicating with the KDC. This keys need to be retrieved in person at the KDC.

Alice sends to the KDC $K_{A - KD C} (A, B)$
The KDC responds with $K_{A - KD C} (R 1, K_{B - KD C} (A, R 1))$ , now Alice knows the session key $R 1$
Alice now sends Bob $K_{B - KD C} (A, R 1)$ , now Bob knows the session key $R 1$
Alice and Bob communicate using the shared session key $R 1$

2.4 Public Key Cryptography

Public Key cryptography uses a radically different approach: the sender and the receiver do not share the secret key, every user now has a public encryption key, known to all, and a private decryption key known only to the receiver.
Alice encrypts the plaintext with Bob’s public key $K_{B}^{+}$ , Bob decrypts the message using his private key $K_{B}^{-}$ : $m = K_{B}^{-} (K_{B}^{+} (m))$ .

Unfortunately public key cryptography is much more computationally demanding than symmetric cryptography: 100 times slower than DES.
Because of this we use public key cryptography to establish a symmetric session key.
Bob and Alice use RSA to exchange a symmetric session key $K_{S}$ , then use $K_{S}$ for symmetric key cryptography communication.

2.4.1 Public key Cryptography algorithms

Requirements:

$m = K_{B}^{-} (K_{B}^{+} (m))$
it should be impossible to compute the private key from the given public key
another important property is the following: $K_{B}^{-} (K_{B}^{+} (m)) = m = K_{B}^{+} (K_{B}^{-} (m))$ .

RSA: Rivest, Shamir, Adleman

Nel 1977 Rivest, Shamir e Adleman propongono un sistema a chiave pubblica con funzione one-way trap-door. Turing Award 2002.

3 Message integrity (8.3)

Message integrity consists in allowing parties to verify that the received messages are authentic:

the sender is who you think it is
the contents are what the sender intended them to be
message has not been replayed
the sequence of the messages is maintained

3.1 Message digests

To implement this we introduce message digests: fixed-length, easy-to-compute digital footprints.
We apply a hash function $H$ to $m$ and get a fixed-size message digest $H (m)$ .

Hash function properties:

easy to compute
irreversibility: given message digest $x$ , it must be unfeasible to find $m$ such that $x = H (m)$
collision resistance: given $[m, H (m)]$ it must be computationally unfeasible to produce $m^{'}$ ( $m^{'} \neq = m$ ) such that $H (m^{'}) = H (m)$ .
Si può mappare uno spazio infinito ad uno spazio finito, pur garantendo questa proprietà? Ovviamente NO (“attacco di buon compleanno”). Hence “computationally unfeasible” and not “impossible”.
seemingly random output

3.1.1 Internet checksum

The internet checksum has some of the properties of a hash function:

fixed length output
is many-to-one
But, given a message with its hash value, it is easy to find another message with the same hash value.

3.1.2 Hash function algorithms (8.3.1)

MD5

MD5 computes a 128-bit message digest in a 4-step process.
Given an arbitrary 128-bit string $x$ , it appears difficult to find the message digest.

SHA-1

SHA-1 is the US standard. It produces a 160-bit message digest.

3.1.3 MAC: Message Authentication Code (8.3.2)

Using the MAC we can authenticate the sender and verify the message integrity.
This approach uses no encryption and is also called “keyed hash”.

We introduce a shared secret: a string only known to sender and receiver.

The sender computes the MAC of < message , shared secret > ( $H (s, m)$ ).
the message and the MAC travel to the receiver
the receiver again computes the MAC of < received message , shared secret >, then compares it with the received MAC
if the two MACs are equal the message has not been altered AND the sender is the expected one.

Playback attack

More precisely if the two MACs correspond, we know that the MAC was generated by Alice, but we don’t know if the < message , MAC > was transmitted by Alice.

Trudy can intercept the message, and play it back to Bob.

Defense

To defend from the “playback attack”, we include the timestamp of generation in the message before computing the MAC. But this is quite difficult to implement, because sender and receiver clock may not be synchronized. The real solution is using OTP (one time password).

Alice contacts Bob
Bob sends an OTP $R$
Alice computes the MAC as follows: $MAC = H (R, s, m)$
Bob expects ONE message PER sent OTP

3.2 Digital signatures (8.3.3)

Digital signatures are a cryptographic technique that allows the sender to digitally sign a document.
A digital signature is:

verifiable: the recipient can verify and prove that the sender and no one else signed the document
non-forgeable
And allows:
non repudiation: the recipient can prove that the sender signed it
message integrity

MAC cannot be used as a digital signature because the secret is shared between the two communicating.

For authentication we use asymmetric cryptography (2.4 Public Key Cryptography):

Bob signs $m$ by encrypting with his private key $K_{B}^{-}$
Bob sends the signed message $K_{B}^{-} (m)$
Alice can verify that the sender is Bob if the message can be decrypted with Bob’s public key $K_{B}^{+}$

But as we said asymmetric cryptography is computationally demanding, so we sign the digest, not the message (the message can be arbitrarily long!):

Bob computes the digest: $H (m)$
Bob signes (encrypts) the digest with its private key
Bob sends the message $m$ with the encrypted message digest $K_{B}^{-} (H (m))$
Alice computes the digest of the received message: $H (m)$
Alice decrypts the received digest using Bob’s public key and obtains (hopefully) the message digest $H^{'} (m)$
Alice compares $H (m)$ and the decrypted messages digest $H^{'} (m)$ , if they are equal the message and the sender can be trusted.

3.2.1 CA: public key certification authorities

Who guarantees that Alice actually has Bob’s public key?
A certification authority (CA) binds a public key to a particular entity $E$ .
The entity $E$ registers its public key with the CA, providing a “proof of identity”.

The CA creates a certificate binding the identity of $E$ to $E$ ‘s public key
the certificate gets digitally signed by the CA using the CA’s private key
when Alice wants to ensure Bob’s identity, it decrypts the certificate using the CA’s public key
The CA’s public key is supposed to be known by everyone.

4 Authentication (8.3)

Goal: Bob wants Alice to prove her identity to him.

4.1 AP: Authentication Protocol

AP1.0: “I am Alice”
AP2.0: Alice says “I am Alice and this is my IP address”
AP3.0: “I am Alice” and sends her secret password to prove it and sends her IP address (Trudy listens to the password the first time and then copies it)
AP3.1: AP3.0 with encrypted password (Trudy can still paste the encrypted password)
AP4.0: Bob sends Alice a nonce $R$ , Alice must return $R$ encrypted with the shared secret key. Now Bob knows Alice is live. Requires a shared symmetric key.
AP5.0: AP4.0 but using public key cryptography:
1. → I am Alice
2. ← R
3. → $K_{A}^{-} (R)$
4. ← send me your public key
5. → $K_{A}^{+} (R)$
  This protocol is susceptible to “man in the middle” attacks, when Alice sends “I am Alice”, Trudy can intercept it and send it herself, now Bob will send Truly the nonce

5 Securing e-mail (8.5)

For securing e-mail we need both Authentication and message integrity.
We use PGP (pretty good privacy).

5.1 E-Mail authentication

Alice wants to send confidential e-mail $m$ to Bob:

Alice:

generates a random symmetric private key, $K_{S}$
encrypts message with $K_{S}$ (for efficiency)
also encrypts $K_{S}$ with Bob’s public key
sends both $K_{S} (m)$ and $K_{B}^{+} (m)$ to Bob

Bob:

uses his private key to decrypt and recover $K_{S}$
uses $K_{S}$ to decrypt $K_{S} (m)$ and obtains $m$

5.2 E-Mail Authentication and Message Integrity

Alice digitally signs the hash of her message with her private key, providing both integrity and authentication.

5.3 E-Mail Authentication, Integrity and Confidentiality

6 Securing TCP connections: TLS (8.6: SSL)

TLS (transport layer security) is a widely deployed security protocol above the transport layer, and is supported by almost all browsers and web servers at https (port 443).

This protocol provides:

confidentiality: via symmetric cryptography
integrity: via cryptographic hashing
authentication: via public key cryptography

6.1 Implementation

handshake: Alice and Bob use their certificates and private keys to authenticate each other and exchange or create shared secrets
key derivation: Alice and Bob use the shared secret to derive a set of keys
data transfer: stream data transfer: data as a series of records
connection closure: a special message to securely close the connection

6.1.1 T-TLS: initial Handshake

Bob establishes a TCP connection with Alice
Bob verifies that Alice is really Alice
Bob sends Alice a master secret key (MS), used to generate all other keys for the TLS session
Potential Issues: 3 RTTs before the client can start receiving data, including the TCP handshake

In detail:
client: TCP SYN
server: SYNACK
client: ACK + t-tls hello
server: public key certificate
client: $K_{A}^{+} (MS) = EMS$ + client request
server: server reply

6.1.2 T-TLS: cryptographic keys

It is considered bad to use the same key for more than one cryptographic function, we use different keys for the MAC (message authentication code) and encryption.
We have four keys:

$K_{C}$ : encryption key for the data sent from client to server
$M_{C}$ : MAC key for the data sent from client to server
$K_{S}$ : encryption key for the data sent from server to client
$M_{S}$ : MAC key for the data sent from server to client

6.1.3 T-TLS: encrypting data

The data stream gets broken into a series of “records”, each record carries a MAC, created using $M_{C}$ .
A record is composed of {length , data , MAC}, and gets encrypted with the symmetric key $K_{C}$ and passed to TCP.

What are the possible attacks on a data stream?

re-ordering: the man-in-the-middle intercepts the TCP segments and reorders them, by manipulating the sequence numbers in the unencrypted TCP header
replay
The solutions are:
use TLS sequence number (both the data and the TLS sequence number are incorporated in the MAC)
use a nonce

6.1.4 T-TLS: connection close

A truncation attack is possible: the attacker forges a TCP connection close segment so that one or both sides think there is less data than there actually is.
The solution is to have different record types:

type 0 for data
type 1 for close
The MAC is now computed using data, type and TLS sequence number, and gets then encrypted with the symmetric key $K_{C}$ .

6.2 Transport-Layer Security (TLS)

TLS provides an API that any application can use.

TLS vs QUIC:

6.2.1 TLS Cipher suite

TLS needs a cipher Suite, which include:

Algorithm for key generation
Public-key encryption algorithm
Symmetric-key encryption algorithm
MAC algorithm

TLS 1.3 offers a more limited cipher suite choice than TLS 1.2 (5 rather than 37 choices).

This means client and server need to agree on the used cipher suite.

6.2.2 TLS 1.3 initial handshake

the client in the TLS client hello messages sends:
- the supported cipher suites
- the client nonce
the TLS server hello message includes:
- the selected cipher suite
- the server certificate
- the server nonce
the client:
- checks the server certificate
- generates the key
- can now make application requests (e.g. HTTPS GET)
  This handshake only needs one RTT.

7 Network Layer Security: IPsec (8.7)

IPsec provides datagram-level (so network layer level) encryption and integrity, for both user traffic and control traffic.
IPsec has two modes:

transport mode: only the datagram’s payload is encrypted and authenticated
tunnel mode: the entire datagram gets encrypted and authenticated, and the encrypted datagram is encapsulated in a new datagram, with a new IP header, tunneled to the destination.

7.1 Virtual Private Networks (VPNs)

Institutions often want private networks for security, but this is costly and needs separate routers, links and DNS infrastructure.

The solution is a VPN: the institution’s inter-office traffic is sent over public Internet instead, but encrypted before entering public internet.

7.2 SAs: Security Associations (SAs) (8.7.3)

Before sending the data, security association (SA) is established from the sending to the receiving entity (directional).
Both sender and receiver maintain state information about the SA, but remember: IP is connectionless, IPsec is connection-oriented.

The router implementing the security stores:

Security Parameter Index (SPI): a 32 bit identifier
origin SA interface
destination SA interface
type of encryption used
encryption key
type of integrity check used
authentication key

7.3 IPsec datagram (8.7.4)

7.4 IPsec protocols (8.7.2)

There are two IPsec protocols:

authentication header (AH) protocol: provides source authentication and data integrity but not confidentiality
encapsulation security protocol (ESP): provides source authentication, data integrity and confidentiality. It is more widely used than AH.

7.4.1 ESP tunnel mode: actions

Actions for the ESP tunnel mode at the router connected to the public internet:

Appends the ESP trailer to the original datagram (which includes the original header fields)
encrypts the result using the algorithm and the key specified by the SA
appends the ESP header to the front of this encrypted quantity
creates an authentication MAC using the algorithm and the key specified by the SA
appends the MAC forming the payload
creates a new IP header, new IP header fields and the addresses to the tunnel endpoint

7.5 IPsec sequence Numbers

For the new SA, the sender initializes the sequence number to 0, each time the datagram is sent to the SA:

the sender increments the sequence number
the senders places the value in the sequence number field
The goal is to prevent the attacker from sniffing and replaying a packet, because the receipt of duplicate authenticated IP packets may disrupt the service.
To solve this the receiver uses a windows (it doesn’t keep track of all the packets) to check for duplicates.

7.6 IPsec Security databases

IPsec uses two databases:

Security Policy Database (SPD): “what to do”
- policy: for a given datagram the sender needs to know if it should use IPsec
- the policy is stored in the SPD
- the sender also needs to know which SA to use
Security Association Database (SAD): “how to do it”
- endpoints hold the SA state in the SAD
- when sending an IPsec datagram, the outgoing router $R 1$ accessed the SAD to determine how to process the datagram
- when an IPsec datagram arrives to the ingoing router $R 2$ , it examines the SPI in the IPsec datagram, indexes the SAD using the SPI and processes the datagram accordingly

7.7 IPsec Conclusions

IPsec is a protocol for datagram-level security
- AH provides integrity and source authentication
- the ESP protocol (using AH) adds also encryption
IPsec peers can be:
- two end systems
- two routers/firewalls
- a router/firewall and a end system

8 Operational security: firewalls and IDS (8.9)

8.1 Firewalls (8.9.1)

A firewall isolates and organization’s internal network from the larger internet, allowing some packets to pass and blocking others.

We need firewalls to:

prevent DOS attacks
- SYN flooding: the attacker establishes many bogus TCP connections, leaving no resources for real connections
prevent illegal modification or access of internal data
- replacing an official website with something else
allow only authorized access to the inside network
- by defining a set of authenticated users/hosts

There are three types of firewalls:

stateless packet filters
stateful packet filters
application gateways

8.1.1 Stateless packet filtering

The internal network gets connected to the Internet via a router firewall, which filters packet-by-packet and decides to forward/drop a packet based on information in the IP header:

source IP address, destination IP address
TCP/UDP source and destination port numbers
ICMP message type
TCP SYN and ACK bits

ACL: access control list

An ACL is a table of rules, applied top to bottom to incoming packets, that looks like the OpenFlowForwarding.

action	source address	destination address	protocol	source port	destination port	flag bit

### 8.1.2 Stateful packet filtering The problem with stateless packet filtering is that it admits packets that make no sense, for example TCP packets without a TCP connection established.

Stateful packet filtering solves this by keeping track of every TCP connection, it in fact:

tracks connection setup (SYN), teardown (FIN) to determine wether or not a packet makes sense
timeouts inactive connections at the firewall: no longer admits these packets

action	source address	destination address	protocol	source port	destination port	flag bit	check connection

8.1.2 Application Gateways

An application gateway filters packets on application data as well as on IP/TCP/UDP fields.
An application gateway is a separate host than the router/filter.

A possible application is: the firewall blocks every telnet connection, except the ones incoming from the application gateway, for authorized users the gateway sets up a telnet connection to the destination host by relaying the data between these two connections.

8.1.3 Limitations of firewalls and gateways

The router is susceptible to IP spoofing, it can’t know if the data “really” comes from the claimed source.
If multiple applications need a special treatment, each need its own application gateway.
Client software must know how to contact the gateway, for example by setting the IP address of the proxy in the web server
filters often use a “all or nothing” policy for UDP
tradeoff: the degree of communication with the outside world in exchange for the level of security
many highly protected sites still suffer from attacks, even using firewalls

8.1.4 IDS: Intrusion detection systems

An intrusione detection system performs a deep packet inspection by also looking at the packet contents (for example checking character strings in the packet against a database of known virus and attack strings).
And IDS also examines the correlation among multiple packets:

port scanning
network mapping
DoS attack

An organization may use multiple IDSs, each with different types of checking at different locations.

🪴 Quartz 4.0

Explorer

Network Security