lost in translation: theory and practice in cryptography
TRANSCRIPT
Crypto CornerEditors: Peter Gutmann, [email protected]
David Naccache, [email protected] C. Palmer, [email protected]
implementation we recently dis-covered. In response, the UK’sequivalent to CERT, the NationalInfrastructure Coordination Centre(NISCC; www.niscc.gov.uk/niscc/index-en.html) published a vulnera-bility advisory about the flaw.1
Vendors also issued updated recom-mendations to customers, and wesaw a flurry of discussion on Slash-dot 2 (www.slashdot.org) and the sci.crypt3 newsgroup (http://news-reader.org/sci.crypt/). In the after-math, we asked ourselves, how didthis happen?
IPsecIPsec is a suite of protocols that theInternet Engineering Task Force(IETF) developed to provide secu-rity at the Internet layer in theTCP/IP protocol stack. This allowsany application that communicatesover IP to exploit an IPsec deploy-ment without re-engineering itself.Its transparency to end users makesIPsec a popular choice in imple-menting virtual private network(VPN) solutions whereby, over thepublic Internet, a remote user cansecurely access an organization’s in-ternal network, or two geographi-cally disparate networks can connectvirtually and securely (site to site).Implementations of IPsec exist inMicrosoft Windows 2000 and XP,
Mac OS X, all major flavors of Unix,and in the Linux kernel from release2.6 onward. Open-source projectssuch as Openswan (www.openswan.org) and strongSwan (www.strongswan.org) have sprung up, and IPsecis widely supported in commercialnetworking hardware.
IPsec operates in either transportor tunnel mode. In transport mode,end hosts need to be IPsec-aware. Intunnel mode (on which we focushere), a pair of security gateways pro-vide IPsec security services on theend hosts’ behalf, creating a securepacket tunnel across the Internet.This is achieved by cryptographicallyprotecting the original packet (theinner packet), which is then placedinside a new outer packet before it’stransmitted across the Internet. En-capsulating Security Payload (ESP) isan IPsec protocol that provides confi-dentiality and authentication services,whereas the Authentication Header(AH) protocol provides authentica-tion independently. Usually in ESP, ablock-cipher algorithm such as theAdvanced Encryption Standard(AES) is used in cipher-block chain-ing (CBC) mode for bulk encryp-tion. A network administrator canenter encryption keys manually oruse the Internet Key Exchange (IKE)protocol to configure them automat-ically. The security policy database
(SPD) and security association data-base (SADB) contain the informationneeded to decide whether and howeach packet passing through is to beprotected by IPsec.
In 1996, Steve Bellovin4 high-lighted the potential dangers of usingESP without authentication. Yeteight years later, when we took a closelook at the state of the then-currentIPsec standards, we discovered a flawin IPsec that was exactly due to the useof encryption-only ESP, the configu-ration that Bellovin had warnedagainst.5 Based on the IPsec imple-mentation in a version of the Linuxkernel, we developed attacks on theESP protocol in tunnel mode withCBC-mode encryption (that is,without any authentication beingprovided by ESP itself or by AH).This is arguably a common choice forVPN deployments. A network ad-ministrator might reasonably expectthat encryption-only ESP shouldprovide at least confidentiality protec-tion for individual packets, but our at-tacks proved this wasn’t so. Moreover,some configurations using ESP withAH are also vulnerable, as are those inwhich authentication is only suppliedby a higher-layer protocol.
Our attacksOur full paper gives a complete de-scription of our attacks,5 but here’s abrief overview. We assumed the at-tacker could eavesdrop on all com-munications between two securitygateways and inject arbitrary packetsin the tunnel. The attacker’s aim wasto recover the plaintext packets cor-responding to individual encryptedpackets that he or she intercepted.
All our attacks are based on awell-known weakness in CBC-
KENNETH G.PATERSON AND
ARNOLD K.L.YAU
RoyalHolloway,University ofLondon
The perils of using encryption without authentication
or integrity protection are well known in the crypto-
graphic research community. Yet it’s exactly the
mandatory support for unauthenticated encryption
that forms the basis of a serious security flaw in an IPsec
Lost in Translation: Theoryand Practice in Cryptography
PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/06/$20.00 © 2006 IEEE ■ IEEE SECURITY & PRIVACY 69
Crypto Corner
mode encryption known as bit-flipping. The CBC mode’s chainingstructure lets someone introduce oneor more controlled bit flips (1 to 0, orvice versa) in the plaintext at the de-cryption end by making specific cor-responding bit flips in the ciphertext.
In our first attack, the attacker hadsome knowledge about the destina-tion address field in the inner packetswithin the intercepted outer packets.Because the inner packet was en-crypted in CBC mode, he or shecould modify the ciphertext by care-fully flipping bits, such that when thereceiving security gateway decryptedthe inner packet, the inner desti-nation address corresponded to ahost in an attacker-controlled net-work range. The gateway then sim-ply routed the inner packet to theattacker in plaintext.
In our second and third attacks,the attacker modified the source ad-dress and other fields in the innerpacket, thus introducing specifictypes of errors into the inner packet.After processing the inner packet,the security gateway or end host senta “helpful” error message about theencountered error to the host at the
indicated source address. This errormessage contains information aboutthe error type and, crucially, sub-stantial portions of the original innerpacket, all in plaintext. The attackerpicked up these error messages andused them to reconstruct completeplaintext packets.
All these attacks were highly effi-cient and independent of encryptionkey length. Most attack variants couldpotentially perform near-real-timecryptanalysis after a short period ofinitial guesses. Moreover, we provedthat these weren’t just attacks onpaper—we implemented them anddemonstrated that they work in a re-alistic laboratory network setup.
Two main contributing factorsallowed our attacks to work. First,the use of confidentiality-only ESPwithout authentication allowedundetected bit-flipping modifica-tions to the inner packet. Properauthentication would have easilythwarted any bit-flipping by dis-carding modified packets thatfailed to authenticate. Second, andperhaps less obviously, the IPsec ar-chitecture standard specifies checksagainst the IPsec policy in the SPD
and SADB that an IPsec imple-mentation must perform for eachreceived and decrypted innerpacket. These checks would havefailed due to the modified addressfields in the inner packet, and theimplementation should havedropped the modified packet at thatpoint. In Linux, however, thesechecks are absent altogether.
In an attempt to understand theroot causes of this security flaw, wewant to scrutinize the process bywhich the sound and prudent “secu-rity message” the cryptography re-search community advocates is, likea Japanese director’s instructions toan American actor, gradually lost intranslation as it moves from re-searchers to standards developers,from standards developers to soft-ware implementers, and from soft-ware implementers to end users.
Mandatory supportfor unauthenticatedencryptionThe need for authenticated en-cryption is well understood in thecryptographic research commu-nity,6,7 and the lack of authentica-tion has been the basis of manypublished attacks against real-worldprotocols such as Secure SocketShell (SSH),8 Kerberos,9 and Point-to-Point Tunneling Protocol(PPTP).10 In fact, Bellovin discov-ered attacks on an earlier version ofIPsec that are well known by IPsecstandards developers.4
Bellovin’s attacks meant that au-thentication was incorporated in thecurrently deployed version of ESP(ESPv2), as specified in the RFC2406 standard.11 However, the useof authentication is still optional, andimplementations are in fact requiredto support encryption-only ESP. AnIETF standard represents a consen-sus among bodies with variousvested interests,12 so a standardscommittee must trade off even es-tablished cryptographic best prac-tices against other criteria such as
70 IEEE SECURITY & PRIVACY ■ MAY/JUNE 2006
Crypto Corner
flexibility, performance, and back-ward-compatibility. To compensatefor this potentially dangerous trade-off, warnings against the use of ESPwithout authentication have beenplaced in the text of RFC 2406.
Omitted warningsEven if RFC 2406 included warn-ings about encryption-only config-urations with the best of intentions,it isn’t at all clear what the imple-menter should do about them: afterall, providing support for encryp-tion-only ESP is mandatory in thestandard. But the standard providesno clues about whether to preventsuch configuration at the policylevel, for example, or whether topass warnings on to the end user.
Even highly skilled software en-gineers aren’t cryptography experts.Their job is to create (to some de-fined extent) a standards-compliantimplementation, which hopefullyinteroperates well with other sys-tems, all to a hard deadline. Animplementer would, as required,provide support for encryption-onlyESP. Even if a warning registers inthe implementer’s mind, its starknessand potency might have worn offconsiderably after reading through acomplicated set of RFCs. This is es-pecially true in the absence of clearinstructions about how to respondto the warning. Even if implemen-ters understand the warning, theymight reasonably expect that it’stheir job to implement encryption-only ESP, but it’s the end user’s job toconfigure his or her system securely.
Choosingencryption-only ESPLet’s say that Dan, a network admin-istrator, is tasked with setting up aVPN using IPsec. He knows heneeds to set up an encrypted tunnel,and he understands that the DataEncryption Standard (DES) is inse-cure. Still, Dan is unsure. A Googlesearch points him to http://lartc.org/howto/lartc.ipsec.tunnel.html,and he duly follows the line-by-line
instructions, using the providedencryption-only setup, during whichhe encounters no warnings of anykind. After half an hour of setup time,testing, and even running a networksniffer to ensure that the tunneledpackets are indeed encrypted, Dantakes a well-earned coffee break, sat-isfied with a job well done. The pack-ets are triple-DES encrypted anddefinitely getting through. What canpossibly go wrong?
Missing policychecks on LinuxWell, if Dan’s IPsec gateways runon Linux, he could be vulnerableto the devastating attacks describedearlier. Every packet that emergesfrom the tunnel is supposed to besubject to policy checks against theSPD and SADB, but these checkshaven’t been implemented in theofficial Linux kernel release 2.6.8.1that we examined in our work. Infact, these checks aren’t designed tobe a strong cryptographic defenseagainst malicious attacks, andtherefore shouldn’t be relied on toensure security.
Ultimately, the IPsec implementerdidn’t have a fair chance of imple-menting these checks properly in thefirst place anyway—although ESP isspecified in RFC 2406, these policychecks are only mentioned in the ar-chitecture document RFC 2401.13
Even then, RFC 2401 doesn’t explic-itly specify that the offending packetsbe dropped. Without understandingthe implications, the IPsec imple-menter could choose to log the errorand continue to process offending
packets. Normal functional testingwouldn’t reveal this bug because theabsence of these policy checks doesn’thamper IPsec’s operation.
Lessons to be learned Our view is that developers of se-curity standards should take moreresponsibility in ensuring that theirstandards are secure on paper byeliminating any potentially danger-ous choices down the line. Theequivalent of Murphy’s law ininformation security states thatwhenever an insecure configura-tion can be chosen, it inevitablywill be. To help translate standardsinto a secure implementation, anyunnecessary complexity should beavoided. Documentation shouldbe clear, concise, and easy to fol-low. If an important security deci-sion is supposed to be left to theend user, the document should in-struct the implementer to pass allrelevant warnings to the user.None of this contravenes theIETF’s maxim of allowing flexibil-ity in endpoint implementations.
Software security is a specializedfield, and security standard imple-menters should be trained accord-ingly. (Naturally, this is harder toensure in Linux because of its open-source nature.) Having an acute se-curity mindset when writing codehelps prevent security bugs beforeone or more of them become thesubject of a future NISCC advisory.System and network administratorsshould have a good workingknowledge—or even better, a deepunderstanding—of tried and testedinformation security best practices:the difference between security andvulnerability often lies in subtle de-tails, and, as our study of IPsec illus-trates, it’s easy to get them wrong.
N ot unlike Charlotte and her inat-tentive photographer husband in
the movie “Lost in Translation,” thereis a distinct lack of understanding be-
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 71
The equivalent of Murphy’s law in information
security states that whenever an insecure
configuration can be chosen, it inevitably will be.
Crypto Corner
tween the different communities ofcryptography researchers, protocoldevelopers, implementers, and endusers. By choice or necessity, thesecommunities are in a committed rela-tionship, yet because each of them op-erate within their own subculture, usetheir own lingo, and have their ownroles and agendas, they neglect to ap-preciate that other communities workdifferently. Through ignorance, as-sumption, concession, and (mis)inter-pretation, important messages easilyget lost in translation. We would liketo see a greater level of collaborationbetween these communities to bridgethe gulf of understanding, so that noone ever again feels like a stranger in aforeign land.
References1. “NISCC Vulnerability Advisory
IPSEC-004033,” 9 May 2005;www.niscc.gov.uk/niscc/docs/al-20050509-00386.html?lang=en.
2. “Flaw Found in VPN CryptoSecurity,” 13 May 2005; http://it.slashdot.org/article.pl?sid=05/05/13/1420212.
3. “Attacks on IPsec,” 14 May 2005;http://groups.google.com/group/sci.crypt/browse_thread/thread/33dd95c9697f46c4.
4. S.M. Bellovin, “Problem Areas forthe IP Security Protocols,” Proc. 6thUsenix Unix Security Symp., UsenixAssoc., 1996, pp. 1–16.
5. K.G. Paterson and A.K.L. Yau,“Cryptography in Theory and Prac-tice: The Case of Encryption inIPsec,” to be published in Advances inCryptology: EUROCRYPT 2006, S.Vaudenay, ed., Springer-Verlag, 2006;http://eprint.iacr.org/2005/416/.
6. M. Bellare and C. Namprempre,“Authenticated Encryption: Rela-tions among Notions and Analysisof the Generic Composition Para-digm,” Proc. Asiacrypt 2000, LNCS1976, T. Okamoto, ed., Springer-Verlag, 2000, pp. 531–545.
7. J. Black and H. Urtubia, “Side-Channel Attacks on SymmetricEncryption Schemes: The Case forAuthenticated Encryption,” Proc.
11th Usenix Security Symp., UsenixAssoc., 2002, pp. 327–338.
8. M. Bellare, T. Kohno, and C. Nam-prempre, “Breaking and ProvablyRepairing the SSH AuthenticatedEncryption Scheme: A Case Studyof the Encode-then-Encrypt-and-MAC Paradigm,” ACM Trans. Infor-mation and System Security, vol. 7,no. 2, 2004, pp. 206–241.
9. T. Yu, S. Hartman, and K. Rae-burn, “The Perils of Unauth-enticated Encryption: KerberosVersion 4,” Proc. Network and Dis-tributed System Security Symp., Inter-net Soc., 2004; www.isoc.org/isoc/conferences/ndss/04/proceedings/Papers/Yu.pdf.
10. B. Schneier and Mudge, “Crypt-analysis of Microsoft’s Point-to-Point Tunneling Protocol (PPTP),”Proc. 5th ACM Conf. Communica-tions and Computer Security, ACMPress, 1998, pp. 132–141.
11. S. Kent and R. Atkinson, IP Encap-sulating Payload (ESP), IETF RFC2406, Nov. 1998; www.ietf.org/rfc/rfc2406.txt.
12. “The Tao of IETF: A Novice’sGuide to the Internet EngineeringTask Force,” IETF, Aug 2001;www.ietf.org/tao.html.
13. S. Kent and R. Atkinson, SecurityArchitecture for the Internet Protocol,IETF RFC 2401, Nov. 1998; www.ietf.org/rfc/rfc2401.txt.
Kenneth G. Paterson is a professor ofinformation security at Royal Holloway,University of London. His technical inter-ests include cryptography and networksecurity. Paterson has a BSc in mathe-matics from the University of Glasgow anda PhD in mathematics from the Universityof London. He is a member of the IEEEInformation Theory Society and the Inter-national Association for Cryptologic Res-earch, and a fellow of the Institute forMathematics and Its Applications. Con-tact him at [email protected].
Arnold K.L. Yau is a PhD student in theInformation Security Group at Royal Hol-loway, University of London. His techni-cal interests include network security, sidechannel attacks, and modes of operationfor block ciphers. Yau has an MEng incomputing from Imperial College Lon-don. Contact him at [email protected].
72 IEEE SECURITY & PRIVACY ■ MAY/JUNE 2006
How toContact
IEEESecurity &
Privacy
Writers
Visit www.computer.org/security/author.htm or log onto Manuscript Central at http://cs-ieee.manuscriptcentral.com/. Authors must use Manuscript Central to upload theirsubmissions. First-time users must create anew account.
Letters to the Editors
Send letters to Kathy Clark-Fisher, LeadEditor, [email protected]. Pleaseprovide an email address or daytime phonenumber with your letter.
On the Web
Access www.computer.org/security/. To visitour community forum, access www.ieeecommunities.org/securityandprivacy.
Subscription Change of Address (IEEE/CS)
Send change-of-address requests formagazine subscriptions to [email protected]. Be sure to specify S&P.
Subscribe
Visit www.computer.org/subscribe/.
Missing or Damaged Copies
If you are missing an issue or received adamaged copy, contact [email protected].
Reprints of Articles
For price information or to order reprints,send email to [email protected] or fax+1 714 821 4010.
Reprint Permission
To obtain permission to reprint an article,contact William Hagen, IEEE Copyrights andTrademarks Manager, at [email protected].