Hi Michael, You are right that it is not difficult for an attacker to replay UDP datagrams. OpenVPN uses a variant of the "sliding-window" algorithm used by IPSec where each packet is tagged with a unique, incrementing sequence number, allowing any replayed datagrams to be identified and dropped.
Various methods are used to ensure the uniqueness of the sequence number. To prevent the sequence number from wrapping around in static-key mode (which uses a long-term, pre-shared key), the sequence number is 64 bits, where 32 bits is a unix timestamp at daemon initialization and the other 32 bits is an incrementing number. If the incrementing number wraps to 0, then we also update the unix timestamp to the current time. In TLS mode we use 32 bits for the sequence number, with a mandatory re-keying if the sequence number approaches its wrap around value. See packet_id.c for the anti-replay algorithm. While it is true that block cipher chaining is made more complex due to the unreliable nature of UDP transport (where packets can be dropped or received out-of-order), OpenVPN (and IPSec as well)make each datagram atomic and stateless by using an "Explicit IV" where the initialiation vector is explicitly recorded in the datagram header, rather than being implicitly assumed based on the residual IV of the previous datagram. This means that datagrams can be decrypted regardless of the order in which they are received. In CBC cipher mode (the default in OpenVPN), the initial IV on daemon initialization is randomized, and each subsequent datagram is encrypted using the current key and the residual IV of the previous datagram. The uncertainty in the IV combined with the uniqueness of the sequence number ensures that it is highly unlikely that two identical plaintext blocks would encrypt to the same ciphertext. OFB and CFB cipher modes handle the IV slightly differently (using the sequence number as the IV) to ensure that IV collisions never occur. Most of the IV logic can be found in crypto.c. Cut and paste attacks where the datagram ciphertext is modified are made infeasable by the use of a keyed HMAC hash controlled by the --auth option. For several papers on HMAC, see: http://www.cs.ucsd.edu/users/mihir/papers/hmac.html Note that OpenVPN takes the HMAC of the ciphertext rather than the plaintext, so it is not vulnerable to the ssh exploit described here: http://openvpn.sourceforge.net/papers/ssh-security.pdf For additional discussion into the problems of encrypting and authenticating an unreliable data stream (such as UDP), check out the IPSec ESP spec: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt OpenVPN borrows much in the way of theory and concepts from IPSec with the goal of producing a portable, lightweight, user-space VPN implementation. Since IPSec must also deal with securing an unreliable data stream, several concepts have been transferable such as sliding window-based replay protection and explicit IV. For additional theoretical documentation you might want to check out the book Applied Cryptography by Bruce Schneier, which while being an extremely well-written practical guide to cryptography, contains references to a great deal of theoretical material. James ----- Original Message ----- From: "Michael Grigoriev" <m...@nit.ca> To: <openvpn-devel@lists.sourceforge.net> Sent: Thursday, July 18, 2002 4:04 PM Subject: [Openvpn-devel] Replay attacks > Hi all, > > I am wondering how OpenVPN overcomes the inherit vulnerability of UDP > comunications to "replay" or "cut-and-paste" attacks, since it is > impossible to implement cipher block chaining. > Also, if anybody could point me to any theoretical documentation on the > subject, it would be greatly appreciated. > Thanks in advance, > -- mag > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >