AuthenticatedEncryptionandSecureChannels

KennyPaterson

InformationSecurityGroup

@kennyog;www.isg.rhul.ac.uk/~kp

Overview

Monday:

•  Securechannelsandtheirproperties•  Securityforsymmetricencryption–fromblockcipherstoAEAD

Tuesday:

•  TLS•  SSH2

TLSOverview

IntroducingTLS

SSL=SecureSocketsLayer.DevelopedbyNetscapeinmid1990s.

SSLv2deprecated,SSLv3broken;bothwidelysupportedonservers.

TLS=TransportLayerSecurity.IETF-standardisedversionofSSL.

TLS1.0=SSLv3withminortweaks,RFC2246(1999).

TLS1.1=TLS1.0+tweaks,RFC4346(2006).

TLS1.2=TLS1.1+moretweaks,RFC5246(2008).

TLS1.3=majorredesigncurrentlyunderwayinTLSWGofIETF.

44

IntroducingTLS

Originallyforsecuree-commerce,nowusedmuchmorewidely.Retailcustomeraccesstoonlinebankingfacilities.

Useraccesstogmail,facebook,Yahoo.

Mobileapplications,includingbankingapps.

Paymentinfrastructures.

User-to-cloud.

PostSnowden:back-endoperationsforGoogle,Yahoo,…

TLShasbecomethedefactosecureprotocolofchoice.Usedbyhundredsofmillionsofpeopleanddeviceseveryday.

55

HighlySimplifiedViewofTLS

Client Server HandshakeProtocol

RecordProtocol

Usedbyclientandserverto1. Negotiateciphersuite2. Authenticate3. EstablishkeysusedintheRecordProtocol

ProvidesconfidentialityandauthenticityofapplicationlayerdatausingkeysfromHandshakeProtocol

66

TLSProtocolArchitecture

TCP

Record Protocol

Handshake Protocol

Alert Protocol

HTTP, other apps

Change Cipher Spec

Protocol

7

TheTLSEcosystem(1/3)

•  Servers•  Includingmanagedserviceproviders(CloudFlare,Akamai)

•  Clients•  Ofallshapesandsizes

•  Certificationserviceproviders•  Ofallshapes,sizesandlevelsofsecurity

•  Softwarevendors•  FromGoogledowntoone-manopen-sourceoperations

•  OpenSSLsomewherein-between•  Hardwarevendors

88

TheTLSEcosystem(2/3)

•  TLSversions:•  SSL3.0,TLS1.0,TLS1.1,TLS1.2

•  ManyserversevenstillsupportSSL2.0(-->DROWNattack)

•  200+ciphersuites•  https://www.thesprawl.org/research/tls-and-ssl-cipher-suites

•  Somequitecommon,e.g.TLS_RSA_WITH_AES_128_CBC_SHA256

•  Somemoreesoteric,e.g.TLS_KRB5_WITH_3DES_EDE_CBC_MD5

•  Some offering no security: TLS_NULL_WITH_NULL_NULL!

•  TLSextensions•  Toonumeroustomention.

•  DTLS99

TheTLSEcosystem(3/3)

•  IETFTLSWorkingGroup•  AlsoIETFUTAWorkingGroup(UTA=UsingTLSinApplications)

•  AndCFRG(CryptoForumResearchGroup)

•  Growingcommunityofresearchers

•  TheTLSecosystemhasbecomeverycomplexandvibrant.

1010

TheTLSEcosystem(4/3)(bonusslide)

11

ANewsworthyProtocol

TLShasbeeninthenews…..BEAST(2011),CRIME(2012),Lucky13(2013),RC4attacks(2013),POODLE(2014),RC4(again)(2015),AES-GCMwithbadrandomness(2016),SWEET32(2016),

Renegotiationattack(2009),tripleHandshakeattack(2014),FREAKandLOGJAM(2015),SLOTH(2016),DROWN(2016),…

Poorqualityofimplementations(particularlyincertificatehandling).

“WhyEveandMalloryLoveAndroid”(2012)

“Themostdangerouscodeintheworld”(2012)

Applegotofail(2013)

GnuTLScertificateprocessingbug(2013)

Truncationandcookiecutterattacks(2013,2014)

OpenSSLCCSbug(2014)

Frankencerts(2014)

Mostlytechpress,withlimitedcrossovertomainstreammedia.

1212

ANewsworthyProtocol

TLShasreallybeeninthenews…..

….Heartbleedbug.

•  Pressurebuiltandthedamfinallybroke?

•  Severityofthethreat:leakageofprivateinformation,inc.serverprivatekeys+widespreaduseofOpenSSL.

•  Practicaldemonstrationofthreat.

•  Agoodlogo!

1313

TLSProtocolArchitecture

TCP

Record Protocol

Handshake Protocol

Alert Protocol

HTTP, other apps

Change Cipher Spec

Protocol

14

TLSRecordProtocol

TLSRecordProtocolprovides:-  Dataoriginauthentication,integrityusingaMAC.

-  Confidentialityusingasymmetricencryptionalgorithm.

-  Anti-replayusingsequencenumbersprotectedbytheMAC.

-  Optionalcompression.

-  Fragmentationofapplicationlayermessages(butnotreassembly!).

-  Astreaminginterfacetocallingapplications.

15

TLSRecordProtocol:MAC-Encode-Encrypt

MAC

SQN||HDR Payload

Padding

Encrypt

Ciphertext

MACtagPayload

HDR

MAC HMAC-MD5, HMAC-SHA1, HMAC-SHA256

Encrypt CBC-AES128, CBC-AES256, CBC-3DES, RC4-128

1616Padding “00” or “01 01” or “02 02 02” or …. or “FF FF….FF”

OperationofTLSRecordProtocol

•  Datafromlayeraboveisreceivedandpartitionedintofragments(maxsize214bytes).

•  Optionaldatacompression.

•  Defaultoptionisnocompression.

•  CalculateMAConsequencenumber,headerfields,anddata,andappendMACtodata.

•  Pad(ifneededbyencryptionmode),thenencrypt.

•  Prepend5-byteheader,containing:

•  Contenttype(1byte,indicatingcontentofrecord,e.g.handshakemessage,applicationmessage,etc),

•  SSL/TLSversion(2bytes),

•  Lengthoffragment(2bytes).

•  SubmittoTCP.

17

OperationofTLSRecordProtocol

In-boundprocessingstepsreversesthesesteps:1.Receivemessage,oflengthspecifiedinHDR.2.Decrypt.3.Removepadding.4.CheckMAC.5.(Decompresspayload.)6.Passpayloadtoupperlayer

(note:nodefragmentation;TLSprovidesastreamoffragmentstotheapplication).

Errorscanarisefromanyofdecryption,paddingremovalorMACcheckingsteps.AllofthesearefatalerrorsinTLS.

18

AEADandTLSRecordProtocol

MEEonlyforallversionsofSSLandTLSuptoTLS1.1.

•  Security?

DedicatedAuthenticatedEncryptionwithAssociatedData(AEAD)algorithmswereaddedinTLS1.2.

•  Singlealgorithmprovidingbothconfidentialityandintegrity/dataorigin(authentication)

•  NeednotconformtoMEEtemplate.

