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.
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
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
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
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.
Top Related