Enhancing Network Security Against Replay Attacks: An Anti-Replay Window Protocol Strategy

1. Replay Attacks Network Systems Security Mort Anvari

2. A Scenario of Replay Attack • Alice authorizes a transfer of funds from her account to Bob’s account • An eavesdropping adversary makes a copy of this message • Adversary replays this message at some later time

3. Replay Attacks • Adversary takes past messages and plays them again • whole or part of message • to same or different receiver • Encryption algorithms not enough to counter replay attacks

4. Freshness Identifiers • Sender attaches a freshness identifier to message to help receiver determine whether message is fresh • Three types of freshness identifiers • nonces • timestamps • sequence numbers

5. Nonces • A random number generated for a special occasion • Need to be unpredictable and not used before • Disadvantage is not suitable for sending a stream of messages • Mostly used in challenge-response protocols

6. Timestamps • Sender attaches an encrypted real-time timestamp to every message • Receiver decrypts timestamp and compares it with current reading • if difference is sufficiently small, accept message • otherwise discard message • Problem is synchronization between sender and receiver

7. Sequence Numbers • Sender attaches a monotonically increasing counter value to every message • Sender needs to remember last used number and receiver needs to remember largest received number

8. Operation of Sequence Numbers • Sender increments sequence number by 1 after sending a message • Receiver compares sequence number of received message with largest received number • If larger than largest received number, accept message and update largest received number • If less than largest received number, discard message

9. Problem with Sequence Numbers • IPsec uses sequence number to counter replay attacks • However reorder can occur in IP • Messages with larger sequence number may arrive before messages with smaller sequence numbers • When reordered messages with smaller sequence numbers arrive later, they will be discarded

10. Anti-Replay Window Protocolin IPsec • Protect IPsec messages against replay attacks and counter the problem of reorder • Sender puts a sequence number in every message • Receiver uses a sliding window to keep track of the received sequence numbers

11. Anti-Replay Window • w is window size • r is right edge of window • Assume s is sequence number of next received message • Three cases to consider 1 w 2 3 • • • sequence numbers • • • • • • received before right edge r r-w+1 not yet received assumed received

12. Cases of Anti-Replay Window • Case i: if s is smaller than sequence numbers in window, discard message s 1 w s r

13. Cases of Anti-Replay Window • Case ii: s is in window • if s has not been received yet, then deliver message s • if s has been received, then discard message s 1 w s s r (discard) (deliver)

14. r s Cases of Anti-Replay Window • Case iii: if s is larger than sequence numbers in window, then deliver message s and slide the window so that s becomes its new right edge window before shift 1 1 w w window after shift

15. Properties of Protocol • Discrimination: • receiver delivers at most one copy of every message sent by sender • w-Delivery: • receiver delivers at least one copy of each message that is neither lost nor suffered a reorder of degree w or more, where w is window size

16. s Problem with Anti-Replay Window • Receiver gets s, where s >> r • Window shifts to right • Many good messages that arrive later will be discarded window before shift window after shift 1 w 1 w r discarded good msgs

17. Automatic Shift vs. Controlled Shift • Automatic shift: window automatically shifts to the right to cover the newly received sequence number without any consideration of how far the newly received sequence number is ahead • Controlled shift: if the newly received sequence number is far ahead, discard it without shifting window in the hope that those skipped sequence numbers may arrive later

18. Three Properties of Controlled Shift • Adaptability • receiver determines whether to sacrifice a newly received message according to the current characteristics of the environment • Rationality • receiver sacrifices only when messages that could be saved are more than messages that are sacrificed • Sensibility • receiver stops sacrificing if it senses that the messages it means to save are not likely to come

19. Additional Case with Controlled Shift • Case iv: s is more than w positions to the right of window • receiver estimates number of good messages it is going to lose if it shifts the window to s • if the estimate is larger than d+1, where d is the counter of discarded messages, and d+1 is less than dmax, then receiver discards this message and increments d by 1 • otherwise, receiver delivers the message, shifts the window to the right, and resets d to 0

20. Another Problem with Anti-Replay Window • Computer may reset due to transient fault • If either sender or receiver is reset and restarts from 0, then synchronization on sequence numbers is lost

21. Scenario of Sender Reset • If p is reset, unbounded number of fresh messages are discarded by q p q seq# : 50 seq# : 50 49 48 3 2 1 0 • • • reset seq# : 0 fresh yet discarded by q

22. Scenario of Receiver Reset • If q is reset, it can accept unbounded number of replayed messages inserted by adversary p q seq# : 50 seq# : 50 49 48 3 2 1 0 • • • reset seq# : 0 replayed yet accepted by q

23. Overcome Reset Problems • IPsec Working Group: if reset, the SA is deleted and a new one is established -- very expensive • Our solution: periodically push current state of SA into persistent memory; if reset, restore state of SA from this memory

24. SAVE and FETCH • When SAVE is executed, the last sequence number or right edge of window will be stored in persistent memory • When FETCH is executed, the last stored sequence number or right edge of window will be loaded from persistent memory into memory

25. SAVE at Sender • s is sequence number at p • Every Kp messages, p executes SAVE(s) to store current s in persistent memory • In spite of execution delay, SAVE(s) is guaranteed to complete before message numbered s+Kp is sent

26. FETCH at Sender • When p wakes up after reset, p executes FETCH(s) to fetch s stored in persistent memory • After FETCH(s) completes, p executes SAVE(s+2Kp) and waits • After SAVE(s+2Kp) completes, p can send next message using seq# s+2Kp

27. Convergence of Sender • Assume when p resets, SAVE(s) has not yet completed, and the last sent seq# is s+t, t < Kp • When p wakes up, s-Kp will be fetched • Therefore, adding 2Kp to fetched seq# guarantees that next sent seq# is fresh

28. Results of SAVE and FETCH • When p is reset, some sequence numbers will be abandoned by p, but no message sent from p to q will be discarded provided no message reorder occurs • When q is reset, the number of discarded messages is bounded by Kq • When p or q is reset, no replayed message will be accepted by q

29. Next Class • Address Resolution Protocol (ARP) and its security problems • Secure ARP • Read paper on website