1. Department of Computer Sciences The University of Texas at Austin A Secure Cookie Protocol Alex X. Liu Department of Computer Sciences The University of Texas at Austin Co-authors: Jason M. Kovacs (UT), Chin-Tser Huang (Univ. of South Carolina), Mohamed G. Gouda (UT)

2. 2 Alex X. LiuThe University of Texas at Austin HTTP is stateless Request/ response

3. 3 Alex X. LiuThe University of Texas at Austin Web Application is Stateful Shopping cart

4. 4 Alex X. LiuThe University of Texas at Austin Web Authentication

5. 5 Alex X. LiuThe University of Texas at Austin Cookie  Cookie: data that records state of clients  Cookies need to be secure first request(user/password) subsequent request(cookie) response(cookie) Response(new cookie) … verify user/password verify cookie; if necessary, create a new cookie BrowserServer

6. 6 Alex X. LiuThe University of Texas at Austin Security Requirements of Cookies  Authentication ─ Login phase: verify client by password ─ Subsequent-requests phase: verify client by cookie  Confidentiality ─ Observation: only server need to read cookie content! ─ Low-level: only server and client can read cookie content ─ High-level: only server can read cookie content  Integrity ─ Detect modified cookies  Anti-replay ─ Detect stolen cookies

7. 7 Alex X. LiuThe University of Texas at Austin Efficiency Requirements  No database lookup in verifying a cookie

8. 8 Alex X. LiuThe University of Texas at Austin State of the art  Fu’s cookie scheme:[Fu et al. 2001]  Three security problems: ─ Lack of confidentiality ─ Replay attacks ─ Volume attacks user name|expiration time|data| HMAC( user name|expiration time|data, server key )

9. 9 Alex X. LiuThe University of Texas at Austin Confidentiality  Lack of high-level confidentiality.  Use server key?  [Xu et al. 2002]: store 1 key/user in database ─ Database lookup is inefficient  [Park & Sandhu 2000]: store unique key in cookie ─ Problem: public key cryptography is inefficient  Our solution: use HMAC( user name|expiration time, server key ) as the encryption key user name|expiration time|data| HMAC( user name|expiration time|data, server key )

10. 10 Alex X. LiuThe University of Texas at Austin Replay attacks  To launch replay attacks ─ Steal someone’s cookie (using Trojans, worms, etc) ─ Replay the cookie  Our Solution: make cookie session dependent user name|expiration time|(data) k | HMAC( user name|expiration time|data, server key ) k= HMAC( user name|expiration time, server key ) user name|expiration time|(data) k | HMAC( user name|expiration time|data|session key, server key ) k= HMAC( user name|expiration time, server key )

11. 11 Alex X. LiuThe University of Texas at Austin Volume attacks  Same server key for all cookies – not safe  [Fu 2001] suggests to change server keys periodically ─ For some cookies, we have to verify twice  Our Solution: replace server key by encryption key user name|expiration time|(data) k | HMAC( user name|expiration time|data|session key, server key ) k= HMAC( user name|expiration time, server key ) user name|expiration time|(data) k | HMAC( user name|expiration time|data|session key, k ) k= HMAC( user name|expiration time, server key )

12. 12 Alex X. LiuThe University of Texas at Austin Implementation  Keyed-hash msg auth code: HMAC-SHA1  Encryption: Rijndael-256 algorithm  Server key: 160 bits  HMAC-SHA1 output: 320 bits  Implemented 5 protocols: ─ Insecure cookie protocol ─ Fu’s cookie protocol with low-level confidentiality ─ Our cookie protocol with low-level confidentiality ─ Fu’s cookie protocol with high-level confidentiality ─ Our cookie protocol with high-level confidentiality  Fu’s cookie protocol with high-level confidentiality: use the server key to encrypt data

13. 13 Alex X. LiuThe University of Texas at Austin Setup  Server: medium-load server, 2.4 GHz Celeron, 512MB RAM, Windows server 2003 standard edition, IIS 6.0, PHP 4.3.10, MySQL 2.23  Client: 2.8 GHz Pentium 4, 512 MB RAM, Red Hat 3.0  Link: dedicated gigabit link, RRT=0.9ms  Server creates a new cookie for each request  End-to-end latency: ─ (1) time for transferring request with cookie to server ─ (2) time for verifying the cookie ─ (3) time for creating a new cookie ─ (4) time for transferring response with new cookie to client

14. 14 Alex X. LiuThe University of Texas at Austin Results: impacts on client

15. 15 Alex X. LiuThe University of Texas at Austin Results: impacts on server

16. 16 Alex X. LiuThe University of Texas at Austin Contributions  Discover 3 problems in state-of-art cookie protocol  Propose a cookie protocol that solves those problems  Conduct performance evaluation and comparison  Conclusion: ─ Security: better ─ Performance: close