Intro to secure communication

and commerce

Exercise 8

Problem

Consider a large corporate network using authentication between master device and computer devices

Computer devices have very small memory capacity

how can the master device use different shared key with each computer's device

avoid PK (why?)

Solution

Avoid PK because of computational cost (the device has limited memory and/or CPU)

Can we use one symmetric key for all the devices ? Only if we assume attacker can’t extract any keys But this is a very strong assumption More acceptable threat model: some keys are exposed

Use PRF with master key stores in a master device (a KDC like solution): kc=fmk(c). Even if attacker an extract keys from SOME devices, she cannot

find keys of other devices Improve solution to provide perfect forward security against

exposure of a computer’s key! (Hint: assume synchronization)

Scenario

Nimda is an internet worm It is usually transmitted through email and

exploits bugs in outlook/express to run the attachement automatically.

Upon infection it searches for web servers and tries to infect them

Scenario

Infection of web servers causes them to append a java script to html files and thus infecting their clients.

The infection of web servers is done through back doors/bugs of IIS web server for “Unicode directory traversal”, allowing the guest user to search/update files on the local hard drive.

Problem

When Nimda infects a computer it looks for other web servers that are reachable from this computer.Propose a way for the search to be performedCan a web server prevent its detection by

such a search?

Solution

Search option 1:For each ip in class of ip address

Try open port 80 If open infect

Search option 2:Monitor HTTP/HTTPS transmission of host by

sniffing local information Infect destination of HTTP transmissions

Solution

Can the web server protect itself?Method 1: the web servers can work on ports

other than 80 (very unlikely due to standards)Method 2: The only way for the virus not to be

able to sniff the transmission is by encrypting it (usually using IPSec) depends on virus location in the protocol stack.

Problem

Lets assume Nimda has infected a computer that is behind a security gateway in the company “fool proof security”.

The computer A is allowed to communicate to a web server which resides in another branch of the company (which is also protected by a security gateway).

The communication between the A and the web server is protected by ESP.

Can the security gateways prevent the infection of the web server by Nimda?

Solution

NO! NIMDA can communicate freely with the web

server because it has control of the computer. NIMDA can send messages protected by ESP

from the computer. Further more, if the communication is done

using tunnel mode, then all message to the security gateway are clear text, thus can be detected/modified freely.

Problem

NIMDA contains the following string (which is not displayed by it)“Concept Virus (CV) V.5”

Can an information security specialist which knows this fact use it in order to add the firewall a protection against NIMDA assuming the firewall is: Packet filter State full inspection packet filter Application Layer relay

Solution

Packet filtering firewalls usually only inspect the headers of the packet and decide by them. Thus, packet filtering firewalls will not filter NIMDA.

Application layer firewall may scan the application packets and find out that NIMDA is being transmitted For example “mail firewall” which scans mail

according to given policies and may find/strip messages.

Problem

The web server executes and distributes only files created on a special `secure development machine`.

Assuming NIMDA infected files are not created on the secure development machine, suggest a mechanism to help the server to prevent/recover/detect infections and to avoid contaminating others.

Solution

Sign files using a private key of the secure development machine.

Execute and send only properly signed files. Calculate signature:

Sign<priv>(hash(file))

Protect public key in a ROM so no modification may be made to it.

Problem

Analyze the impact of IPSec on a simple tcp connection

Scenario

Let’s assume an RTT (round trip time) of 100msec, and fixed TCP timeout of 0.5sec Let’s assume no queuing affects the time.

Consider a connection which sends a single short query and receives a short reply. After wards it disconnects.

The time to compute any single public key operation is 1sec.

Invocation of IKE takes another 200msec. Simply due to the context switching

Problem

How long would it take for the IP-SEC security association to be established, assuming we use IKEv2?

Recall: IKEv2 ExchangesInitial Exchanges (cf. phase I)

IKE_SA_Init exchange: Negotiate crypto-suites, exchange keys (DH) and nonces

IKE_Auth exchange: authenticate IKE_SA_Init exchange,exchange identities, certificates and traffic selectors, and establish 1st child SA

Create_Child_SA exchange(cf. phase II)

Create_Child_SA exchange: Identify new SA (and, if rekeying, existing SA); Exchange nonces, and optionally keys (DH) and traffic selectors

initiator(Alice)

responder

(Bob)

Traffic Selector: IP addresses and/or ports (specific or range), protocol (TCP/UDP/*…)

Recall: IKEv2: IKE_SA_Init exchange

• Negotiate crypto-suites• Exchange gi, gr (Diffie-Hellman public values) • Exchange nonces

HDR, SAi1, KEi, Ni

HDR, SAr1, KEr, Nr, [CERTREQ]

SPIi, Version, flags,…

`cipher suites`

DH-group IDs,gi

gr

initiator’s nonce

Trust anchors (root CA’s)

Recall: IKEv2 IKE_Auth exchange• Authenticate (sign) IKE_SA_Init exchange• Exchange identities and certificates • Exchange traffic selectors • Establish 1st child SA• Encrypted and authenticated (MAC) using SK { }

HDR, SK{ IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSrIDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr }

HDR, SK{ IDr, [CERT,] AUTH, SAr2, TSi, TSrIDr, [CERT,] AUTH, SAr2, TSi, TSr }

TSi, TSr are Traffic Selectors

For co-located recipients

Signature AH/ESP `cipher suites`

Solution 200msec until IKE invoked PK calculations

2 : DH calculations (at IKE_SA_Init exchange) 2 : signatures (at IKE_Auth exchange) Summarizes to 4 PK operations

None in parallel; DH can be pre-computed If we add certificate verification then 2 more. This takes around 6 seconds.

We must add the 4*100msec(RTT) for the 4 phases used in the setup of the SA

Summary: almost 6.6 seconds

Problem

How many packets are sent by each party before the IP-sec SA is established?

Solution

Each party sends 3 IKE packets before IPsec SA is established.6 packets total

Also: sender’s TCP retransmits `SYN` packet once every TCPtimeout=0.5secTotal: 6.6/0.5=13 packets

Total of 19 packets till IPsec SA established

Problem

Compute the total number of packets sent and the total connection time.

Solution In addition to the previous packets, there are the application

packets. Lets assume for simplicity that each query is contained within 2

packets. For each transmitted packet, an ACK packet is transmitted. Further more, TCP connection establishment takes 3 packets. Summary

((2(query) + 2(responses))*2(acks)) + 2 query + 2 responses + 19(IKE) = 31 packets total

Total connection time is: 31 * 100ms(RTT) + 200ms(IKE) +

(6.6)(SA est)=~9.8sec

Problem

What is the overhead of packets and time?

Solution

The overhead is obviously the IPSec SA establishment and TCP overhead. (2(query)+2(responses)*2(acks) + 19(IKE) = 27

packets total 27 * 100ms(RTT) + 200ms(IKE) + (6.6) = ~8.8sec

A lot of overhead for just a simple connection Is it worth it?

Solution Consider a DOS attack on TCP connections. Without cookies, the servers may collapse due to buffers overflow

and CPU utilization. This is due to TCP timeouts and RTT calculations.

With cookies, add 2 messages for each connection establishment (I.e. 200 ms for this scenario) which is a lot less than the overhead of using IPSec.

Conclusion: use IPSec for long term connections and a large quantity of data for the overhead to pay; or against intercepting adversaries.

Note: TCP cookies do not help when ACTIVE ADV is causing the DOS attack.