280 likes | 386 Vues
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
E N D
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 performed • Can 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 Exchanges Initial Exchanges (cf. phase I) initiator(Alice) responder(Bob) 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 Traffic Selector:IP addresses and/or ports (specific or range), protocol (TCP/UDP/*…) 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
Recall: IKEv2: IKE_SA_Init exchange • Negotiate crypto-suites • Exchange gi, gr (Diffie-Hellman public values) • Exchange nonces initiator’s nonce HDR, SAi1, KEi, Ni SPIi, Version, flags,… gr DH-group IDs,gi HDR, SAr1, KEr, Nr, [CERTREQ] `cipher suites` 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 { } AH/ESP `cipher suites` Signature HDR, SK{ IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr } For co-located recipients TSi, TSr are Traffic Selectors HDR, SK{ IDr, [CERT,] AUTH, SAr2, TSi, TSr }
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.5sec • Total: 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.