•  GeneralAEADinterfacespecifiedinRFC5116.

•  AES-GCMspecifiedinRFC5288.

•  AES-CCMspecifiedinRFC6655.

19

20

AEADandTLSRecordProtocol

TLS1.2supportonmajorwebsites:

9/2012:5%;9/2013:17%;9/2014:43%;9/2015:66%;9/2016:79%

(source:sslpulse)

TLS1.2supportinbrowsers:

Chrome:sincerelease30.

Firefox:sincerelease28.

IE:sinceIE11.

Safari:sinceiOS5andOSX10.9.

(source:wikipedia,Nov.2013)

20

HistoricalAEADUsageinTLS

SnapshotfromICSICertificateNotaryProject(Sept.2014):

21

16.3%

1.6%

CurrentAEADUsageinTLS

SnapshotfromICSICertificateNotaryProject(Aug.2016):

22

>60%

1.2%

BEAST

24

BEAST

•  IVchaining:uselastblockofpreviousciphertextasIV.

•  DefaultinCBCmodeforSSLv3andTLS1.0.

•  Leadstoachosen-plaintextdistinguishingattackagainstTLS.•  FirstobservedforCBCmodeingeneralbyRogawayin1995.

•  ApplicationtoTLSnotedbyDaiandMöllerin2004.

•  ExtendedtotheoreticalplaintextrecoveryattackbyBardin2004/2006.

•  TurnedintoapracticalplaintextrecoveryattackonHTTPcookiesbyDuongandRizzoin2011–theBEAST.•  BEAST=BrowserExploitAgainstSSL/TLS

•  16-yeardemonstrationthatattacksdogetbetterwithtime.

24

25

Ci-1 Ci

Pi-1 Pi

dK dK

Pi-1 Pi

Ci-1 Ci

eK eK

InitialisationVector(IV):•  DefinesC0forprocessingfirst

block.•  ChainedIVsarecommonin

applications,andinSSL3.0andTLS1.oinparticular.

•  TLS1.1and1.2requireIVtoberandom.

CBCmodeneedssomeformofpaddingifplaintextlengthsarenotmultipleofblocklength.•  Moreonpaddinglater.

CBCModeReminder

26

AttackingChainedIVs

26

SupposeattackerwishestodistinguishencryptionsofsingleblocksP0,P1.AttackermakesLoRencryptionqueryformessagepair(P0,P1).

AttackerreceivesciphertextC=C1formessagePbwheresomeknown,previousblockC0wasusedastheIV.

Pb

C0 C1

eK

27

AttackingChainedIVs

27

C1willbeusedastheIVforthenextencryption.AttackernowmakesLoRqueryonmessageP0⊕C0⊕C1.AttackerreceivessingleblockciphertextC2.

Pb

C0 C1

eK

P0⊕C0⊕C1

C2

eK

AttackingChainedIVs

Pb

C0 C1

eK

P0⊕C0⊕C1

C2

eK

•  IfPb=P0,theninputstoblockcipherarethesameinbothencryptions.

•  Hence,ifPb=P0,thenC1=C2.•  Otherwise,ifPb=P1,thenC1≠C2.•  SolookingatC1andC2givesusatesttodistinguish

encryptionsofP0andP1.28

AttackingChainedIVs

Distinguishingattackextendseasilytomulti-blockmessages.

BreaksCBCmodeintheIND-CPAsecuritymodel.

SoIVchainingforCBCmodeisbrokenintheory.

HowcanweturnthisintoapracticalattackonTLS?

•  Wewantplaintextrecoveryratherthanadistinguishingattack.

•  Weneedtofindawaytorealisethechosenplaintextrequirement.

29

TheBEAST–Part1

•  AssumebytesP0,P1,…P14areknown,trytorecoverP15.•  UseP 0 P 1…P14asfirst15bytesofP’.•  Iterateover256possiblevaluesinP’15.•  P’15=P15ifandonlyifC1=C2.•  Soaverageof128trials(eachinvolvingonechosenplaintext)toextractP15

whenremainingbytesinblockareknown.

C0 C1

eK

P’⊕C0⊕C1

C2

eK

P0…P14

P15

30

TheBEAST–Part2

NowassumeattackercancontrolpositionofunknownbytesinstreamwithrespecttoCBCblockboundaries(chosenboundaryprivilege).Repeatprevioussingle-byterecoveryattackwithslidingbytes.

Green:initiallyknownbytes.Red:unknown(target)bytes.Orange:recoveredbytes.

P10 P11 T0 P12 P13 P14 T1 T2 T3 T4 T5 P9 P8 P7 P5 P6 …

P10 P11 T0 P12 P13 P14 T1 T2 T3 T4 T5 P9 P8 P7 P5 P6 …

P10 P11 T0 P12 P13 P14 T1 T2 T3 T4 T5 P9 P8 P7 P5 P6 …

P4 P3 P1 P2 P0

P4 P3 P1 P2 P0

P4 P3 P1 P2 P0

…

…

…

P10 P11 T0 P12 P13 P14 T1 T2 T3 T4 T5 P9 P8 P7 P5 P6 … P4 P3 P1 P2 P0 …

31

TheBEAST–Part3

Browser

TLStunnelCookiefor

remotesite

32

33

BEAST–KeyFeatures

•  BEASTJavaScriptloadedaheadoftimeintoclientbrowserfromcompromisedormaliciouswesbite.

•  Provideschosen-plaintextcapability.•  AttacktargetisHTTPsecurecookie.•  JavaScriptusesHTTPpaddingtocontrolpositionsofunknownbytes

(chosenboundaryprivilege).•  Difficulttogetfinecontroloverbyte/blockpositions.•  Needtobeabletoinjectchosenplaintextblockattheverystartof

RecordProtocolmessages.•  JavaScriptalsoneedstocommunicatewithMITMattacker.

•  Summary:it’scomplicated,butitcanbemadetowork.**Givenazero-dayinthebrowser!

33

34

BEAST–Impact

•  TheBEASTwasamajorheadacheforTLSvendors.•  Perceivedtobearealisticattack.•  Mostclientimplementationswere“stuck”atTLS1.0.

•  Bestsolution:switchtousingTLS1.1or1.2.•  UsesrandomIVs,soattackprevented.•  Buttheseversionwerenotwidelysupportedserver-sideattimeof

attack.

•  ForTLS1.0,varioushacksweredone:•  Use1/n-1recordsplittinginclient.

•  Nowimplementedinmostbrowsers.•  Send0-lengthdummyrecordaheadofeachrealrecord.

•  Breakssomeimplementations.•  OrswitchtousingRC4?

34

35

BEAST–Lessons

•  Atheoreticalvulnerabilitypointedoutin1995becamea“practical”attackin2011.•  Attacksreallydogetbetter(worse!)withtime.•  Practitionersreallyshouldlistento(some)theoreticians.•  And,inthiscase,theydid:TLS1.1and1.2userandomIVs.•  Problemwasthatno-onewasusingtheseversionsin2011.

•  Toolsfromthewidersecurityfieldwereneededtomaketheattacksheadlinenews.•  Man-in-the-browserviaJavascript.•  FairgamegiventhehugerangeofwaysinwhichTLSgetused.•  Maybethosetoolscanbeusedelsewhere?

