Wednesday, February 28, 2007

Continuation to Did you know series?

The code red worm is a computer worm that attacked computers running the Microsoft IIS web server. Within a week of its release (July 13th 2001) it had infected 3590000 users. It made use of the vulnerability in the indexing software distributed with IIS called as buffer overflow. This worm along with others like slammer, nimda etc are all fast scanning worms. The effectiveness of these worms can be argued to the fact that IPv4 addresses are only 32 bit long thus allowing exhaustive search. This can make one believe that adoption of the 128bit IPv6 addressing should stem the speed due to it sparse address spacing of these worms assuming that the number of internet users dont go up by similar factor. The work factor for finding a target in an IPv6 Internet will increase by approximately 2 to the power 96, rendering random scanning prohibitively expensive. This raises a good point of discussion if this can be a good solution.

Fact on security threat

Fact on security threat:
Clever computer criminals have recently become much more sophisticated in their attacks against online banks. The Internet is now awash in programs called "remote access Trojans," or RATs, that feed on online banking passwords. Designed specifically to lurk in the background, waiting until the user types the name of a well-known bank into a Web browser, the program springs into action, copying every keystroke. The data is sent back to the criminal, who can then raid the online bank

Thursday, February 22, 2007

Did you know series?

Post what you know about security attacks or alarms that you would like to share with others:

Here's one: A fast scanning worm can affect more than half the Internet in 10 sec. The Slammer worm was not quite as fast but it was nearly there. Any ideas as to why?

Thursday, February 1, 2007

Lecture 3: Secure Routing in the Internet

About the man-in-the-middle attack (MITM) in the challenge-response protocol discussed today, I am wondering if the following method works. As Joel also suggested briefly, I am thinking of using of authenticated key agreement protocol (KA) to encounter this problem.

Informally, and for the purpose of our discussion, KA is a public key protocol that establish a session key between two entities, and each party get authenticated by the other.

A secure KA (in the Bellare-Rogaway model or the Canetti-Krawczyk model) can withstand MITM. In particular, a user C forwarding a user A's challenge to user B will only result in two different session keys (one between A and C and another between B and C).

So my suggestion is as follows: use such KA to get a session key (which involves the challenge-response part already), then use the resulting session key to encrypt the signature. If the other side is not the one it purported, then he/she cannot decrypt and get the signature. The encryption here is just symmetric encryption, and the computational overhead involved by KA can be amortized to several invocations (well, there is a security trade off, e.g. the session key is later compromised).