Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Implementation of a Two-way Authentication Protocol Using Shared Key with HashCS265 Sec. 2David WangIntroduction•Authentication is important in most network communications•Before two parties can transfer secure information, they have to make sure that they are talk to the right person (or machine). •It is also important that both parties in the authentication process can identify each other without leaking any secret information.•Authentication on the network is challenging because the information being transferred on the insure link may be overheard, intercepted, modified, or replayed by other partiesIntroduction (cont.)•Many different protocols are used for network authentication with different concerns in mind. •Some protocols focus on high security; some protocols focus on performance•How to the right choices will depend on the application requirement–For example:–Online banking system requires higher security and integrity–Online chatting application requires lower securityApplication requirement •Need an authentication protocol for an online stock broker•Need to be very secure when users login to the system•Two-way authentication is needed because users don’t want to give out their stock account and password to wrong place, and broker don’t want hacker to steal money.•Efficiency is also important when users making orders, but the protocol will focus on the authentication.•Using shared key algorithm with HashProtocolA BI’m A; E (Ra, K)E ((Rb, Ra), K)H (passwd, Rb)Notations:A – Users Ra – Random number generated by AB – Broker Rb – Random number generated by B(m1, m2) – Message m1 and Message m2 K – Key shared by A and BE (p, k) – Encrypt plaintext p using key kH (m1, m2) – Hash message m1 together with message m2Protocol Analysis•Three messages to archive two-way authentication•First message: A encrypts a random Ra number using ‘K’ and sends it to B. Only B can decrypt it to get Ra.•Second message: B generates Rb and and sends E((Rb, Ra), K) to A. Only A can decrypt it to get Rb and Ra. A uses Ra to verify B.•Third message: A sends H(Password, Rb) to B. B verifies A by computing the same hash.•Finally: Finishes authentication by clearing some states. Can also use (Ra xor Rb) as session key to do the communication.Protocol Analysis (cont.)•Replay of the first message will not succeed because B will send back the other encrypted random number. Without knowing the key, this will not make sense to the intruder.•Replay the second message will not succeed because A will sends back H(passwd, Rb). Without knowing Rb, intruder will not be able to figure out passwd.•Replay the third message will not succeed because B will finishing the authentication after it receive the first hashed passwd.•Offline password guessing is not very possible because the intruder won’t be able to figure out the random numbersProtocol Analysis (cont.)•However, can not prevent the modification to the the message. This may be weak to denial of service attack.•Also, have to protect the password file on the server.•Can use HMAC with the message to prevent modification.•Can encrypt the password file on the server.Implementation•Implemented on top of HTTP protocol•Client side: GUI component using Java Swing, Crypto algorithm using TEA Java implementation with CBC mode, Hash using MD5 Java implementation.•Server side: Using JSP on Tomcat, Crypto algorithm using TEA Java implementation with CBC mode, Hash using MD5 implementation.DemoLogin FieldPassword FieldMessages between client and serverConclusion•This protocol can prevent replay and offline password guessing. However, we have to notice that the protocol it is weak to modification attack, and we also need to protect the password file on the server side.Credit to MD5 implementation•The MD5 source code is borrowed form
View Full Document
Unlocking...