35

PaddingOracleAttacks

TLSRecordProtocol:MAC-Encode-Encrypt

MAC

SQN||HDR Payload

Padding

Encrypt

Ciphertext

MACtagPayload

HDR

MAC HMAC-MD5, HMAC-SHA1, HMAC-SHA256

Encrypt CBC-AES128, CBC-AES256, CBC-3DES, RC4-128

3737Padding “00” or “01 01” or “02 02 02” or …. or “FF FF….FF”

TLSRecordProtocolPadding

PaddinginTLS1.0anduphasaparticularformat:–  Alwaysaddatleast1byteofpadding.–  Iftbytesareneeded,thenaddtcopiesofthebyterepresentationoft-1.

–  SopossiblepaddingpatternsinTLSare: 00; 0101; 020202;…-  SSLv3hasweakerformatrequirements:

00; ??01; ????02;….38

TLSRecordProtocolPadding

•  VariablelengthpaddingispermittedinallversionsofTLS(butnotinSSL).

•  Upto256bytesofpaddingintotal: FFFF….FF

•  FromTLS1.0:Lengthslongerthannecessarymightbedesirabletofrustrateattacksonaprotocolbasedonanalysisofthelengthsofexchangedmessages.

39

HandlingPaddingDuringDecryption

•  TLS1.0erroralert:decryption_failed:ATLSCiphertextdecryptedinaninvalidway:eitheritwasn`tanevenmultipleoftheblocklengthoritspaddingvalues,whenchecked,weren’tcorrect.Thismessageisalwaysfatal.

•  Suggestspaddingformatshouldbechecked,butwithoutspecifyingexactlywhatchecksshouldbedone.

•  LegacyofSSLv3,wherenocheckingcanbedonebecauseoflooserequirementsonpaddingformat.

40

ExploitingWeakPaddingChecks–MöllerAttack

SSL/TLSdecryptionsequence:CBCmodedecrypt,removepadding,checkMAC.

[M04]:failuretocheckpaddingformatleadstoasimpleattackrecoveringthelastbyteofplaintextfromanyblock.

Assumptionsfortheattack:•  AttackerhasaspecialTLSciphertextcontainingacompleteblockof

padding.

•  SoMACendsonblockboundaryforthisciphertext.

•  Paddingisremovedbyinspectinglastbyteonly(cfSSLv3).

41

MöllerAttack

42

Ct-1 Ct

dK dK

Ct-2

dK

…

…

Blocks from special ciphertext

Byte value is “0F” here

MöllerAttack

43

Ct-1 C*

dK dK

Decryption succeeds if and only if byte value is “0F” here

Target ciphertext block from stream

Ct-2

dK

…

…

Blocks from special ciphertext

Enabling recovery of last byte of dK(C*) here.

MöllerAttack

•  Decryptionsucceedsifandonlyif:

Ct-1⊕dK(C*)=(??,??,....??,0F)

•  Failureofdecryptionresultsinvisibleerrormessage.

•  HenceattackercanrecoverlastbyteofdK(C*)withprobability1/256.

•  SuccessenablesrecoveryoflastbyteoforiginalplaintextP*correspondingtoC*intheCBCstream,bysolvingsystemofeqns:

Ct-1⊕dK(C*)=(??,??,....??,0F)

C*-1⊕dK(C*)=P*

whereC*-1istheblockprecedingC*inthestream.

44

POODLEattack

45

•  InSSLv3,noformatcheckingispossible!•  SoMöller’sattackalreadybreaksCBCmodeinSSLv3.•  CombinewithBEASTideastomovetargetplaintextbytesinto

correctpositionforattackone-by-one.•  ResultingcombinationoftechniquesisknownasthePOODLE

attack(Duongetal.2014).•  POODLE=PaddingOracleonDowngradeLegacyAttack•  https://www.openssl.org/~bodo/ssl-poodle.pdf•  Nozero-dayvulnerabilityisneeded.•  10yearsfromMöller’soriginalobservationtoPOODLE.

POODLEattack

46

•  ThereisnoeffectivecountermeasuretoPOODLEattack.•  Receivercannotdomorerigorouspaddingchecks,becausesendercannot

bereliedupontouseTLSformatinSSL!

•  CannotswitchtoRC4becausethat’salsobroken.•  SothisPOODLEkillsSSLv3.What’stheproblem?NomodernbrowserrequestsSSLv3!•  SSL/TLSversionnegotiationmechanismisnotproperly

implementedbymanyservers.•  AnactiveMITMattackercandowngradeclientandservertoSSLv3

byspoofingserverresponsesinSSL/TLShandshake.•  OnlysolutionistocompletelyremoveSSLv3supportinbrowsers.

FullPaddingCheck

•  InTLS1.1andup:

Eachuint8inthepaddingdatavectorMUSTbefilledwiththepaddinglengthvalue.ThereceiverMUSTcheckthispadding….

•  Sodecryptionchecksthatbytesattheendoftheplaintexthaveoneofthefollowingformats:

00;

01,01;

02,02,02;

….

FF,FF,………..FF;

andoutputsanerrorifnoneoftheseformatsisfound.

•  NBOther“sanity”checksmayalsobeneededduringdecryption.

47

PaddingOracles

48 48

•  Vaudenay[V02]proposedtheconceptofapaddingoracle.

C

Valid/Invalid

•  Vaudenayshowedthat,forCBCmodeandforcertainpaddingschemes,apaddingoraclecanbeusedtobuildadecryptionoracle!

PaddingOracle

P=DecK(C)

CheckpaddingofP

PaddingOracleAttackforTLSPadding

Ct-1 Ct

Pt-1 Pt

dK dK

XOR with various Δ here and submit to padding oracle

Eventually produces valid pad “00” here

Recovering true plaintext byte via Pt ⊕ Δ = (…. 00)

49

PaddingOracleAttackforTLSPadding

Ct-1 Ct

Pt-1 Pt

dK dK

XOR with Δ1Δ0 here and submit to oracle

Eventually produces valid pattern “01 01” here

This byte now set to “01” by setting Δ0:=Δ ⊕ 01

Recovering true plaintext byte via

Pt ⊕ (…..Δ1Δ0) = (….0101)

50

PaddingOracleAttackforTLSPadding

•  Anaverageof128trialsareneededtoextractthelastbyteofeachplaintextblock.

•  Canextendtotheentireblock,withanaverageof128trialsperbyte.

•  Canextendtotheentireciphertext.•  Becauseattackercanplaceanytargetblockaslastblockofciphertext.

51

TLSPaddingOraclesInPractice?

•  InTLS,anerrormessageduringdecryptioncanarisefromeitherafailureofthepaddingcheckoraMACfailure.

•  Vaudenay’spaddingoracleattackwillproduceanerrorofonetypeortheother.

•  Paddingfailureindicatesincorrectpadding.

•  MACfailureindicatescorrectpadding.

•  Iftheseerrorsaredistinguishable,thenapaddingoracleattackshouldbepossible.

52

TLSPaddingOraclesInPractice?

Goodnews(fortheattacker):

•  TheerrormessagesarisinginTLS1.0aredifferent:•  bad_record_mac

•  decryption_failed

Badnews:

•  Buttheerrormessagesareencrypted,socannotbeseenbytheattacker.

•  Andanerrorofeithertypeisfatal,leadingtoimmediateterminationoftheTLSsession.

•  53

TLSPaddingOraclesInPractice?

Canveletal.[CHVV03]:•  Recallthesequence:decrypt,checkpadding,checkMAC.•  AMACfailureerrormessagewillappearonthenetworklaterthan

apaddingfailureerrormessage.•  BecauseanimplementationwouldonlybothertochecktheMACif

thepaddingisgood.

•  Sotimingtheappearanceoferrormessagesmightgiveustherequiredpaddingoracle.

•  Eveniftheerrormessagesareencrypted!

•  Amplifythetimingdifferencebyusinglongmessages.

•  Buttheerrorsarefatal,soitseemstheattackercanstillonlylearn

onebyteofplaintext,andthenwithprobabilityonly1/256.

54

OpenSSLandPaddingOracles

Canveletal.[CHVV03]:

•  TheattackercanstilldecryptreliablyifafixedplaintextisrepeatedinafixedlocationacrossmanyTLSsessions.

•  e.g.passwordinloginprotocoloranHTTPsessioncookie.

•  Amulti-sessionattack.

•  Modernviewpoint:useBEAST-stylemalwaretogeneratetherequiredencryptions.

•  TheOpenSSLimplementationhadadetectabletimingdifference.

•  Roughly2msdifferenceforlongmessages(closeto214bytemaximum).

•  EnablingrecoveryofTLS-protectedOutlookpasswordsinabout3hours.

55

Multi-sessionVersion

Ct-1 Ct

Pt-1 Pt

dK dK

XOR with various Δ here and submit for decryption

Eventually produces valid pad “00” here

Recovering true plaintext byte via Pt ⊕ Δ = (…. 00)

56

Ct-1, Ct vary in each trial, but Pt is fixed

57

PaddingOracleAttackCountermeasures?

•  RedesignTLS:•  Pad-MAC-EncryptorPad-Encrypt-MAC.

•  Tooinvasive,didnothappen.

•  SwitchtoRC4?

•  Oraddafixtoensureuniformerrors:•  CheckaMACanyway,evenifthepaddingisbad.

•  Ifattackercan’ttelldifferencebetweenMACandpaderrors,thenmaybeTLS’sMEEconstructionissecure?

•  FixincludedinTLS1.1and1.2specifications.

57

PaddingOraclesPost[CHVV03]

•  RegardedasasolvedproblemforSSL/TLS.

•  Steadytrickleofotherpapersshowingpaddingoracleattacksinothersystems,e.g.

•  ISOstandardforCBC-modeencryption[PY04,YPM05].

•  TraileroracleattackonIPsec[DP07,DP10]

•  POETattackonASP.NET[DR10].

•  XMLencryption[JS11].

•  OpenSSLimplementationofDTLS[AP12].

58

Lucky13Attack

60

PaddingOracleCountermeasures,Revisited

Responsetotimingattacksin[V02,CHVV03]fromtheTLS1.1and1.2specifications:

…implementationsMUSTensurethatrecordprocessingtimeisessentiallythesamewhetherornotthepaddingiscorrect.Ingeneral,thebestwaytodothisistocomputetheMACevenifthepaddingisincorrect,andonlythenrejectthepacket.ComputetheMAConwhatthough?

60

TLSRecordProtocol:MAC-Encode-Encrypt

MAC

SQN||HDR Payload

Padding

Encrypt

Ciphertext

MACtagPayload

HDR

Problemis:howtoparseplaintextaspayload,paddingandMACfieldswhenthepaddingisnotoneoftheexpectedpatterns00,0101,…?

6161

62

EnsuringUniformErrors

FromtheTLS1.1and1.2specifications:Forinstance,ifthepadappearstobeincorrect,theimplementationmightassumeazero-lengthpadandthencomputetheMAC.•  Thisapproachwasadoptedinmanyimplementations,

includingOpenSSL,NSS(Chrome,Firefox),BouncyCastle,OpenJDK,…

•  Otherapproachespossible(e.g.GnuTLS).

62

63

EnsuringUniformErrors

…Thisleavesasmalltimingchannel,sinceMACperformancedependstosomeextentonthesizeofthedatafragment,butitisnotbelievedtobelargeenoughtobeexploitable,duetothelargeblocksizeofexistingMACsandthesmallsizeofthetimingsignal.

63

64

EnsuringUniformErrors

…Thisleavesasmalltimingchannel,sinceMACperformancedependstosomeextentonthesizeofthedatafragment,butitisnotbelievedtobelargeenoughtobeexploitable,duetothelargeblocksizeofexistingMACsandthesmallsizeofthetimingsignal.

64

65

Lucky13:DistinguishingAttack

65

CK C’

C=EncK(M) MiseitherR287||00orR32||FF256

K

•  AdversaryinterceptsC,mauls,andforwardsontorecipient.•  Timetakentorespondwitherrormessagewillindicate

whetherM=R287||00orM=R32||FF256.•  Ciphertext-onlydistinguishingattack.

Lucky13DistinguishingAttack–Choose

RR…..……….……………R00

FFFF………………………….FF

R

R

C

CIV

IV

66

Lucky13DistinguishingAttack–Maul

RR…..……….……………R00

FFFF………………………….FF

R

R

CIV

CIV

67

Lucky13DistinguishingAttack–Inject

RR…..……….……………R00

FFFF………………………….FF

R

R

C’IV

C’IV

1-bytevalidpadding20-byteMAC267-bytemessage

256-bytevalidpadding20-byteMAC12-bytemessage

68

Lucky13DistinguishingAttack–Decrypt

RR…..……….……..RR

R

CIV

CIV

69

RR…..……….……..RR

R

SlowMACverification

FastMACverification

Timingdifference:4SHA-1compressionfunctionevaluations

SQN||HDR

SQN||HDR

280bytes

25bytes

Lucky13DistinguishingAttack–Decrypt

70

Lucky13–ExperimentalResultsforDistinguishingAttack

71

Prob

abil

ity

1.50�106 1.51�106 1.52�106 1.53�106 1.54�106 1.55�106 1.56�106 1.57�1060

0.00001

0.00002

0.00003

0.00004

0.00005

0.00006

Hardware Cycles �Calculated by Attacker⇥OpenSSLv1.0.1onserverrunningat1.87Ghz.

100MbitLAN.

Differenceinmeansiscirca3.2μs.

Lucky13–SuccessProbabilityforDistinguishingAttack

72

NumberofSessions SuccessProbability

1 0.756

4 0.858

16 0.951

64 0.992

128 1

73

Lucky13–PlaintextRecovery

73

XOR 2-byte Δ here and submit for decryption

Produces valid patterns “01 01”

(or longer valid pad) or “00”,

OR bad pad.

Ct

Pt

dK

Ct-1

dK

R2 R1

dK dK

IV

(HMAC-SHA-1+AES-CBC)

Target ciphertext block from

stream

74

Case1:“0101”(orlongervalidpad)

74

Ct

Pt

dK

Ct-1

dK

R2 R1

dK dK

IV

XOR 2-byte Δ here and submit for decryption

SQN||HDR

13+16+16+10=55bytes 20bytes

4SHA-1compressionfunctionevaluations

“01 01” (or longer valid pad)

75

Case2:“00”

75

Ct

Pt

dK

Ct-1

dK

R2 R1

dK dK

IV

XOR 2-byte Δ here and submit for decryption

SQN||HDR

56bytes 20bytes

5SHA-1compressionfunctionevaluations

“00”

76

Case3:Badpadding

76

Ct

Pt

dK

Ct-1

dK

R2 R1

dK dK

IV

XOR 2-byte Δ here and submit for decryption

SQN||HDR

57bytes 20bytes

5SHA-1compressionfunctionevaluations

zero-length pad

77

Lucky13–PlaintextRecovery

77

Theinjectedciphertextcausesbadpaddingand/orabadMAC.ThisleadstoaTLSerrormessage,whichtheattackertimes.

Thereisatimingdifferencebetween“0101”caseandtheother2cases.AsingleSHA-1compressionfunctionevaluation.

Roughly1000clockcycles,circa1μsontypicalprocessor.

Measurabledifferenceonsamehost,LAN,orafewhopsaway.

(Comparewithoriginalpaddingoracleattack:2ms.)

Detectingthe“0101”caseallowslast2plaintextbytesinthetargetblockCttoberecovered.

UsingthestandardCBCalgebra:Pt ⊕ (…..Δ1Δ0) = (….0101).

Attackthenextendstoallbytesasinastandardpaddingoracleattack.

78

Lucky13–PlaintextRecovery

78

Weneed216attemptstotryall2-byteΔvalues.

Andweneedaround27trialsforeachΔvaluetoreliablydistinguishthedifferentevents.

(Actualnoiseleveldependsonexperimentalset-up.)

EachtrialkillstheTLSsession.

Hencetheheadlineattackcostis223sessions,allencryptingthesameplaintext.

Seemsrathertheoretical?

79

Lucky13–Improvements(AttacksGetBetter!)

79

If1-out-of-2lastplaintextbytesknown,thenweonlyneed28attemptsperbyte.

Iftheplaintextisbase64encoded,thenweonlyneed26attemptsperbyte.

And27trialsperattempttode-noise,foratotalof213.

BEAST-styleattacktargetingHTTPcookies.

Maliciousclient-sideJavascriptmakesHTTPGETrequests.

TLSsessionsareautomaticallygeneratedandHTTPcookiesattached.

GETrequestsare“padded”sothat1-out-of-2conditionalwaysholds.

Costofattackis213GETrequestsperbyteofcookie.

Nowapracticalattack!

80

Lucky13–ExperimentalResults

80

Hard

ware

Cycl

es�Cal

cula

tedby

Adve

rsar

y⇥

⇥15 � 0xFE

0 50 100 150 200 2501.286⇤106

1.287⇤106

1.288⇤106

1.289⇤106

1.290⇤106

1.291⇤106

1.292⇤106

�15Byte14ofplaintextsetto01;byte15settoFF.

ModifyΔinposition15.

OpenSSLv1.0.1onserverrunningat1.87Ghz,100MbitLAN.

Mediantimes(noisenotshown).

81

Lucky13–Countermeasures

81

Wereallyneedconstant-timedecryptionforTLS-CBC.

Adddummyhashcompressionfunctioncomputationswhenpaddingisgoodtoensuretotalisthesameaswhenpaddingisbad.

Adddummypaddingcheckstoensurenumberofiterationsdoneisindependentofpaddinglengthand/orcorrectnessofpadding.

Watchoutforlengthsanitycheckstoo.

Needtoensurethere’senoughspaceforsomeplaintextafterremovingpaddingandMAC,butwithoutleakinganyinformationaboutamountofpaddingremoved.

PerformanceofBasicCountermeasures

82

Prob

abil

ity

1.50�106 1.51�106 1.52�106 1.53�106 1.54�106 1.55�106 1.56�106 1.57�1060

0.00001

0.00002

0.00003

0.00004

0.00005

0.00006

Hardware Cycles �Calculated by Attacker⇥Pr

obab

ilit

y1.54�106 1.55�106 1.56�106 1.57�106 1.58�106 1.59�106 1.60�106 1.61�1060

0.00001

0.00002

0.00003

0.00004

0.00005

0.00006

Hardware Cycles �Calculated by Attacker⇥

Before After

83

ConstantTimeDecryptionforMEE

•  Better,butstillnotperfect.

•  Distinguishingattackstillpossible.

•  Properconstant-time,constant-memoryaccessimplementationisreallyneeded.

•  Challengingtotestpaddingcorrectnessanddosanitycheckingwithoutbranchingonsecretdata.

•  SeeAdamLangley’sblogpostat:

https://www.imperialviolet.org/2013/02/04/luckythirteen.html

forfulldetailsonhowLucky13wasfixedinOpenSSLandNSS.

83

84

Lucky13–Impact

84

OpenSSLpatchedinversions1.0.1d,1.0.0kand0.9.8y,released05/02/2013.

NSS(Firefox,Chrome)patchedinversion3.14.3,released15/02/2013.

Apple:patchedinOSXv10.8.5(iOSversiontbd).

Operapatchedinversion12.13,released30/01/2013

OraclereleasedaspecialcriticalpatchupdateofJavaSE,19/02/2013.

BouncyCastlepatchedinversion1.48,10/02/2013

AlsoGnuTLS,PolarSSL,CyaSSL,MatrixSSL.

Microsoft“determinedthattheissuehadbeenadequatelyaddressedinpreviousmodificationstotheirTLSandDTLSimplementation”.

(Fulldetailsat:www.isg.rhul.ac.uk/tls/lucky13.html)

85

SecurityproofforMEEinTLS

85

Theorem([PRS11],informalstatement)SupposeEisablockcipherwithblocksizenthatisSPRP-secure.SupposeMAChastagsizetandisPRF-secure.SupposethatforallmessagesMqueriedbytheadversary:

|M|+t≥n.

ThenMEEwithCBCmodeencryption,randomIVs,TLSpadding,anduniformerrorsprovidesAEsecurity.

C0 C1

eK

C2

eK

C3

eK

86

Lucky13–Lessons

86

TLS’sMAC-Encode-Encryptconstructionishardtoimplementsecurelyandhardtoprovepositivesecurityresultsabout.

Longhistoryofattacksandfixes.

Eachfixwasthe“easiestoptionatthetime”.

Nowreachedpointwherea500linepatchtoOpenSSLwasneededtofullyeliminatetheLucky13attack.

BettertouseanEtMconstructionfromdayone,oreatthecostofswitchingatthefirstsignoftrouble.

Aconservativeapproachseemsmeritedforsuchanimportantprotocol.

AtthetimeTLSwasfirstdesigned,EtMversusMtEdebatewasnotsoclearcut.

CurrentStatusandFutureDevelopmentsinTLS

CurrentStatus–CBC-mode

MostCBC-modeimplementationshavebeenpatchedagainstBEASTandLucky13,butreputationhasbeendamagedbylongseriesofattacks.

•  Largeecosystemandtrickinessofproperpatchmeansthatnoteveryimplementationispatchedtothesamedegree.

•  Variantattacksarediscoveredfromtime-to-time.

•  Lucky13strikesagain–flushandreloadattacks[IIES15].•  LuckymicrosecondsonAWSs2n[AP16].

•  ErrorinLucky13countermeasureinOpenSSLNIcodepath[S16].

Relativeperformancealsoanissue(HMACquiteslowcomparedtomodernMACalgorithms).

88

CurrentStatus–RC4

RC4isnearlydeadforHTTPoverTLS

•  Usagehasdroppedfrom50%to1-2%since2013.

•  ButstillwidelyusedinotherTLSapplications,e.g.STARTTLSforSMTP.

AES-GCMandAES-CCMareavailableforTLS1.2.

•  TLS1.2isnowsupportedinallmajorbrowsersandinmajorityofhightrafficwebservers(wikipedia,sslpulse).

•  Morethan60%ofTLStrafficisusingTLS1.2(ICSICertificateNotary).

89

CurrentStatus–AES-GCM

AES-GCMistrickytoimplementsecurelypurelyinsoftware.•  Mainissueisavoidingleakageofhashkeyviaside-channelattack.

•  Alsoneedside-channelresistantimplementationofAES.

AES-GCMisrelativelyfast

•  EspeciallywithAES-NIandPCLMULQDQinstructions(IntelandAMD).

•  2.53to1.03cyclesperbyte,dependingonprocessor.

http://2013.diac.cr.yp.to/slides/gueron.pdf

•  RoughlytwiceasfastasAES-CBC+HMAC-SHA-*

•  ButOCBwouldbeevenfaster!

90

Otherdevelopments

ChaCha20-Poly1305definedinIETFRFC7905.•  ImportantforenvironmentswhereAESisnotavailableinhardware.

•  ChaCha20isastreamcipher;Poly1305aMACalgorithmbasedonpolynomialhashing.

•  CombinationisagoodAEADschemeassumingChaCha20isideal[P14].

•  Smallamountofusagecurrently.

ReformofMEEtoEtMtomakeCBC-modeeasiertoimplementsecurely.

•  RFC7366.

•  DeploymentviaTLSextension,unclearhowwidelyadopteditwillbecome.

91

92

TLS1.3

TLS1.3isnownearingcompletioninIETFTLSWG.

•  ReducinglatencyinHandshake.

•  SimplificationofkeyexchangeandauthenticationmethodsinHandshake.

•  Servername/identityhiding/handshakeencryptionforimprovedprivacy(?)

•  Reformofsymmetricalgorithms–AEADonly.

92

SSH

IntroductiontoSSH

94

Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices. Used primarily on Linux and Unix based systems to access shell accounts, SSH was designed as a replacement for TELNET and other insecure remote shells, which send information, notably passwords, in plaintext, leaving them open for interception. The encryption used by SSH provides confidentiality and integrity of data over an insecure network, such as the Internet.

– Wikipedia

SSHBinaryPacketProtocol(RFC4253)

•  Encode-then-E&Mconstruction,statefulbecauseofinclusionof4-bytesequencenumber.

•  Packetlengthfieldmeasuresthesizeofthepacket:|PadLen|+|Payload|+|Padding|.•  Encrypted,sosequenceofencryptedpacketslookslikealongstringofrandombytes.

•  EncryptionoptionsinRFC4253:CBCmode;RC4.•  AES-CTRdefinedinRFC4344.95

Encrypt

PRF-MAC

Payload

Ciphertext MAC tag

Sequence Number 4

Packet Length 4

Pad Len 1

Padding ≥4

CBCmodeinSSH

96

•  RFC4253mandates3DES-CBCandrecommendsAES-CBC.

•  SSHusesachainedIVinCBCmode:–  IVforcurrentpacketisthelast

ciphertextblockfromthepreviouspacket.

–  EffectivelycreatesasinglestreamofdatafrommultipleSSHpackets.

Ci-1 Ci

Pi-1 Pi

dK dK

Pi-1 Pi

Ci-1 Ci

eK eK

CTRmodeinSSH

97

•  CTRmodeusesblockciphertobuildastreamcipher.

•  CTRmodeforSSHisstandardisedinRFC4344.•  Initialvalueofcounteris

obtainedfromhandshakeprotocol.

•  Counterrunsacrosspackets.•  Packetformatispreservedfrom

CBCcase.•  RFCrecommendsuseofAES-

CTRwith128,192and256-bitkeys,and3DES-CTR.

Ci

eK

Pi

ctr+i

Pi

eK

Ci

ctr+i

SSHBinaryPacketProtocol(RFC4253)

•  IVchainingattack:•  Chosenplaintext,distinguishingattackduetoRogaway,appliedtoSSHin[BKN04].•  NotfullyrealisticforSSHbecauseofformatrequirementsonthefirstblockof

plaintextandbecauseofchosenplaintextrequirement.•  ConstructionwithrandomIVsisIND-sfCCAsecure[BKN04].

98

Encrypt

PRF-MAC

Payload

Ciphertext MAC tag

Sequence Number 4

Packet Length 4

Pad Len 1

Padding ≥4

SSHBinaryPacketProtocol(RFC4253)

•  Howdoesdecryptionwork?•  Recall:receivergetsastreamofbytes,andasingleciphertext

canbefragmentedoverseveralTCPmessages.

99

Encrypt

PRF-MAC

Payload

Ciphertext MAC tag

Sequence Number 4

Packet Length 4

Pad Len 1

Padding ≥4

BreakingCBCmodeinSSH[APW09]

100

IV Ci*

P0’

dK

•  Thereceiverwilltreatthefirst32bitsofthecalculatedplaintextblockasthepacketlengthfieldforthenewpacket.

•  Here: P0’=IV⊕dK(Ci*)whereIVisknown.

Targetciphertextblockfromstream

Lengthfield

BreakingCBCmodeinSSH[APW09]

101

IV Ci*

P0’

dK

R R

P2’

dK dK

P1’

Theattackerthenfeedsrandomblockstothereceiver–  Oneblockatatime,waitingtoseewhathappensattheserver

wheneachnewblockisprocessed–  ThisispossiblebecauseSSHrunsoverTCPandtriestodoonline

processingofincomingblocks

BreakingCBCmodeinSSH[APW09]

102

IV Ci*

P0’

dK

•  Onceenoughdatahasarrived,thereceiverwillreceivewhatitthinksistheMACtag–  TheMACcheckwillfailwithoverwhelmingprobability–  Consequentlytheconnectionisterminated(withanerrormessage)

•  Howmuchdatais“enough”sothatthereceiverdecidestochecktheMAC?

•  Answer:whateverisspecifiedinthelengthfield:

R R

P2’

dK dK

P1’

MAC tag

BreakingCBCmodeinSSH[APW09]

103

IV Ci*

P0’

dK

Ci-1* Ci

*

Pi*

dK

•  KnowingIVand32bitsofP0’,theattackercannowrecover

32bitsofthetargetplaintextblockPi*:

Pi*=Ci-1

*⊕dK(Ci*)=Ci-1

*⊕IV⊕P0’

Furtherdetails

•  Theattackasdescribedrequirestheinjectionofcirca231bytesofciphertext(expectedvalueoflengthfield).

•  Itrecovers32bitsofplaintextwithprobability1.

•  AndleadstoanSSHconnectionteardown(onMACfailure).

•  TheattackworkswithrandomIVstoo,breakingtheschemethatwasprovensecurein[BKN04].

•  Somethingwentwrongsomewhere!

104

Furtherdetails–Lengthchecking

•  RFC4253requiresimplementationstocheckthatlengthfieldis“reasonable”.

•  Detailsareimplementation-specific.

•  Backin2009,theleadingimplementationwasOpenSSH,thenatversion5.1.

•  AccordingtoSSHwebpage,80%ofserversontheInternetwereusingOpenSSHaroundthattime.

105

Furtherdetails–LengthcheckinginOpenSSH

•  OpenSSH5.1performstwolengthchecksonthelengthfield(LF)whendecryptingthefirstciphertextblock:

•  Check1:5≤LF≤218.

•  Check2:totallength(4+LF)isamultipleoftheblocksize:

LF+4modBL=0.

•  Eachcheckproducesadifferenterrormessageonthenetwork,distinguishablebyattacker.

•  Ifbothcheckspass,thenOpenSSHwaitsformorebytes,thenperformsMACcheck,resultinginathirdkindoferrormessage.

106

Furtherdetails–LengthcheckinginOpenSSH

•  Check1(5≤LF≤218)passeswithprobabilityapprox.2-14.

•  Ifitpasses,thenwithhighprobability,14MSBsofLFare“0”.•  Pass/faildetectableviaerrormessage.

•  Henceattackwithsuccessprob.2-14recovering14bitsofconfirmedplaintext.

•  Check2(LF+4modBL=0)passeswithprobability1/BL,typically2-3or2-4.•  Ifitpasses,thensome(3or4)LSBsofLFarerevealed.

•  Pass/faildetectableviaerrormessage/connectionenteringwaitstate.

•  Ifwaitstateisentered,thentheattackproceedsasbefore.

•  Overall,theattackonOpenSSH5.1recovers32bitsofplaintextwithprob.2-18(forBL=16)andrequiresinjectionofatmost218bytesofdata.

107

Doestheattackmatter?

•  Ontheonehand,theattackhaslowsuccessrate,onlyrecovers32bitsofplaintext,andcausestheSSHconnectiontoabort.

•  Ontheotherhand,anattackercanapplytheattacktomanyconnections,boostinghisoverallsuccessrate.

•  Canalsoiteratetheattackagainstclientsthatperformauto-reconnects.

•  ThinkaboutwhatkindsofdataSSHmightbeprotecting.•  SSHwasmeanttobebullet-proof;theattackshoweditwasnot.

•  ItlefttheprovablesecurityoftheSSHBPPunresolved.108

Countermeasurestotheattack

•  AbandonCBC-mode?•  Alternativesavailableatthattime:CTR,RC4.

•  DropbearimplementedCTRandrelegatedCBCmodeinversion0.53.

•  Developnewmodes?•  ModesbasedonGenericEtM,AES-GCM,ChaCha20-Poly1305

weresubsequentlyaddedtoOpenSSH.

•  PatchCBC-mode?•  OpenSSH5.2alsointroducedapatchtostopthespecificattack

onCBCmode.

109

TheOpenSSHpatch

•  Basicidea:hidetheerrorsfromtheadversary.•  Ifthelengthchecksfail,donotsendanerrormessage,but

waituntil218byteshavearrived,thenchecktheMAC.

•  Ifthelengthcheckspass,buttheMACcheckeventuallyfails,thenwaituntil218byteshavearrived,thenchecktheMAC.

•  Noerrormessageiseversentuntil218bytesofciphertexthavearrived.

•  CannolongercountbytestoseehowmanyarerequiredtotriggerMACfailure.

110

TheorylessonfromtheSSHattack

•  Modelusedforsecurityproofin[BKN04]wasinadequate.

•  Itassumedlengthwasknownandatomicprocessingofciphertexts.

•  ButfragmentedadversarialdeliveryofciphertextoverTCPispossible.

•  Implementationshavetodecryptfirstblocktofindouthowlongplaintextismeanttobe,andactonitbeforeperforminganyauthentication.

•  That’snotreflectedinanyoftheAE/AEADsecuritymodels!

111

MoreSSHsecurityanalysis

•  [PW10]:bespokesecuritymodelforCTRmodeinSSHandproveditsecure(assumingblockcipherisaPRP).

•  [BDPS12]:generalframeworkforstudying“SymmetricEncryptionschemessupportingfragmenteddecryption”likethoseusedinSSH.•  IND-sfCFAallowstheattackertodeliverciphertexttoa

decryptionoracleinasymbol-by-symbolfashionandobserveanyerrors/messageoutputs.

•  [BDPS12]alsoidentifiedadditionalsecuritypropertiesthatSSHattemptstoprovide:•  BoundaryHiding(BH)andDenial-of-Serviceresistance.

112

TheStateofAEADinSSHToday

ThestateofAEADinSSHtoday

•  In[ADHP16],weperformedameasurementstudyofSSHdeployment.

•  WeconductedtwoIPv4addressspacescansinNov/Dec2015andJan2016usingZGrab/ZMap.

•  GrabbingbannersandSSHservers’preferredciphers.•  ActualcipherusedinagivenSSHconnectiondependsonclient

andserverpreferences.

•  Roughly224serversfoundineachscan.

•  Nmapfingerprintingsuggestsmostlyembeddedrouters,firewalls.

114

ThestateofAEADinSSHtoday:SSHversions

115

MostlyOpenSSHanddropbear;others

lessthan5%.

ThestateofAEADinSSHtoday:SSHversions

116

Dropbearat56-58%.886kolderthanversion0.53,sovulnerabletovariantof2009CBC-

modeattack!

ThestateofAEADinSSHtoday:SSHversions

117

OpenSSHat37-39%.130-166kolderthanversion5.2andprefer

CBCmode,sovulnerableto2009

attack!

ThestateofAEADinSSHtoday:SSHversions

•  DropbearnowdominatesOpenSSH.•  Butmaybeswitchingbackagain:ComcastcableIPaddress

rangedroppedfrom2M+devicesrunningDropbear(Feb2016)to83k(May2016).

•  Longtailofoldsoftwareversions.•  MostpopularversionofOpenSSHisversion5.3,releasedOct

2009(currentversionis7.2).

•  DeterminedbymajorLinuxdistros?

•  SignificantpercentageofDropbearandOpenSSHserversarepotentiallystillvulnerabletothe2009attack.•  8.4%forDropbear.

118

ThestateofAEADinSSHtoday:preferredalgorithms

119

OpenSSH preferred algorithms

•  Lotsofdiversity,surprisingamountof“genericEtM”(gEtM).

•  CTRdominates,followedbyCBC.

•  ChaCha20-Poly1305ontherise?(becamedefaultinOpenSSH6.9).

•  SmallamountofGCM.

ThestateofAEADinSSHtoday:preferredalgorithms

120

Dropbear preferred algorithms

•  LessdiversitythanOpenSSH.

•  CTRdominates,followedatalongdistancebyCBC.

•  No“exotic”options.

ANewAttackonCBCmodeinOpenSSH

TheOpenSSHpatch

•  Version5.2+CBCmodepreferredbyroughly20kOpenSSHservers.

•  RecalltheOpenSSHpatch,inversion5.2andup:•  Ifthelengthchecksfail,donotsendanerrormessage,butwait

until218byteshavearrived,thenchecktheMAC.

•  Ifthelengthcheckspass,buttheMACcheckeventuallyfails,thenwaituntil218byteshavearrived,thenchecktheMAC.

•  OneMACcheckisdoneiflengthchecksfail:on218bytes.

•  TwoMACchecksaredoneiflengthcheckspass:oneonroughlyLFbytes,theotheron218bytes.

122

AttackingtheOpenSSHpatch[ADHP16]

•  ThisleadstoatimingattackonCBCmodeinOpenSSH5.2andup:1. InjecttargetciphertextblockCi

*.2. Thensend218bytesasquicklyaspossibletoserver.

3. TimethearrivaloftheMACfailuremessage.

•  FastarrivalindicatesthatlengthchecksfailedandoneMACcomputation.

•  SlowarrivalindicatesthatthelengthcheckspassedandtwoMACcomputations.

•  Thisleaks18bitsofinformationaboutthelengthfield,andhence18bitsaboutthetargetblock.

123

AttackingtheOpenSSHpatch[ADHP16]

•  Sizeoftimingdifference:•  AMACcomputationonroughly217bytes(theexpectedvalueofLF).

•  ForHMAC-SHA1,thisrequires211hashcompressionfunctionevaluations.

•  cf.Lucky13timingdifference:asinglehashcompressionfunction!

•  Remoteattackercaneasilydetectdifference.

•  Successprobabilityoftheattack:•  Needtopassbothlengthchecks,so2-18.

•  Canincreasesuccessrategivenpartialplaintextknowledgeintargetblock.

•  (Idea:waitfortherightIVbeforemountingtheattack;moresevereattackforrandom,explicitIVversion.)

124

AttackingtheOpenSSHpatch[ADHP16]

•  Increasenumberofplaintextbitsrecoveredbyusingfiner-grainedtiminginformation.•  BecausethetimingdelayisproportionaltothevalueofLF.

•  Iftiminggranularity=1compressionfunctionevaluation,thenwecanrecoverupto30bitsofplaintextfromtargetblock.

•  Challenging,butnotimpossibleinco-residentattackerscenario.

•  Possiblecountermeasuretotheattack:ifMACfails,thencomputesecondMACon218–LFbytesinsteadofonall218bytes.

•  StillleavesresidualtimingdifferencebecauseoffinedetailsofHMAC.

•  Reallyneedconstanttimeimplementationofdecryptionalgorithmtoeliminatethisclassofattack.

125

Disclosureoftheattack

•  WenotifiedtheOpenSSHteamoftheattack(5/5/16).

•  “…wedonotfeelthatanemergencyreleaseisnecessary,northattheattackremainsecretaheadofsucharelease.”

•  TheyaddedcountermeasuresinOpenSSH7.3(1/8/16).

•  OpenSSHhassteadilybeendeprecatingoldalgorithmsandmodes.

•  CBCmodewasalreadydisabledbydefaultinOpenSSH6.7(butcanbere-enabled).

•  ButOpenSSHcannotforcepeopletostopusingoldversionsofthesoftware.

126

SecurityanalysisofotherSSHandOpenSSHmodes–CTR,gEtM,AES-GCM,ChaCha20Poly1305

SecurityanalysisofotherOpenSSHencryptionmodes

•  In[ADHP16],wealsousetheframeworkof[BDPS12]toprovesecuritypropertiesofgEtM,AES-GCM,andChaCha20-Poly1305inOpenSSH.

•  Theframeworkallowsfragmenteddecryptioncapability,multipledecryptionerrors,etc.

• Wefoundasubtleerrorinthesecuritymodelsin[BDPS12].

• Wealsoextendedthemodelstoincludeintegrityaswellasconfidentiality.

128

SecurityanalysisofotherOpenSSHencryptionmodes

gEtMandAES-GCMinOpenSSH:•  DerivedfromAEADschemeswithAD=lengthfield(nowunencrypted).

•  Hencesanitycheckingoflengthfieldcannotrevealanythingusefultoadversary.

•  IssueingEtMcode:

•  MACiscomputedoncetheciphertexthasarrivedbutisnotcomparedtoreceivedMACuntilafterdecryption.

•  Henceanyerrorsarisingduringdecryptionstepwillbesignalledtoattacker.

•  Arisesfromsharedcode-pathandreuseoflegacyE&Mcode.

•  Notasecuritythreatforanycurrentlyspecifiedencryptionschemes.

•  FixedinOpenSSH7.3.

•  Both(fixed)gEtMandAES-GCMareprovablysecure:achievingIND-sfCFA,INT-sfCFAsecurity.

129

ChaCha20-Poly1305inOpenSSH

130

Payload

MAC tag

SQN 4

Packet Length 4

Pad Len 1

Padding ≥4

C1 C2

K1IV = SQN||064 ChaCha20 ChaCha20

K2IV = SQN||0631

ChaCha20 K2

IV = SQN||0630

0256

KpolyPoly1305

SecurityanalysisofChaCha20-Poly1305inOpenSSH

•  ChaCha20-Poly1305inOpenSSH:•  64-bytekeyissplitintotwohalves,K1,K2.

•  K1usedtoencryptSSHlengthfieldusingChaCha20.

•  K2usedtoencrypteverythingelse,alsousingChaCha20.

•  Poly1305MACkeyisobtainedas:

ChaCha20(K2,IV=SQN||0630,M=0256).

•  MACappliedtobothciphertextcomponents.

•  Analysismorecomplexbecauseofencryptedlengthfield.

•  Ideaisthatusingseparatekeysforencryptinglengthfieldandthereststopsattacks.

•  CTRmodeanalysisshowsthistobeunnecessary.

131

Closingremarks

133

Closingremarks

•  Onceabadcryptographicchoiceisoutthereinimplementations,it’sveryhardtoundo.

•  OldversionsofTLShangaroundforalongtime.

•  ThereisnoTLSproductrecallprogramme!

•  SlowuptakeofTLS1.1,1.2.

•  TLShascomeundersustainedpressurefromattacks.

•  BEAST,Lucky13andRC4attackshaveprovidedincentivestomovetoTLS1.2andinfluencedthedesignofTLS1.3.

•  Attacksare“semi-practical”butweignoresuchattacksatourperil.

•  GoodvendorresponsetoLucky13viapatching,slowerresponsetoRC4attacksviaswitchingoffsupport.

133

Closingremarks

•  Goodalgorithmdesignishard.

•  Butsoisgoodprotocoldesign.•  Attacksareusuallyobviousinretrospect,butfinding

themisnotsoeasy.

•  Keepinmindthevalueofattacksonpaperversusattacksinpractice.

•  Implementedattacksareneededtoconvincepractitioners.

•  Butanon-paperattackisoftentheharbingerofapracticalattack.

134

Closingremarks

• We’veseentheevolutionfromsimplesecuritymodelsforsymmetricencryptiontomoresophisticatedsecuritynotionsforsecurechannels.

•  ThecryptographycommunityisfocussedonAEADasanendgoal.

•  AEADisanimportanttoolbutnotthesamethingasasecurechannel.

135