private communication middleware architecture d1...d1.1 - private communication middleware...

D1.1-Privatecommunicationmiddlewarearchitecture 1

Private communication middleware architecture

D1.1

Project reference no. 653884

February 2016


Documentinformation

Scheduleddelivery 01.03.2016Actualdelivery 01.03.2016Version 1.0ResponsiblePartner INESC-ID

Disseminationlevel

Public

Revisionhistory

Date Editor Status Version Changes 23.12.2015 M.Correia Draft 0.1 Initialversion04.01.2016 S.Totakura Draft 0.2 Revisedversion17.02.2016 M.Pardal Draft 0.3 Revisedversion26.02.2016 M.Pardal Final 1.0 Reviewerscommentsincorporated.

Contributors

MiguelPardal(INESC-ID)MiguelCorreia(INESC-ID)SreeHarshaTotakura(TUM)GeorgCarle(TUM)KaranBalu(INESC-ID)AndréJoaquim(INESC-ID)DiogoRaposo(INESC-ID)

Internalreviewers

V.Schiavoni(UniNE)K.Tarbe(CYBER)

AcknowledgementsThis project is partially funded by the European Commission Horizon 2020 workprogrammeundergrantagreementno.653884.MoreinformationAdditional information and public deliverables of SafeCloud can be found athttp://www.safecloud-project.eu


Glossaryofacronyms

Acronym DefinitionAPI ApplicationProgrammingInterfaceAS AutonomousSystemBSD BerkeleySocketsDistributionBGP BorderGatewayProtocolCA CertificationAuthorityCBC CipherBlockChainingCN CertificateNotaryCRL CertificationRevocationListDES DataEncryptionStandardDHE Diffie-HellmanENISA EuropeanNetworkandInformationSecurityAgencyHMAC HashedMessageAuthenticationCodeICMP InternetControlMessageProtocolIDS IntrusionDetectionSystemIETF InternetEngineeringTaskForceIP InternetProtocolIPsec IPSecurityIV InitializationVectorMAC MessageAuthenticationCodeMD MessageDigestNIST NationalInstituteofStandardsandTechnologyMPTCP Multi-PathTCPOSI OpenSystemsInterconnectionPKI Public-KeyInfrastructureRFC RequestforCommentsRIR RegionalInternetRegistrarsRMS RelayMembershipServiceSCCA SafeCloudClientAgentSCCL SafeCloudClientLibrarySCRWP SafeCloudReverseWebProxySCSA SafeCloudServerAgentSCSL SafeCloudServerLibrarySCWP SafeCloudWebProxySCSV SignalingCipherSuiteValue(SCSV)SHA SecureHashAlgorithmSSL SecureSocketsLayerSSH SecureShellTCP TransmissionControlProtocolTLS TransportLayerSecurityTTL TimeToLiveUDP UserDatagramProtocol


Tableofcontents

Documentinformation................................................................................................................................2

Disseminationlevel......................................................................................................................................2

Revisionhistory.............................................................................................................................................2

Contributors....................................................................................................................................................2

Internalreviewers........................................................................................................................................2

Acknowledgements.......................................................................................................................................2

Moreinformation..........................................................................................................................................2

Glossaryofacronyms...................................................................................................................................3

Tableofcontents...........................................................................................................................................4

Executivesummary.......................................................................................................................................6

2 Threats.....................................................................................................................................................7

2.1 Securechannelcomponentvulnerabilities..............................................................................................7

2.1.1 Vulnerabilitiesinasymmetricciphermechanisms...................................................................7

2.1.2 Vulnerabilitiesinsymmetricciphermechanisms.....................................................................8

2.1.3 Vulnerabilitiesinhashfunctions.......................................................................................................9

2.1.4 SSL/TLSvulnerabilities.......................................................................................................................10

2.2 Serviceidentification.......................................................................................................................................11

2.3 Man-in-the-middleattacks...........................................................................................................................12

2.4 Routehijacking..................................................................................................................................................13

3 Services..................................................................................................................................................16

3.1 Vulnerability-tolerantchannels.................................................................................................................17

3.1.1 Description................................................................................................................................................17

3.1.2 Components..............................................................................................................................................19

3.1.3 API.................................................................................................................................................................19

3.2 Protectedserviceprovisioning....................................................................................................................20

3.2.1 Description................................................................................................................................................20

3.2.2 Components..............................................................................................................................................21


3.2.3 API.................................................................................................................................................................23

3.3 Routemonitoring..............................................................................................................................................24

3.3.1 Description................................................................................................................................................25

3.3.2 Components..............................................................................................................................................25

3.3.3 API.................................................................................................................................................................26

3.4 Multi-pathcommunication...........................................................................................................................27

3.4.1 Description................................................................................................................................................27

3.4.2 Components..............................................................................................................................................28

3.4.3 API.................................................................................................................................................................29

4 Architecture.........................................................................................................................................30

4.1 Middlewareentities.........................................................................................................................................30

4.2 Topologicalarchitecture...............................................................................................................................31

4.3 Softwarearchitecture.....................................................................................................................................34

4.3.1 Userendpoints........................................................................................................................................34

4.3.2 Othercomponents.................................................................................................................................35

4.4 API...........................................................................................................................................................................36

5 Conclusion............................................................................................................................................37

6 References............................................................................................................................................38


Executivesummary

Data communication is an important source of concerns about privacy andconfidentiality.Forexample,inrecentmonthsalarmswereraisedabout:weaknessesincryptographic algorithms used to encrypt communications, attacks against thealgorithm used to agree upon shared keys in TLS, the deviation of huge chunks ofInternettraffictofarawaycountries,andtheespionageoftrafficinsidethenetworksofmajor cloud computing providers. All these issues are related to communicationinsecurityandprivacyleaks.

The objective of work packageWP1 is to providemiddleware services to improve theprivacyandsecurityofcloudcommunicationsintheSafeCloudarchitecture.Thepurposeofthesecommunicationservicesistoprovidethesamepropertiesassecurechannels–confidentiality, integrity, and authenticity – plus availability, but assuming powerfuladversaries that may be able to break some of the assumptions that make existingchannels secure. An example of such a broken assumption is to consider that theDiffie-Hellman key exchange is secure, proved wrong recently by the Logjam attack[ABD+15].

Thepresentdeliverable(D1.1)isthefirstofWP1.Itpresentsapreliminarydesignofthesecurecommunicationmiddleware:thethreatsitassumes,theserviceitwillprovide,anditsarchitecture.

Themiddlewareisconcernedwithtwoformsofcommunication:machine-to-cloudandcloud-to-cloud. SafeCloud does not envisage the need to protect data privacy inmulticast, anycast or broadcast communications, so the middleware provides onlyunicastcommunication,i.e.,communicationbetweentwoendpoints.Theseendpointscanbe user terminals, computers in the clouds, among others. Communication isconnection-oriented,similarlytoprotocols likeTCPorSSL,aswealsodonotenvisagetheneedtosupportdatagramcommunication(e.g.,asUDP).

Themiddleware is implemented at the application layer of the OSImodel and of theInternetprotocolstack,followingtheend-to-endargument(mostcomplexityshouldbeimplemented at the higher layers of the protocol stack) and practical considerationsabout thedifficultyof implementingmechanismsat lower layers in the Internet(fromthe network layer down changes may be needed in equipment of Internet serviceproviders,whichisunpractical).

Thisdeliverableisorganizedasfollows.

• Section 2 presents the threats that the middleware has to tackle, i.e., theproblemsithastosolveoratleastmitigate.

• Section3presentstheservicesthatthemiddlewarewillprovide,explaininghowtheyaddressthethreatsofSection2.

• Section4presentsthearchitectureofthemiddleware.• Finally,Section5concludesthereport.


2 Threats

As mentioned in the previous section, we aim to provide security despite powerfuladversaries thatmaybeable tobreak someof theusual assumptionsmadeby securechannelsolutionssuchasSSL/TLS,IPsec,andSSH.Specifically,weconsiderfourthreats,whichweexplaininthefollowingsections:

• Securechannelcomponentvulnerabilities: secure channels (e.g., TLS, IPsec)arebasedoncomponentsthatmaybevulnerable(e.g.,RC4,MD5,SHA-1);

• Service identification: servers that offer services via well-known ports arevulnerabletoattacksthatidentifyservices(portscanning/fingerprinting);

• Man-in-the-middleattacks:anattackermayimpersonateanendpoint identityand thereby defeat security mechanisms that keep the communication to theendpointsecure;

• Routehijacking:trafficmaybedeviatedandtheneavesdropped.

WeconsiderasmainexampleofsecurechannelprotocolthewidelyadoptedTransportLayer Security (TLS) [DR08]. Originally called Secure Sockets Layer (SSL), its firstversion was SSL 2.0, released in 1995. SSL 3.0 was released in 1996, bringingimprovements to its predecessor such as allowing forward secrecy and supportingSHA-1[FKC11].Definedin1999,TLSdidnotintroducemajorchangestoSSL,buttheywereenoughtomakeTLS1.0incompatiblewithSSL3.0.Inordertograntcompatibility,aTLS1.0connectioncanbedowngradedtoSSL3.0,bringingsecurityissues(cf.Section2.1.4). TLS 1.1 and TLS 1.2 are upgrades that brought some improvements such asmitigatingCBC(cipherblockchaining)attacksandsupportingmoreblockciphermodesof operation to use with AES. TLS is divided into two sub-protocols, Handshake andRecord, constituted by several mechanisms each. The Handshake protocol is used toestablish or re-establish communication between a server and a client. The Recordprotocolisusedtoprotectthemessagessentandreceived.

2.1 Securechannelcomponentvulnerabilities

This section provides an argument that secure channels may be vulnerable becausetheircomponentsmaycontainvulnerabilities(Sections2.1.1-2.1.3)ortheprotocolitselfmaybevulnerable(Section2.1.4).

2.1.1 Vulnerabilitiesinasymmetricciphermechanisms

ProposedbyRivestetal.in1978,RSAisacryptographicmechanismusedtocipherandsignmessagesordata[RSA78].RSA'ssecurityisbasedontwoproblems:factorizationoflarge integers and the RSA problem (the task of performing an RSA private-keyoperationgivenonlythepublickey)[MOV96].RSA'sstrengthisinverselyproportionaltotheavailablecomputationalpower.Astheyearspass,it isexpectedthatperformingthe factorization of large integers becomes a feasible task. RSA will be broken whenthoseproblemscanbesolvedwithinapracticalamountoftime.

Kleinjungetal.performedthe factorizationofRSA-768,aRSAnumberwith232digits[KAF+10].Theresearchersstatethattheyspentalmosttwoyearsinthewholeprocess,which is clearly a non-feasible time. Factorizing a large integer is a very differentconcept frombreakingRSA.RSA is still secure.Asof2010, the researchers concluded


that RSA-1024 would be factored within five years, i.e., in 2015. As for now, nofactorizationofRSA-1024hasbeenpubliclyannounced.

Shor invented an algorithm to factorize integers in polynomial time using quantumcomputing [S95]. However, for the time being quantum computers able to do suchfactorizationarestilltheoretical.

Other attacks, unrelated to the problemsmentioned above, can target RSA. A chosenplaintext attack [DH76] exploits the fact that RSA is deterministic – given the sameinput,thesameoutputwillbeproduced.Letusassumetheattackerhasthepublickey,knows some of the content of the original message, and has the original messageciphered. He can try to cipher multiple plaintexts of his own with the public key,comparethemwiththeoriginalcipheredmessage,anddiscoverthemessage.

Achosenciphertextattack[RS92]isanotherpossibleattacktoRSA.ItbenefitsfromthemultiplicativepropertyofRSA.Theproductoftwociphertextsisequaltocipheringtheproductofthetwoplaintexts.Intheseattacks,anattackersendsacipheredmessageofhisown,consistingontheoriginalcipheredmessage$M$multipliedbyarandomvalueR, cipheredwith the same key asM. If the attack is successful, the attacker can nowobtainMbydecomposingthemessagesent.Theseattacksassumethatanattackercanobtainplaintextsfromciphertextsfromthesystem.Adaptivechosenciphertextattacksareanadaptiveformofchosenciphertextattacksinthesensethattheyusetheresultsofpreviouslysentciphertextstoselectfutureciphertexts.

2.1.2 Vulnerabilitiesinsymmetricciphermechanisms

Triple DES, or 3DES, is an encryption mechanism based on DES [F99]. As the namesuggests, Triple DES consists on multiple encryption using DES. Triple DES can beimplementedusingoneofthreekeyingoptions:

i Allthreekeysareindependent;ii Key1isequaltoKey3.Key1andKey2areindependent;iii Allthreekeysareequal.

Associatedwitheachkeyingoptionthereisasetofvulnerabilities.Keyingoptioniusesthreedifferent56-bitkeys,i.e.,a168-bitkey,butduetomeet-in-the-middleattacks,therealsecurityis112-bit.LuckspresentedanattacktokeyingoptioniofTripleDES[L98].Theproposedattackconsistsinameet-in-the-middleattackthatreducedthenumberofsteps needed to roughly 2108 steps from 2112 steps. While being an improvementcompared to the brute force attack, this attack still requires a lot of time to beperformed,whichmakesitimpracticable.NISTstatesthatTripleDESwithkeyingoptioniissecureuntiltheendof2030.Fromthereonwards,itsuseisdisallowed[NIST12].

Keyingoptioniiusestwodifferent56-bitkeys,i.e.,a112-bitkey.Keyingoptionii,alsoknownastwo-keytripleencryption,canbeattackedusingchosenplaintextattackswithabout2kstepswithk=56[MH81].Merkleetal.concludeditispreferabletouseasingleencryptionalgorithmwithalongerkeyratherthanamultipleencryptionalgorithmwithasmallerkey.

KeyingoptioniiihasthesamesecurityasDES,whichmakesitaninsecureoption.


2.1.3 Vulnerabilitiesinhashfunctions

Ahashfunctionisafunctionthatoutputsahashgivenabytearrayasinput.Themainapplications of hash functions in modern cryptography regard data integrity andmessageauthentication.Sometimesalsocalledmessagedigestordigitalfingerprint,thehash is a compact representation of the input array and can be used to identify it[MOV96].

According to Menezes et al., a hash function h must have at least two properties[MOV96]:

• Compression–hmapsaninputarraysoffinitelengthtoanoutputh(s)ofafixedlengthx;

• Ease of computation – given h and an input array s, the hash h(s) is easy tocompute.

Menezesetal.alsolistthreepotentialproperties,additionallytothoseabove:

• Preimage resistance – for all pre-specified outputs, it is computationally in-feasibletofindanyinputarraywhichhashestothatoutput,i.e.,findingtheinputarrays,giventheoutputh(s);

• Secondpreimageresistance – it is computationally infeasible to findany secondinputarraywhichhas thesamehashasanyspecified inputarray, i.e.,givens1,findings2<>s1,whereh(s1)=h(s2);

• Collision resistance – it is computationally infeasible to find two input arrayswhosehashisidentical,i.e.,findings1!=s2,whereh(s1)=h(s2).

If a hash function is not preimageresistant or 2nd-preimage resistant, it is thereforevulnerable to preimage attacks. If a hash function is not collision resistant, it isvulnerabletocollisionattacks.Somegenericattackstohashfunctionincludebruteforceattacks,birthdayattacksandside-channelattacks.

MD5isacryptographichashfunctionthat,althoughbeingprovedtobeinsecure,isstillwidelyusednowadays.MD5supersedesMD4,andwascreatedbyRivestin1991[R92].MD5producesa128-bitmessagedigestandiscommonlyusedtoverifydataintegrity.Wangetal.provedthatMD5isnotcollision-resistant[WY05].Theemployedattackwasadifferentialattackthatisaformofattackthatconsistsinstudyinghowdifferencesintheinputaffecttheoutput.

The Secure Hash Algorithm 1 (SHA-1) is another cryptographic hash function. Itproducesa160-bitmessagedigest.Althoughtherehavenotbeenpubliclyfoundactualcollisions for SHA-1, it is considered insecure and the use of SHA-2 or SHA-3 isrecommended [S15]. Other attacks have been successful against SHA-1. Stevens et al.presentedafreestartcollisionattackforSHA-1’sinternalcompressionfunction[SKP15].Taking into consideration theDamgard-Merkle [M79] construction forhash functions,andtheinputofthecompressionfunction,afreestartcollisionattackisacollisionattackwhere the attacker can choose the initial chaining value, also known as InitializationVector(IV).EventhoughtherearesuccessfulfreestartcollisionattacksonSHA1itdoesnotimplythatSHA1itselfisinsecure.

In2005,Wangetal.presentedacollisionattackonSHA-1thatreducedthenumberofcalculationsneededtofindcollisionsfrom280to269[WY05].Theresearchersclaimthat


thiswas the firstcollisionattackonthe full80-stepSHA-1withcomplexity inferior tothe 280 theoretical bound. By the year 2011, Stevens improved the number ofcalculationsneededtoproduceacollisionfrom269toanumberbetween260.3and265.3[St12].

Nowadaysitisstillcomputationallyexpensivetoperformthesenumberofcalculations.Itisexpectedthatbytheyearof2021,acollisionattackwillbeaffordable[Ss12].

2.1.4 SSL/TLSvulnerabilities

ThissectionconcludesbyshowingthattheSSL/TLSprotocolitselfmaybevulnerable.

TLS vulnerabilities can be classified in two types: specification vulnerabilities andimplementationvulnerabilities.Specificationvulnerabilitiesconcerntheprotocol itself.Aspecificationvulnerabilitycanonlybefixedbyanewprotocolversionoranextension.Wemayarguethatthedeprecationofacryptographicmechanismisaprotocol'sdesignflaw as the protocol should not support an insecure mechanism. ImplementationvulnerabilitiesarerelatedtovulnerabilitiesincertainimplementationsofSSL/TLS,suchasOpenSSL,orbrowsers'implementations.TheInternetEngineeringTaskForce(IETF)releasedRFC7457[SHS15]onFebruary2015containingthesummaryofknownattacksto TLS specifications and TLS implementations. In this section we present the mostrecent(known)attackstoTLS.

Startingwithspecificationvulnerabilities,Logjam is themost recentattackand itwaspresented in May 2015 [ABD+15]. The Logjam attack consists in exploiting Diffie-Hellman key exchange weaknesses. Logjam is a man-in-the-middle attack thatdowngrades the connection to a weakened Diffie-Hellman mode. This Diffie-Hellmanwithweakparameters isoneattackmadepossibleby the restrictions imposedby theU.S.A. export of cryptography. In the 1990's, the United States of America legislatedsome restrictions over exporting cryptography. In order to support SSL/TLS in somecountriesnotallowedtoimportU.S.A.cryptography,SSL/TLSsupportsweakenedDiffie-HellmanmodesthatarecalledtheEXPORTmodes[V15].

Previous attacks, such as the one made possible due to the FREAK vulnerability[BBD+15]havealreadymadeuseofthisweakness.Adrianetal.considerLogjamaresultof aprotocol specificationvulnerabilitydue to the factofTLS still allowing theuseofDiffie-Hellmanwithweakparameters[ABD+15].

Inordertounderstandtheattackitself,weintroducetheconceptofnumberfieldsievealgorithm. A number field sieve algorithm is an efficient algorithm used to factorintegers bigger than one hundred digits. The authors used a number field sievealgorithm to precompute twoweak512-bitDiffie-Hellman groups used bymore than92%of thevulnerableserversparameters [ABD+15].Thisapproachwas takendue tothe fact that it is computationally heavy to generate prime numberswith the desiredcharacteristics.

TheLogjamman-in-the-middleattackchangesthecurrentciphersuitestoDHE_EXPORT(which provides EXPORT modes), forcing the use of weakened Diffie-Hellman keyexchange parameters. As the server supportsDHE_EXPORT, a completely validDiffie-Hellman mode, the handshake proceeds without the server noticing the attack. Theserver proceeds to compute its premaster secret using weakened Diffie-Hellmanparameters. From the client's point-of-view, the server chose a seemingly normal


ephemeral Diffie-Hellman (DHE) option and proceeds to compute its secret alsowithweak Diffie-Hellman parameters. By this point, the man-in-the-middle can use theprecomputationresultstobreakoneofthesecretsandestablishtheconnectiontotheclientpretendingtobetheserver.OneaspectworthnoticingisthatthisattackwillonlysucceediftheserverdoesnotrefusetoacceptDHE_EXPORTmode.

The solution for this vulnerability is simple and has already been implemented.BrowsersandotherclientssimplydenytheaccesstoserversusingweakDiffie-Hellmanciphersuites,suchasDHE_EXPORT,althoughTLSstillallowsit.

Another attack concerning the protocol specification is a padding attack namedPOODLE. POODLE stands for Padding Oracle On Downgraded Legacy Encryption andwas presented by Google engineers in 2014 [MDK14]. The origin of this attack is thebackwardcompatibilitywithSSL3.0ofmanyTLSimplementations.Tobesuccessful,theattackershould induceadowngradeattackfirst, inordertotransitionfromTLS1.xtoSSL3.0.

POODLE targets theCBCmodeof operationused in SSL3.0.Although, an assumptionthattheattackercanmodifycommunicationsbetweentheclientandtheservermustbemade. POODLE is a padding attack which exploits the given assumption. As the CBCpaddingisnotdeterministicandnotcoveredbythemessageauthenticationcode(MAC),theintegrityoftheCBCpaddingisnotfullyverifiedwhendecrypting.

ThePOODLEattackcanbeusedtodecryptHTTPcookiesinwebsites.Theauthorsstatethat for every byte revealed, 256 SSL 3.0 requests are needed. The attack has beenprovedtobepossibleinTLS[L14].Theimplementationsaffectedarethosethatdonotproperlycheckthepaddingused.

The most obvious solution is to avoid SSL 3.0 by disallowing the backwardscompatibilityanddeprecatingSSL3.0.AnothersolutionistouseTLSFallbackSCSV,asdescribed in [ML14]. This signaling cipher suite value (SCSV) intends to preventunnecessary downgrade of the connection when both client and server actually dosupportthemostrecentversionofTLS.

RegardingTLSimplementationvulnerabilities,Heartbleed,discoveredin2014,isoneofthemostrecentones(CVE-2014-0160).Itsnamecomesfromthemechanismwherethevulnerability lies, the heartbeat extension. Heartbleed was a security vulnerability inOpenSSL1.0.1, through1.0.1f,when theheartbeat extension [STW12]was introducedandenabledbydefault.TheHeartbleedvulnerabilityallowedanattackertoperformabuffer over-read [CDF+14]. A buffer over-read happenswhenmore data is read thanallowed. This can be used to access the contents of other, possibly sensible, programvariables.

2.2 Serviceidentification

Almostallofthecyberattacksareperformedafteridentifyingthevulnerabilitiesofthetargeted system. These are found out by acquiring knowledge about the type ofoperatingsystemthesystemisrunning,andthetypeofservicesrunningonit.Often,thevulnerabilitiesarearesultofaprogrammingerrorinservices,whichresultinabuffer-overfloworasimilarexploit,orasaresultofmisconfigurationofservices.Eitherway,knowledgeabouttherunningserviceshelpsanattackertodeterminetheattackvector


tobeused.Ifthisinformationishiddentotheattacker,itsattackvectorisreducedandthustheattackshindered.

Acommonandeasywayofhidinginformationabouttheservicesrunningontheserveris to run them on non-standard port numbers. This helps to evade port scans by anattacker over commonly used port numbers. However, should the attacker conduct ascanoverallportsorbysheerlucklearnanon-standardportbeingopen,hewouldbeabletodeterminethetypeandinsomecasestheversionofservicebyconnectingtotheserviceandobservinghowtheserviceresponds.Thisprocessiscalledbannergrabbingorservicefingerprinting.

Adefense against service fingerprinting is touse a Firewall or an IntrusionDetectionSystem (IDS) to observe and block port scans. However, this could be defeated if theattackerhasenoughpatiencetotemporallyspreadoutthescansovera longperiodoftimeorhasenoughIPaddressestoconductthescans(asinthecasewithabotnet).

2.3 Man-in-the-middleattacks

Intheseattacksanattackerplaceshimself inbetweenthecommunicatingentitiesandtriestoimpersonatethemforeachother.Ifsuccessful,theattackerisabletolearntheircommunications and alter them. These attacks are prominent in the caseswhere thecommunication entities, for example a server and a client, have to agree on anencryptionkey for the first timewithout theknowledgeof eitherof theirpublickeys.Thisisbecausetheclientpresentsitspublickeytotheserverwhichmaylikelybenewtoitandhencecouldbeeasilyreplacedbyanattacker.Theclientwhenpresentedwiththeserver’skeymaynotknowifitisindeedtheserver’skeyandisnotreplacedbytheattacker.

Modern secureweb communicationprotocols such asTransport Layer Security (TLS)used in the HTTPS protocol depend upon Public-Key Infrastructure (PKI) to defendagainst these attacks.PKI enables communicationentities toobtaindigital certificatesfrom trusted third parties, referred to as Certification Authorities (CA) as anendorsement of their identity. Through a digital certificate, the CA cryptographicallyconveys that the certifiedpartyhas aparticularname,public keyand communicationaddress. Since a digital certificate could be obtained from anyone, the CA should betrustedbyboththecommunicationentitiesfortheircertificatestobevalid.Withdigitalcertificates in place, the attacker in the middle has to impersonate either the CA orimpersonate the public key and the communication address, either of which aretheoreticallyhard.

Inpractice,however,acommunicationentity trustsmanyCAs.Forexampleamodernweb browser such as Firefox or Internet Explorer trusts up to 100 of CAs. This isbecause of political and commercial reasons behind the PKI: each country or a bigorganization wants to have its own CA. Since the PKI does not limit the validity ofcertificatesissuedbyaCAlocallytosomeregionordomain,aCAwhichistrustedbyacommunication entity can issue valid certificates to anyone. Thismeans that 1) if anattacker succeeds in placing himself as a trusted CA list or 2) if he attacks andcompromises a certification authority, he can again perform the man-in-the-middleattacks.SuchattacksonPKIarenotrare[HRE+14].


2.4 Routehijacking

Information travels on the Internet as packets that follow routes from machine tomachine.TheInternetitselfisanetworkcomposedbymanyinterconnectednetworks.Administrativenetworkdomains are calledAutonomousSystems (AS), and the routingbetweentheseautonomoussystemsishandledbytheBorderGatewayProtocol(BGPv4)[RLH06].

TheBorderGatewayProtocoldoesnotensurethatBGProutersusetheASnumberthathas been allocated, or that the AS holds the prefixes it originates. So a router can beconfigured to advertise a prefix froman address spacebelonging to anotherAS in anactionknownasIPprefixhijacking[BFM+10].Thisactioncanhappenintheforms:

• Hijack the entire prefix –where the hijacker announces the exact prefix of thevictim,meaningthatthesameprefixhastwodifferentorigins.

• Hijackonlyasub-prefix–theoffenderannouncesamorespecificprefixfromanalready announced prefix. For example if the victim is announcing200.200.0.0/16 the attacker announces 200.200.200.0/24. Due to the longestprefixmatchingrule,anASthatreceivestheseannouncementsmaydirecttraffictoward thewrongAS. This type of hijacking is associated to blackhole attacks,wherethemaliciousASdropsallthepacketsreceived.

• Interceptionhijack–theattackerannouncesa fakeroutetoanAS.TheASnowforwards traffic from a victim intended to a legitimate destination to themalicious interceptor. The contents of the intercepted traffic can beanalyzed/changed, before being sent to the legitimate destination. Figure 1illustratesthistypeofattack.

Figure1.ASroute-interceptionattack.

Schlampetal.describedanattackwhereanoffenderclaimsownershipofanentireAS[SCB13].ToperformanAShijackingattack,theattackerpretendsthatheownstheASofthe victim. These types of attacks are harder to detect because unlike the prefixhijackingattack,therearenosignsofduplicateoriginannouncements,theonlychange


thatdoesoccuristheformationofanewlinktotheupstreamproviderfromthevictimAS.Accordingtotheauthors,toperformthisattack,theoffenderneedstohavearouterconfiguredwithBGPandprovetheownershipofthevictimAS,toanupstreamprovider,by controlling Regional Internet Registrars (RIR) databases where the informationabout ownerships is stored. The authors conclude by suggesting an early detectionsystem that combines multiple data sources and verifies the expiration date of thedomainoftheautonomoussystems,sendingawarningtoASesinwhichanexpirydateisclose.Thisisimportantbecause,ifadomainexpires,anattackercanre-registerthatdomainclaimingtheownership.

Autonomoussystemsareboundbybusinessrelationships,thereforenetworkoperatorsspecifyroutingpoliciesthataffectwhichBGProutesarechosen.BGPUPDATEmessagescontain routeattributes that areusedbyBGP routers to compare theannouncementsreceived.Someof themost importantrouteattributesare the localpreference, theASpathlengthandtheorigintype.ABGProuterselectsaroutewithamaximumvalueoflocalpreferenceandaminimumvaluefortheASpathlength.

Asurvey[GSG13]wasconductedinordertoobtainsomeinformationabouttheroutingpoliciesinplace,inwhichalmost100responsesfromnetworkoperatorswereobtained.Thequestionsaskedinvolvedmainlytheusabilityofmodelsofroutingpolicies,liketheGao and Rexford model, and the criteria of BGP decision process (steps which helpdecide the route to choose). In the Gao and Rexford model, ASes that buy transitservices,toobtainaccesstootherpartsoftheInternet,arecalledcustomers,ASesthatprovide these services arenamedasproviders, and finallyASes at the same level areknownaspeers.Themodelassumesthefollowingconditions:

• By having a choice, the ASes always choose to route traffic to neighboringcustomers insteadofaneighboringpeer,orprovider.Thispreference isdue tothe monetary gain obtained by choosing customer routes and the way toexplicitlydefineitisbyusingacriteriaknownaslocalpreference.

• ASes only export providers or peers routes to neighboring customers. ThisimpliesthatanASonlyexportstrafficifitwaspaidtodoso.

Accordingtotheresponses,68%appliedbothconditionsand19%onlyappliedthefirstcondition.Reasonsregisteredforthenon-usabilityoftheexportconditionincludesecretagreementsandthatexportrestrainingtechniquesmayendupbreakingrouting.Theseevidences show that it is difficult to predict the paths that packets take due to theheterogeneityofroutingpoliciesindifferentASes.

Autonomoussystemscanmodifyforwardingattributesfortheirownconvenience.Forexample,theycan:

• ReduceanASpath inorder to lookmoreattractiveaccording to some routingmetric;

• Put additional AS hops at the end to make a hijacked route look like it wasoriginatedbytheproperAS;

• AddthevictimAStotheASpath,andoncetheadvertisementreachesthevictimAStheBGPloopingsystemwilldropthemisleadingannouncement[BFM+10].


BGP security today mainly consists of filtering suspicious BGP announcements, likeannouncements that contain loopback addresses, or addresses that are not owned bytheAS thatannounced it.Theproblemof thisapproach is thatdetecting invalidrouteannouncements is more challenging when the offending AS is several hops away.Therefore, having a global view of correct routing information would make it mucheasiertodetectinvalidroutes.

An accurate routing registry would have prefix ownership, AS-level connectivity androuting policies enabled in each AS, helping ASes in verifying the legitimacy of theadvertisementsthattheyreceive.ThedrawbacksofthismodelmainlyincludethelackofdesireofISPstosharetheirproprietaryroutingpolicies.Moreovertheregistryitselfisoftenuntrustedduetoitspowertomanipulatetherouteinformationatwill.

Ultimately,theadoptionofsecuritysolutionsislimitedbythelackofsharingofreliableinformationinpublicInternetregistriesofaboutthecorrectmappingofIPaddressestoASes.


3 Services

TheSafeCloudmiddlewarewillprovideasetof fourservicesthatsolveormitigatethethreatspresentedintheprevioussection.TheservicescorrespondtoTasksT1.2toT1.5ofWP1,asshowninTable1.Task1.1definesthemiddlewarearchitectureanditsfirstoutcomeisthepresentdeliverable,D1.1.Thetablealsosummarizesthethreatshandledbyeachservice.

Service Task Section Threathandled

Vulnerability-tolerantchannels T1.2 3.1 Securechannelcomponentvulnerabilities

Protectedserviceprovisioning T1.3 3.2 Serviceidentification

Routemonitoring T1.4 3.3 Man-in-the-middleattacks,routehijacking

Multi-pathcommunication T1.5 3.4 Man-in-the-middleattacks,routehijacking

Table1:Correspondencebetweenthemiddlewareservices,WP1’stasks,andthethreatsinSection2.

Figure 2 presents these services in the context of the SafeCloud framework. Inparticular,thesecurecommunication(WP1)isdescribedinthesecondrowandcontainsthreesolutions:

(1) Vulnerability-tolerant channels – this solution corresponds to the first service,whichhasthesamename(T1.2).

(2) Protectedservices– thissolution includessolution1,and itextends itwiththesecondservice,protectedserviceprovisioning(T1.3).

(3) Route-awarechannels–includessolution2,andextendsitwithroutemonitoring(T1.4)andmulti-pathcommunication(T1.5).


Figure2.TheSafeCloudframework.

Thefollowingsectionspresentthefourservices.Eachsectionstartswithadescriptionof the mechanism, then presents the main components that implement the service,finallypresentstheserviceAPI.

3.1 Vulnerability-tolerantchannels

3.1.1 Description

Secure communication channels are mechanisms that allow two entities to exchangemessages or information in some sense securely in the Internet. A securecommunication channelusuallyprovides threeproperties:authenticity,confidentiality,and integrity.Regardingauthenticity, inanauthenticchannel,noonecan impersonateanother.Theinformationregardingtheoriginalsenderofamessagecannotbechanged.Regarding confidentiality, in a confidential channel, only the original receiver of amessage is able to read that message. Regarding integrity, the messages cannot betamperedwith.

Severalprotocolstoimplementsecurecommunicationchannelsexistnowadays,suchasTLS, IPsecorSSH.Eachof thesechannels isused foradifferentpurpose,butwith thesamegoalofsecuringthecommunication.WeintroducedTLSinSection2.TheInternetProtocolSecurity(IPsec)isanetworklayerprotocolthatprotectsthecommunicationata lower level than SSL/TLS,whichoperates at the transport layer [KS05]. The SecureShell(SSH)isanapplicationlayerprotocol,similarlytoSSL/TLS,thatisusedforsecureremote login, secure file copy, and other secure network operations over an insecurenetwork[YL06].

Asecurecommunicationchannelbecomesinsecureifavulnerabilityisdiscoveredinitsspecification or implementation. Vulnerabilities may concern the protocol'sspecification, cryptographic mechanisms used by the protocol or specific

SafeCloud framework draft

State of

the Art

SafeCloud framework

Secure

commu

nication

TLS secure

channels

Solution 1: Vulnerability-tolerant

channels

Solution 2: Protected channels Solution 3: Route-aware channels

Gives: tolerance to vulnerabilities

in components (e.g., in hash

function)

Gives: improved confidentiality

thanks to a lesser chance of fake

certificates; resistance to port

scans and enumeration of network

infrastructure

(notary and portknocking)

Gives: improved confidentiality

with warnings about route

hijacking and making harder

access to communication

API: extended secure socket API API: extended secure socket API API: extended socket API

Technology provided by: INESC-

ID/TUM


ID/TUM


ID/TUM

Secure

storage

Encrypted

database

Solution 1: Distributed encrypted

filesystem

Solution 2: Long-term distributed

encrypted document storage

Solution 3: Secure block storage

Gives: file storage Gives: long-term (entangled)

document storage (immutable)

Gives: block storage on individual

data centers

API: POSIX API: REST (S3 or similar) API: Key/value

Technology provided by: UniNE /

INESC-ID


INESC TEC


INESC TEC

Secure

queriesNone

Solution 1: SQL on encrypted

values

Solution 2: SQL on encrypted keys

and values

Solution 3: SQL on encrypted keys

and values with untrusted clients

Gives: privacy of data values

against server

Gives: privacy of data and keys

against server

Gives: privacy of data and keys

against client and server

API: SQL API: SQL API: SQL


TEC


TEC and CYBER

Technology provided by: CYBER


implementationsoftheprotocol.ManyvulnerabilitieshavebeendiscoveredinSSL/TLSoriginating new versions of the protocol with renewed security aspects such asdeprecating cryptographic mechanisms or enforcing security measures. Certainimplementations of SSL/TLS have also been considered vulnerable by havingimplementationdetailscausingabreachinsecurityandaffectingdevicesworldwide.

Oursolution isasecurecommunicationchannel tolerant tovulnerabilitieswhichdoesnot rely on only one cipher suite. It is our belief that, in order to solve the problem,diversity and redundancy are helpful to mitigate vulnerabilities. Diversity andredundancyconsistinusingtwoormoredifferentmechanismswiththesameobjective.Forexample,MD5andSHA-3arebothhashfunctionsusedtogeneratedigests.Inarealcase,whereMD5 has become insecure, our secure communication channel resorts toothermechanisms, such as SHA-3, in order to keep the communication secure. Usingdiversity and redundancy, when a mechanism is targeted by an attack, anothermechanismisabletomaintainthesecurityandavailabilityofthecommunication.

The objective of this solution is to mitigate the problem of secure communicationchannelsbeingvulnerabletoattacks.Thetaskinvolvesstudyingtheuseofdiversityandredundancy to improve security, in general, and to improve secure communicationchannels'security,inparticular.Morespecifically,ourproposaltoachievethisobjectiveis to develop a new secure communication channel tolerant to vulnerabilities thatprovides authenticity, confidentiality and integrity, and uses diverse and redundantmechanisms aimed at making the communication more secure. Our approach willintroduce redundancy and diversity through specific entry points of our securecommunicationchannel.

Oneofthechallengesofthisworkistoevaluateifdiversityandredundancyhavearealimpact on increasing the security of a communication channel while still havingreasonableperformance.

Our proposal is a diverse secure communication channel. It aims to increase securityusingdiverseandredundantmechanismsanditisbasedontheTLS1.2standard.

Our proposal solves the problems originated from having only one cipher suitenegotiated between client and server. In the case when one of the cipher suitesmechanismsisinsecure,thesecurecommunicationchannelsusingthatciphersuitemaybe vulnerable. Our diverse secure communication channel negotiates more than onecipher suite between client and server and, consequently, more than one encryptionmechanismwillbeusedforeachpurpose.Hence,thechanneldoesnotrelyinonlyoneciphersuite.AlthoughmostciphersuitesusedbyTLS1.2areregardedassecure,thereisnoassurancethatanagencyorcompanywithhighcomputationalpowerisnotabletobreakthatencryptionmechanismtodayorinthenearfuture.

Diversity and redundancy’s primary entry point in our proposal is in the Handshakewhere client and server negotiate the k cipher suites to be used, where k > 1 is thediversityfactor,representingthenumberofdifferentciphersuites. Inacasewhenthediversityfactoris1, it isconsideredthatthechannelhasnodiversity,andthechannelbecomesregularTLS1.2.


Evenwhenk−1ciphersuitesbecomevulnerable,ourproposalremainssecureduetotheexisting diversity. The remaining redundant cipher suite ensures that thecommunicationissecurebyremaininginvulnerable.

Nevertheless,notallcipherssuitesarecompatiblewitheachother.Ciphersuitesmustbecombinedinawaythatsecurityincreases,nottheopposite.Theserverchoosesthebest combination of k cipher suites according to the cipher suites the client hasavailable.

Diversityandredundancywillalsobeintroducedinthecommunicationbetweenclientandserver.ItisourintenttouseasubsetofthekciphersuitesdefinedintheHandshakeProtocoltocipherthemessages.Whileperformancemustbetakenintoaccount,wewillproceedtoestimatethereasonablekciphersuites,andalsothereasonablesubsetofktobeusedtocipherthemessages.

3.1.2 Components

Thechannel is implementedbytwocomponents: theserverandtheclient. Just like inTCP, the server awaits connection requests, and the client takes the initiative ofcontacting the server for establishing a connection. Just like inTLS, there is an initialhandshakeprotocolbetweenclientandserverthatisintendedtoexchangeinformationabout the identities and supported cryptographic protocols, to authenticate thecommunicatingpartiesandtoperformthedistributionofsessionkeys.

3.1.3 API

TheclassicalprogramminginterfaceforTCPandUDPistheBerkeleyUNIXSocketAPI[S90].Itprovidesprimitiveslikesocket(tocreateacommunicationendpoint),bind(toassociateanIPaddressandaport toasocket),sendandsendto(tosenddata),receiveandreceivefrom(toreceivedata)andselect(toblockwaitingforreceivingfromseveralendpoints).

TheAPI forSecureSockets(asocketthatusesSSL/TLSwithprotectionguarantees) isprovided in the Java programming language in the javax.net.ssl package. The classesextend regular sockets and add a layer of security over the underlying networktransportprotocol.

Thetypicalservercodeconsistsin:

• SSLServerSocketFactory.getDefault()• sslServerSocketFactory.createServerSocket(portNumber)• sslServerSocket.accept()• sslSocket.getInputStream()

Thetypicalclientcodeconsistsin:

• SSLSocketFactory.getDefault()• sslSocketFactory.createSocket(hostName,portNumber)• sslSocket.getOutputStream()

The creation of a secure socket is done through a factory object that abstracts theconcrete class that is instantiated. This indirection level can be leveraged to return


modifiedsecuresockets, likeourproposedvulnerability-tolerantsecuresockets,whilemaintainingoverallAPIcompatibility.

Asecureserversocketiscreatedbyprovidingthedesiredbindingwithusuallytheportnumber.Theacceptmethodleavestheserverawaitingconnectionrequests.

ReadingfromandwritingtothesocketisperformedusingtheInputandOutputstreamobjectsthatarefoundinthejava.iopackage.

When secure sockets objects are first created, no handshaking is done so thatapplicationsmay first set their communication preferences e.g. what cipher suites touse.However,securityisalwaysprovidedbythetimethatapplicationdataissentovertheconnectionbecausethesecurityhandshakeisdoneimplicitlyoncetheclienttriestoreadfromorwritetothesocket.

ThehandshakecanbealsobeexplicitlystartedbycallingthestartHandshake()method.Thismethodcanbeextendedtoaddoptionsrelatedwithvulnerability-tolerance,ifthedefaultvaluesneedtobemodified.Themanagingoftheciphersuiteswillalsoneedtobemodified,asthesupportedandenabledciphersuiteswillhavetodealwithmultiplesimultaneouschoices.

3.2 Protectedserviceprovisioning

3.2.1 Description

Protected service provisioning addresses the threat that attackers can identify theservicesrunningonahosttodeterminetheirattackvector.Thisisdonebyemployingport-knockingtactics.

Port-knockinglimitstheavailabilityandvisibilityofaserviceonlytoauthorizedclients.An advantagewhen compared to other authenticationmechanisms is that with port-knockingunauthorizedclientswillneitherbeable toaccess theservicenorbeable todetermineiftheserviceisevenavailableandrunningonthehost.Thisisbecauseportknocking works at the transport layer in OSI networking stack. In the case of a TCPconnection attempt to the protected service, the first TCP SYN packet the TCPhandshakecontainsauniqueauthentifierauthenticating theTCPconnection.WhereasincaseofaUDP-basedconnection,theUDPheadercouldcontaintheauthentifier.

Since neither TCP nor UDP protocols incorporate fields for authentifier data, it isaccommodatedinfieldswhichallowarbitraryvalues, forexample,theinitialsequencenumber field inTCP. In the caseofUDPonly the sourceanddestinationportnumberfields can have arbitrary numbers,which restricts the number of bits for authentifierdata.

Thefollowingfactorsareconsideredwhiledevisingourport-knockingmechanism:

• Protectioncoverage: shouldonlysomesubsetof services runningon thehostbe protected or all of them? This question impacts the design decisions toprovideport-knockingauthenticationofeachserviceortojustoneproxyservicerunningonthehost.

• Authentication mechanisms: How is the authentication between hostsachieved? Is this done through a PKI based on certificates where the cloud


serviceproviderdeploysaCAandcertifiesallofthehostsandtheserviceusers?Or is it done through sharing passphrases to individual service users and alsoamonghosts?This impactswhetherwecould reuseoff-the-shelfport-knockingsolutionssuchasknockknockd,whichcurrentlyonlysupportspassphrasebasedauthentication.

• Deployability:howfarareserviceprovidersanduserswillingtogotoconfiguretheoperationsystemson theirhosts?Theanswers to thisquestion letsusruleout solutions involving complex configurations which involve patching theoperationsystem'skernel.

• Scalability: there are off-the-shelf software solutions providing port-knocking,knockknockd is an example of this. However, it requires each client to beauthorizedby a passphrase stored in a file.While this approach is simple, thislimits its scalability as the knockknockd service has to scan through thepassphraseseach timeaport isknocked.Also, ithindersdeploymentscenarioswhere a service provider has multiple servers, for either load balancing orredundancy,andaclientshouldbeable toaccessanyof thoseserviceswith itsport-knockingpassphrase.Inthiscase,thepassphraseprofilesofclientshavetobesynchronizedonallserversprovidingaccesstotheclients.Also,whenaclienthastobepermittedorrestricted,itscorrespondingpassphraseprofilehastobeaddedorremovedrespectively.

Considering these factors, our solution is to provide a complete protection coverageextending to all system services, if need be. To address the scalability concerns, weproposetousePKIbasedauthenticationapproachasthisremovestherequirementtosynchronized passphrase profiles and only requires CA certificate to authenticate anyclient.Therequirementofsynchronizingpassphraseprofilesisinthiscasereplacedbyhaving a requirement of implementing revocation lists. However, there existframeworksfordealingwithrevocationlistsandprovidedthatwechooseareasonablecertificateexpirydates,wecanboundthesizeoftherevocationlists.

3.2.2 Components3.2.2.1 Protocol

The protocol for port-knocking involves a one-way handshake between client andserver. The handshake is always initiated by the client. As part of the handshake theclienttransfersitscertificateinthepayloadofanUDPpackettoapre-determinedportontheserver.Thispayloadwillalsocontaintheportnumbertheclientwantstoopenonthe server, current timestamp, IP address and port number of the client's transportendpoint, and a HMAC over these fields. The payload is encrypted with the server’spublic key. If theport knocking service on the server determines the certificate to bevalid,theclientissaidtohavesuccessfullyport-knocked.

If the UDP packet is malformed or the client’s certificate is invalid, the serverimmediatelyrespondswithanICMPportunreachablemessagetotheclient,givingtheimpression that theUDPport isclosed.Foranattackeroranunauthorizedclient, thismessageconveysthatnoserviceisusingthegivenport.

Inthecaseofasuccessfulport-knockbyaclient,theserverdoesnotrespondbacktotheclient’sfirstUDPpacket.It insteadwaitsfortheclienttosenditsconnectionpackettothe intendedport.Anypackets to thisportreceived fromtheclientwithinaperiodoftimewillthenbeallowedbythefirewall.Theportisclosedfortheclientafteratimeout


for TCP and UDP connections or by explicit connection teardown in the case of TCPconnections.

Figure3:FormatoftheUDPknockpacket

TheformatoftheUDPknockpacketisshowninFigure3.Theformatisnotfinalizedatthetimeofwritingthisdeliverable.Sincetheformatimpactstheimplementationwhichishoweverabstractedbytheclient libraryAPI,anychanges inthepayloadformatareless likelyto impacthigher layerswhichusetheprovidedAPI.Versionincompatibilityforthepayloadformatisaddressedbybeingasbackwardscompatibleaspossible.

Ahandshakepacketfromaclientisconsideredmalformedif:

• ItisnotaUDPpacket;• Itissmallerthanaminimumlengthrequiredbytheprotocol;• The destination port is not the pre-defined port on which the port-knocking

servicewillbeexpectingtoreceiveit;• Thepayloadfailstodecryptwiththeserver’sprivatekey;• Thedecryptedpayloaddoesnotmatchthepayloadformat;• The decrypted payload has a different version than those supported by the

server;• Theclientcertificateisinunknownformat.

Additionally,thecertificateinthedecryptedpayloadistreatedasinvalidif:

• Theclientcertificatehasexpiredorthevaliditystartsinfuture;• TheclientcertificateisnotsignedbyaCAtrustedbytheserver;• TheclientcertificateisinalatestCRLissuedbytheserver.

3.2.2.2 Server component

Thisisaservicerunningontheserverprovidingportknockingfortheservicesrunningon the same server. It interacts with the firewall of the system to determine whichclientsaretobeauthorized.Toparticipateintheportknockinghandshake,thefirewallismadetologallincomingUDPpacketstoapre-determinedport.TheservicewillreadthesepacketsanddiscardmalformedonesbyrespondingwithICMPportunreachablemessagestotheirrespectivesenders.Thesemessagesarealsosentifthepacketiswell-formedbuttheclientcertificateisinvalid.

For well-formed packets containing valid client certificates, the service opens up theintendedportonthefirewallfortherespectiveclient.

Theservercomponentisconfigurableviaaconfigurationfile.TheconfigurationincludestheportnumberoftheUDPhandshakepackets,a listofCAswhosecertificatesshould


be a treated as valid, and a certificate revocation server address for periodicallydownloadingthecertificaterevocationlists.

3.2.2.3 Client library

Clientapplicationshavetoimplementtheport-knockingprotocolbeforetheycanaccessthe services on a server implementing our port-knocking solution. The client libraryimplements this client-side protocol of the port-knocking protocol. This helps in codereuseandmaintenanceasanyminorchangesintheprotocolonlyconcernwithchangestothelibraryinsteadoftheclientapplications.

TheprogramminginterfaceofthislibraryisdescribedintheAPIsectionbelow.

3.2.2.4 Proxy

Theproxyisaservicerunningontheclientside.Itisusedsolelyforconvenienceandisimplemented to improvedeployability. Itprovides transparentaccess to servicesonaport-knockedserverwithoutrequiringtheclientapplicationtousetheclientlibrary.

Thisworksbyhavingtheclientapplicationconnecttotheproxy'slocalSOCKSportandaskingtheproxytoopenconnectionstoaport-knockedservice.Theproxythendoestheportknockinghandshakebyusingtheclientlibraryandforwardstheapplicationtrafficthebetweentheclientapplicationandtheport-knockedservice.Byusingtheproxy,theclient application need not require to interfacewith the client library to access port-knockedservices.

3.2.3 API

TheAPIfortheclientlibrarywillprovideasinglefunctioncall,whichinheritsfromtheBSDsocketAPI’sopenfunctioncall.

int knock_open(AF, TYPE, client_cert, server_cert, server_addr, knock_port, service_port)

1. AF: Communication address family. Used to select either IPv4 or IPv6 sockets.OnlyAF_INETandAF_INET6aresupported

2. TYPE:STREAMorDGRAMforTCPorUDPrespectively

3. client_cert:client'scertificatetouseintheport-knockinghandshake

4. server_cert:server'scertificate

5. server_addr: socket address for server. This should correspond to the AFparameter.

6. knock_port:theporttowhichtheinitialUDPpackethastobesentto

7. service_port: theport of the service towhich the connectionhas tobe grantedaftersuccessfulport-knockingattheserver

8. Return:-1uponerror;fd>0forafiledescriptorcorrespondingtothesocket


Thisfunctiontriestoportknocktheserveridentifiedbyserver_certandisreachableonserver_addr. It does so by first sending the first UDP packet of the handshake toknock_port. If the requested TYPE is STREAM, then it also connects the socket to theservice_portontheserver.

The return value of the function is a file descriptor corresponding to the underlyingsocket.InthecaseofTCP,i.e.,whenTYPEisSTREAM,thesocketwillbeinaconnectedstate.

Caveats: the connection to the port-knocked service may expire after a period ofinactivity. This will be more relevant if UDP (TYPE set to DGRAM) is used, for TCPimplementsTCPkeep-alivesaspartofitsstack.

3.3 Routemonitoring

Our approach to routemonitoring involves various techniques to collectively deduceany anomalies in the routes used by SafeCloud endpoints. For this we use networkmeasurements deriving from actively probing the characteristics of the routes and,optionally, passively inferring routing changes from BGP route advertisements asdescribed by Feamster et al. [FAB+03]. The collected data is then analyzed on theendpoints,andaresponseistriggeredbyroutinganomalies.

Throughactiveprobingwedeterminethenumberofinvolvedhops,latencyandpacketlossintheroute.Thisrequirestraffictobeexchangedontherouteperiodically.Usually,thistrafficisgeneratedbytheapplicationlayers,however,inthecasetheupperlayersdonotsupplyenoughtraffic,activeprobingrequiresdummytraffic tobesenttokeepthe route characteristics updated. The measurements determined in this waycorrespond to the amount of traffic in the route. With a varying traffic rate, themeasured route characteristics vary due to queuing and scheduling involved at theroute’shops.

Thisworkdoesnot intend to substitute theuseofbestpractices to configureBGP,orseveral preventionmechanisms that have already been proposed [BFM+10] [KFR06],buttopresentaroutehijackingdetectionsystemusingasetofmonitoringtechniqueslike, traceroute,measuring latenciesand IP tracebackmechanisms that caneffectivelyandreliablymonitortheroutesthepacketsaretaking,ultimatelyleadingtoaconclusionabouttheexistenceofaroutehijack.

Moreover,sinceroutingintheInternetissusceptibletochangesduetovaryingnetworkloadandconnectivityconditions,notallroutinganomaliesaretobetreatedasattacksontheroutingprotocol.Thiscausesdifficultyfordetectingattacksautomatically,whilekeepingthefalsepositiveratelowisaggravatedbythefactthatwemeasuretheroutecharacteristics from the endpoints. Hence, our route monitoring approach does notattempt to identify such attacks, however it will provide mechanisms to statisticallyevaluatetheroutemeasurementsandtriggerresponsecallbacksfromapplicationsuponfindingananomaly.Itisleftuptotheapplicationstoeitherlogtheanomalyforfutureinvestigationsortakepreventiveactionsanticipatingapossibleroutingattack.


3.3.1 Description

The objective of this service is to provide a route monitoring system. The systememploys various techniques tomeasure route characteristics in a comprehensivewaysuch that they are harder to be manipulated by an active attacker in the route.Additionally,weconsiderthefollowingrequirements:

• Efficient–Theoverheadassociatedtothemeasurementshastobekeptaslowaspossible;

• Scalable – The monitoring system has to scale well i.e., the number of routesbeingmonitoredshallnotbecomeabottleneckfortheperformanceofthesystem

• Easytodeploy –The systemshall notdependonvantagepoints andprivilegedinformationlikeBGPmessagesthatlimititsabilitytobeusedinpractice;

• Resilient – The techniques that constitute the system have to be redundantenoughtopreventattackersfrommanipulatingtheroutecharacteristics;

Ourmonitoring system takes into considering three important routemetrics: latency,hopcount,andthepathbetweenthesourceanddestination.

Sincepacketsinaroutetakenon-negligibleamountoftimetotraversearoute,anattackcausingthepacketstotraversealongerroutewouldincreasethedelay.Howeverduetothe congestion in thenetwork, causedby legitimate reasons, thismethodofdetectingroutehijackingisnotreliable.Forthisreason,weproposetoalsoconsiderthenumberof hops in the route alongwith the delay. The number of hops in the route could bemeasuredreliablybyobservingtheTime-to-Live(TTL)fieldoftheInternetProtocol(IP)packetsatthesourceanddestination.Anattackerthathashijackedtheroutecanbypassthis monitoring technique by adjusting the TTL field of the IP packets in order toreproducethenumberofhopsofanormalpathbetweenthesourceandthedestination.Therefore, ourproposalwill keep statebothof thenumberofhops and the time thatpacketstakefromend-to-end.

Ananomalycausedbythetwostates,latencyandhopcount,givesusenoughreasontostart investigating the path the packets are taking. Furthermore, less extreme changecases, like 20-30% changes in the metrics, may also require investigation. For this,tracerouteisusedbutroutersmaybeconfiguredtoblocktracerouterequestsorcertainprotocolslikeICMPorUDP.Thustracerouteswithdifferentprotocolsareexecutedandtheresultsaremergedgeneratingthemostcompletepathpossible.Anydifferenceintheobservedpathfurtherconfirmstheanomaly.

3.3.2 Components

TheroutemonitoringsystemcomprisesofamonitoringservicerunontopofSafeCloudcommunicationendpoints.Theservicecomprisesofthefollowingcomponents:

• TTLmonitor• Routemetricsmonitor• BGPmonitor(optional)• Anomalydetector

TheTTLmonitorestimates thenumberofhops involved in the route.For this task, ituses a multitude of approaches based on Traceroute (ICMP, TCP, UDP), SecureTraceroute[PS03],IPoptions(RecordRoute,StrictSourceRecordRoute,LooseSource


Route),andestimationsbasedonReturnTTL.Noneoftheseapproachesareguaranteedtoworkuniversally.This isdue to the fact thateachhop in the involvedroutecanbeconfiguredindependentlyandbehavesdifferentlyforeachapproach.Forexample,someIP routers are known to discard IP packetswith any of the Record Route options bydefault; some do not respond to ICMP traceroute requests, but will respond to UDPtraceroute. Therefore, each of these approaches will be implemented as a pluggablemodule.Thishelpsustoprioritizeimplementationofsomeofthemandtodevelopandto test them individually. It alsohelpsus to compare resultsof eachmoduleand thusdeterminethehopcountwithgoodconfidenceshouldmultiplemodulesdeterminethesamenumberofhops.

Route metrics monitor is tasked with the responsibility of determining the latency,bandwidthandpacketlossinanetwork.Themetricsareobservedforeachorsomeofthetrafficsentbyhigher layerapplications. Inthecasewherethemetricsneedstobekeptupdatedwithoutapplicationlayer,dummytrafficisused.Theobservedmetricsfortheindividualpacketsaresubjectedtostatisticalfilteringwithboundedhistorytoevenoutnoise.

BGPmonitorobservesBGPupdates for anomalies andanticipated changes in existingroutes. BGP updates are collected from different vantage points such as PlanetLab[C+03]and/or3rdpartyproviderssuchasRouteViewsProject1.SinceBGPdata isnotexpectedtobeavailableinmostdeploymentscenarios,weconsideritasoptional.

The anomaly detectormaintains a history of inputs from themonitors and processesthemthroughstatisticalanalysis.Thisanalysisconsiderstheavailabledata,bothcurrentand historical, to identify changes to the route. If a change is perceived, an alert ispropagatedtotheapplicationusingtheAPI.

3.3.3 API

The API consists of calls to get information aboutmetrics of a route. Since these arestatisticalmeasurements,thecallsreturnthemetricsandpredictederrorbounds.Thisinformation isprovidedsynchronously.TheAPIalso supports registeringcallbacks sothat applications can be notified asynchronously through registered callbacks uponspecificevents.

route_register(source, destination, modules)

This function registers a route between given source and destination to bemonitored.Itinstantiatestherouteobjectwiththenecessarymonitoringmodules.

1. source:thesourceaddress2. destination:thedestinationoftheroute3. modules:listofvariousroutemonitoringmodulestobeusedformonitoringthis

route.Thechoicedeterminestheroutemonitoringmetricsthatwillbeavailableforthisroute.

route_get_info(route, metric_type)

1. route:therouteobjectwhichiscreatedfromanearliercalltoroute_register1 https://www.routeviews.org/


2. metric_type: the type of themetric to be used. This depends on themodulesregisteredformonitoringtherouteinthecalltoroute_register

3. return: thecorrespondingroutemetricobject. Ifnometrictypeisavailable,anerrororanexceptionisthrown.

route_monitor_callback(closure, event, route_metrics)

This is the type of callback to be implemented by an application interested inmonitoring the route. After implementing this callback, it should be registeredwith acalltoroute_monitor().Itwillthenbecalledasynchronouslywheneveraninterestingeventhappens.Theeventscouldbeachangeinthenumberofhops,changeintheTTLnumber,etc.

1. closure: a pointer to a block of memory which is registered along with thiscallback. This is used to associate the callback with some state informationdefinedbytheapplication.

2. event:theeventduetowhichthiscallbackiscalled3. route_metrics:theassociatedmetricobject.4. return:nothing.

route_monitor(route, events, monitor_callback, closure)

Registeramonitoringcallbackforaroute.

1. route:therouteobjectforwhichthismonitoringcallbackhastoberegistered.2. events:setofeventsofinterestforthecaller.Aneventfromthissetwilltrigger

thecallback3. monitor_callback:thecallbacktobecalledwhenaneventhappens4. closure:Statewhichshouldbeassociatedwiththecallback.Itwillbeavailablein

thecallbackasthefirstargumentwhenthecallbackiscalled.5. return:amonitoringhandlewhichcanbeusedtocancelthemonitoringofthis

routeandtherebyunregisteringthecallback.

route_monitor_cancel(monitor)

Cancelapreviouslyregisteredmonitoringcallback

1. monitor:monitoringhandlepreviouslyobtainedfromroute_monitor.

3.4 Multi-pathcommunication

3.4.1 Description

Multi-pathcommunicationconsists in dividing thedata to be sent over a network andsplititacrosstwoormorepaths,spreadingonthesourceandsinkingonthedestination.This idea may allow providing data confidentiality even if the attacker can breakcryptographicprotocolslikeTLS.

A problem faced by implementing multi-path routing is the possibility of having alimitednumberofchannelswheretodistributetheinformationduetopathfailures.Forexample, assume a network composedby tenpossible paths froma certain source todestination,whereonlytwopathsareavailabletosendthedata.Thesepathfailurescanbe causedbydifferent reasons, but, in this case, it is important to study thedenial ofserviceorselectiveforwardasthemainmaliciouscauseforthesefailures[SP10].


Thisserviceprovidesanadditionallayerofsecuritybydistributingthecommunicationthrough several channels. In order to do so, four mechanisms can be leveraged. Thecommunication starts with path discovery, where network nodes (routers or otherdeviceswithroutingcapabilities)arediscovered,i.e.,thesourceacquiresinformationonwhich nodes it can send the information through. This discoverywill be based on anupperandlowerboundongeographiclocation.Usingatopology-awareandtrust-baseddecisionalgorithm,severalnodesfromdifferentInternetServiceProvidersarechosen,accordingtotheirlocationandtrustlevel–thisapproachiscalled(1)Multi-homing.Thetrustleveliscalculatedaccordingtotheamountofpacketsdroppedandresponsetimetothesourceinthediscoveryphase.Thisselectionandthenumberofnodesusedwillbebasedintheamountofphysicalpathsavailableandtheamountofinformationtobesent.Eachnodewillcreateasingle-hopoverlaylinktothedestination,generatingan(2)OverlayNetwork. Successively the packets are split among the different overlay linksthat were previously created and sent to the destination using Multi-path TCP (3)MPTCP[FRHB13].ThisprotocolisanextensionofthegenericTCPimplementationthathastheabilitytodistributeandsenddatabetweendifferentinterfacesorIP-addresses.Therefore,itwillbeusedtodistributethedataamongalllinksintheoverlaynetwork.Inthe case when not enough channels are acquired to provide resilience against theinterceptionofpackets,(4)NetworkCodingisappliedtothepacketsinordertoprovidesomeresistancetotheseeavesdroppingattacks.

Somerequirementsfortheserviceare:

• Thepathselectionshouldbeasphysicallydisjointaspossible;• Thepathselectionshouldberandomizedaccordingto lowerandupperbounds

ofgeographiclocation;• The framework should resort to network coding when there are not enough

pathstouse;• The security of communication should always overcome the performance,

howevertheperformanceshouldbeacceptable.

3.4.2 Components

Implementing this architecture requires a set of components other than thecommunicatingendpoints.

Forimplementingapplication-layerroutingasetofnodeshavetobeusedtoroutethedata.Wecallthesenodesrelays.Theserelayswilltypicallybeserversinthecloudsthatimplement the SafeCloud architecture. Nevertheless, additional computers may beobtained for that purpose. In this case, it is useful to increase the diversity of theavailablechannels.Thesecomputerscanberentedtoadditionalcloudserviceproviders,or provided by interested users (e.g., large companies committed to supporting theSafeCloudarchitecture).

Thesecondcomponentisamembershipservicethattrackswhichnodesareavailabletoplaytheroleofrelaysateachmoment.Thiscomponentiscriticalfortheavailabilityofthe communication, so it has to be secure, dependable, and disaster-tolerant. Weenvisage to implement this service on top of a coordination service called DepSpace[BAC+08].DepSpaceisreplicatedsoifthesereplicasarescatteredgeographicallyitcancontinue operating, even if disasters occur. Moreover it uses Byzantine fault-tolerantprotocolstoprovidedataintegrityandavailabilitydespiteintrusionsinasubsetofthe


servers.Thisservicewillkeepalistofactiverelays,removingthemfromthelistiftheyare unavailable. DepSpace is a tuple space, not a membership service, but it can beprogrammedforthatpurpose.

3.4.3 API

TheAPIof theservice isagainessentially thesocketsAPI,with twoextra functions todefineandgetthenumberofchannelstouse:

• setNChannels()• getNChannels()


4 Architecture

This section presents the first version of the private communication middlewarearchitecture, the coreof thisdeliverable.Thisarchitectureexpresseshow the serviceswillbedeployed,soitmaystillbereviseddependingontheevolutionoftheproject.ThefinalversionofthearchitecturewillappearindeliverableD1.3.

The purpose of the SafeCloud middleware is to provide private and secure unicastcommunication within the SafeCloud architecture. In terms of privacy/security themiddlewareaimstoprovidefourpropertiesdespitethethreatsexplainedinSection2:

• ConfidentialityorPrivacy2:absenceofdisclosureofdatatounauthorizedparties;• Integrity:absenceofunauthorizedmessagemodifications;• Authenticity: absence of personification of message senders (i.e., the message

senderistheoneindicatedinthemessage);• Availability:themiddlewareshallbereadytoprovideitsservicewhenrequested.

4.1 Middlewareentities

FromSection3itispossibletoextractthemainentitiesofthearchitecture:

Endpoints.Thesearethecomputersinvolvedinthecommunication:servers,desktops,laptops,smartphones,tablets,etc.Thecommunicationtakestwobasicflavors:machine-to-cloud(i.e.,betweenexternalendpointsandcloudendpoints),andcloud-to-cloud(i.e.,betweenendpointsinclouds).

Publickey infrastructure (PKI). Themiddleware assumes that every endpoint has along-termpublic-privatekeypair,withthekeysizeselectedtobesecure inthe future(i.e., “expected to remain secure in 10-50 year lifetime”) according to ENISA’srecommendations [Eni14]. The public key of this key pair is distributed usingcertificatesthroughaPKI.ThePKIiscomposedofseveralcomponents[CSF+08]:3

• Certificationauthorities (CAs): entities that generate certificates; CAs should bereplicated using intrusion-tolerant schemes [ZSR02,VCB+13] so they can beresilientbeforestrongadversaries;

• Registration authorities (RAs): components to which CAs may (optionally)delegatecertainmanagementfunctions,e.g.,theenrollmentofusers;

• CRL issuers: components that generate and sign certificate revocation lists(CRLs);

• Repositories:componentsthatstoreanddistributecertificatesandCRLs.

Certificate notary (CN). This notary service will be provided by some SafeClouddeploymentsbyrunningtheCrossbear[HRK+12]notaryservice.Thecertificatesofthe

2 The term privacy is also used in the sense of confidentiality of personal data. Here we consider it in a broader sense of confidentiality of any data being transported in messages.

3 Endpoints (end entities in the RFC nomenclature) may also be considered part of the PKI but we leave them out for the purpose of considering the PKI a service.


notaries will be included with the middleware to avoid man-in-the-middle attacksagainst the notaries. The notaries provide the certificate verification service toSafeCloudendpointsasadefenseagainstSSLman-in-the-middleattacks.

Relaying infrastructure. The multi-path communication service involves sendingmessages throughdifferentphysicalpathsover the Internet.The IPprotocoldoesnotprovide to endpoints the option to define the network layer path, so this has to beimplemented at application layer, using an overlay network and multi-homing. Therelayinginfrastructurehastwomaincomponents:

• Relays: the relays are the intermediate nodes of the overlay network, i.e.,computers, typically servers, that support application layer routing for multi-path communication purposes. The relays will provide a simple forwardingservice so, from the security point of view, they are criticalmainly in terms ofavailability.

• Relay membership service (RMS): an online database of relays, which can bejoinedandleftbyrelaysthatcomeonlineorgoofflineforsomereason.Fromthesecuritypointofviewthiscomponentiscriticalforavailabilitysoitisreplicatedusing intrusion-tolerant schemes, similarly to CAs. This service can beimplemented using an intrusion-tolerant coordination service like DepSpace[BAC+08].

4.2 Topologicalarchitecture

The topological architecture consists in deploying these components in theenvironment.Veryroughlywecanconsiderthreebasicrealms:

• SafeCloudclouds: theSafeCloudcloudswheredataandprocessingarescatteredforsecuritypurposes;

• SafeCloud users: users/consumers of the SafeCloud architecture, typicallycompaniesandotherorganizationsorindividuals;

• Third-parties: other organizations, e.g., a PKI or an organization contracted formonitoringorrelaying;suchorganizationsmayevenbecloudserviceproviders,buttheircloudsarenotSafeCloudclouds.

Figure4representstheabstracttopologicalarchitectureofSafeCloud,withNSafeCloudclouds,N’SafeCloudusernetworks (organizations), andN’’ third-parties.The Internetinterconnects these networks. We say that this is an application layer view of thearchitecture in the sense that it only presents components that implement thewholeOSI/Internetstack.


Figure4.Abstracttopologicalarchitecture:NSafeCloudclouds,N’SafeCloudusernetworks,andN’’third-parties,allinterconnectedbytheInternet.

Thereareseveraloptions intermsofhowthecomponentsof theprevioussectionareplacedintherealms:

• Endpoints:canbeatSafeCloudcloudsorusers;• PKIcomponents:canbeatSafeCloudcloudsorthird-parties;• Certificatenotary:servicescouldbeinstalledatsomeSafeClouddeploymentsor,

alternativelyrunthroughthird-partycloudserviceproviders;• Relays: may be at SafeCloud clouds, third-parties, or even at large SafeCloud

userswillingtocommittotheoperationoftheSafeCloudarchitecture;• Relaymembershipservice:placedtypicallyatSafeCloudclouds.


Figure5.Topologicalarchitecture:applicationlayerview;nothirdparties.

Figure5 represents amore concrete topological architecturewithNSafeCloud cloudsandN'SafeCloudusers,showingalsothemiddlewareservices,someofthemreplicated,andafewendpoints.Figure6presentsasimilararchitecture,nowincludingonethird-partythatprovidesaPKIservice.

Figure6.Topologicalarchitecture:applicationlayerview;onethird-partyprovidingthePKIservice.


Figure7providesanetworklayerviewof thearchitecture inFigure5,as itshowsalsodevicesthatimplementtheprotocolstackuptothatlayer.Thismeansadding(networklayer) routers to Figure 5. This allows us to show multi-path communication usingdifferentnetworkpaths,meaningdifferent(networklayer)routersandlinks.

Figure7.Topologicalarchitecture:networklayerview;nothird-parties.EndpointAcommunicateswithendpointBusing2-pathcommunication.

4.3 Softwarearchitecture

The software architecture will differ considerably between endpoints and othercomponentssuchasRMSorCAs.

4.3.1 Userendpoints

InendpointsthemainSafeCloudsoftwarecomponentsare:

• SafeCloud Client Library (SCCL) – used to implement applications that use themiddlewareforcommunication;providestheAPIpresentedinSection4.4.

• SafeCloud Client Agent (SCCA) – a process that runs in background andimplements some of the services that require activity at the client side, e.g.,monitoringthediversityanderrorrateofoverlaypaths.

Moreoverweenvisagetheneedofusingthemiddlewaretoprovidetunnelstotransportthe communication of legacy applications. The most obvious example is webcommunication.Tosupportitweconsiderthefollowingcomponent:

• SafeCloud Web Proxy (SCWP) – it allows browsers to use SafeCloud’s securechannels;itusestheAPIsofthemiddleware,implementedbytheSCCL.

Figure8representsthesecomponents.


Figure8.SafeClouduserendpointsoftwarearchitecturewithonebrowserandseveralapplicationsusingthemiddleware.

4.3.2 Othercomponents

Thenon-endpointcomponentsareimplementasdaemonsrunninginservers.Severalofthesecomponentscanbe instantiated in thesamephysicaland/orvirtualservers.Forexample, if the RMS and the CA both have 4 replicas, we can have only 4 physicalservers,eachoneplayingboththeroleofRMSreplicaandCAreplica.However,securityconsiderationshavetobetakenintoaccountwhensharingphysicalmachinesthisway.

There is one daemon per component (e.g., one for relays, one for RMSs, one for CAs,etc.).Howevertherearecomponentsthatareusedbyalldaemons:

• SafeCloudServerLibrary(SCSL)–server-sideofSafeClouds’securechannels.• SafeCloud Server Agent (SCSA) – a process that runs in background and

implementssomeoftheservicesthatrequireactivityattheserverside,similarlytotheSCCA.

Thereisalsoaspecificdaemonforsupportingstockwebapplications:

• SafeCloud Reverse Web Proxy (SCRWP) – a server-side proxy that receivesrequestsandsendsrepliesusingSafeCloud’smiddleware(securechannels)andcalls web applications running in unmodified web or application servers (e.g.,Apache,Tomcat,orWildFly/JBoss).

Figure9representsthesecomponents.

Figure9.SafeCloudnodesoftwarearchitecturewithoneweb/applicationserverandseveraldaemonsusingthemiddleware(e.g.,Relay,RMS,CA).


4.4 API

TheAPIhastwoparts:

• CommunicationAPI(providesprimitivestosendandreceivemessages)• Management API (provides primitives to manage the middleware and the

communication,e.g.,formonitoring,add/removerelays,etc.)

ThefunctionsoftheAPIarethosedescribedintheprevioussection.Table2summarizesthisinformation,mentioningthesectionthatdescribeseachpart.

APIPart Service APIFunctions Section

CommunicationAPI

Vulnerability-tolerantchannels

+

Multi-pathcommunication

SSLServerSocketFactory.getDefault()sslServerSocketFactory.createServerSocket()sslServerSocket.accept()sslSocket.getInputStream()SSLSocketFactory.getDefault()sslSocketFactory.createSocket()sslSocket.getOutputStream()

3.1.3

ManagementAPI

Vulnerability-tolerantchannels

– 3.1.3

Protectedserviceprovisioning

knock_open() 3.2.3

Routemonitoring register_route()route_get_info()route_monitor_callback()route_monitor()

3.3.3

Multi-pathcommunication

setNChannels()getNChannels()

3.4.3

Table2:SafeCloudmiddlewareAPI.


5 Conclusion

This document presents the first version of the SafeCloudmiddleware,which aims toprovide the same properties as common secure channels (e.g., SSL/TLS, IPsec) –confidentiality, integrity, and authenticity – plus availability, but assuming powerfuladversaries that may be able to break some of the assumptions that make existingchannelssecure(e.g.,thatacertaincryptographicalgorithmissecure).

Thedeliverablepresents:

• Thethreatsthatthemiddlewareisaimedtohandle:securechannelcomponentvulnerabilities, service identification, man-in-the-middle attacks, and routehijacking;

• The services the middleware will provide: vulnerability-tolerant channels,protectedserviceprovisioning,routemonitoring,andmulti-pathcommunication;

• Thearchitectureofthemiddleware:itsentities,thetopologicalarchitecture,thesoftwarearchitectureatthenodes,anditsAPI.

Thearchitecturepresentedisnecessarilypreliminary,asthecomponentsarestillbeingdevelopedand there is stillnot a completeunderstandingonhow theywillworkandinteract.ThefinalversionwillappearindeliverableD1.3.


6 References

[ABD+15]D.Adrian,K.Bhargavan,Z.Durumeric,P.Gaudry,M.Green,J.A.Halderman,N.Heninger, D. Springall, E. Thomé, L. Valenta, B. VanderSloot, E. Wustrow, S. Zanella-Béguelin,andP.Zimmermann.ImperfectForwardSecrecy:HowDiffie-HellmanFailsinPractice.InProceedingsofthe22ndACMConferenceonComputerandCommunicationsSecurity(CCS),Denver,CO,October2015.[BAC+08]A.Bessani,E.Alchieri,M.Correiaand J.Fraga.DepSpace:AByzantineFault-TolerantCoordinationService.InProceedingsoftheEuropeanConferenceonComputerSystems(EuroSys).April2008.[BBD+15] B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud, C. Fournet, and M.Kohlweiss. AMessy State of theUnion: Taming the Composite StateMachines of TLS.IEEESymposiumonSecurityandPrivacy,pages1-19,2015.[BFM+10]K.Butler,T.R.Farley,P.McDaniel, and J.Rexford.ASurveyofBGPSecurityIssuesandSolutions.ProceedingsoftheIEEE,Vol.98,N.1,pp.100-122,2010.[C+03] Brent Chun, David Culler, Timothy Roscoe, Andy Bavier, Larry Peterson,MikeWawrzoniak,andMicBowman.2003.PlanetLab:anoverlaytestbedforbroad-coverageservices.SIGCOMMComput.Commun.Rev.33,3(July2003),3-12.[CDF+14]M.Carvalho,J.DeMott,R.Ford,andD.Wheeler.Heartbleed101.IEEESecurity&Privacy,Vol.12,N.4,pp.63-67,2014.[CSF+08]D.Cooper,S.Santesson,S.Farrel,S.Boeyen,R.Housley,andW.Polk.InternetX.509PublicKeyInfrastructureCertificateandCertificateRevocationList(CRL)Profile(RFC5280).May2008.[DH76]W.DiffieandM.Hellman.NewDirectionsinCryptography.IEEETransactionsonInformationTheory,Vol.22,N.6,pp.644-654,1976.[DR08]T.DierksandE.Rescorla.TheTransportLayerSecurity(TLS)Protocol,Version1.2(RFC5246),2008.[Eni14]ENISA.Algorithms,KeySizeandParametersReport–2014.November,2014[F99]H.Feistel.DataEncryptionStandard(DES).FIPSPub46-3,3,1999.[FAB+03]N.Feamster,D.G.Andersen,H.Balakrishnan,M.F.Kaashoek.MeasuringtheEffects of Internet Path Faults on Reactive Routing, ACM SIGMETRICS PerformanceEvaluationReview,Vol.31,N.1,2003.[FRHB13] A. Ford, C. Raiciu, M. Handley, and O. Bonaventure. TCP Extensions forMultipathOperationwithMultipleAddresses.IETFRFC6824.Jan.2013.

[FKC11]A. Freier, P. Karlton, andP. Kocher. The Secure Sockets Layer (SSL) ProtocolVersion3.0(RFC6101),2011.[GSG13]P.Gill,M.Schapira,andS.Goldberg.ASurveyofInterdomainRoutingPolicies.ACMSIGCOMMComputerCommunicationReview,Vol.44,N.1,pp.28-34,2013.[HRE+14] L. S. Huang, A. Rice, E. Ellingsen, and C. Jackson. Analyzing forged SSLcertificatesinthewild.InProceedingsoftheIEEESymposiumonSecurityandPrivacy,pp.83-97,2014.


[HRK+12] R. Holz, T. Riedmaier, N. Kammenhuber, and G. Carle. X. 509 Forensics:Detecting and Localising the SSL/TLS Men-in-the-middle. In Computer Security–ESORICS,pp.217-234,2012.[KAF+10] T. Kleinjung, K. Aoki, J. Franke, A. Lenstra, E. Thom_e, J. Bos, P. Gaudry, A.Kruppa, P. Montgomery, D. Osvik, H. Te Riele, A. Timofeev, and P. Zimmermann.Factorizationofa768-BitRSAmodulus.LNCS6223,pp.333-350,2010.[KFR06] J. Karlin, S. Forrest, and J. Rexford. Pretty Good BGP: Improving BGP byCautiouslyAdoptingRoutes.Proceedingsofthe14thIEEEInternationalConferenceonNetworkProtocols(ICNP),2006.[KS05]S.KentandK. Seo. SecurityArchitecture for the InternetProtocol (RFC4301),2005.[L14] A. Langley. The POODLE bites again. https://www.imperialviolet.org/2014/12/08/poodleagain.html,Dec.2014.[L98] S. Lucks. Attacking Triple Encryption. In Proceedings of the 5th InternationalWorkshopinFastSoftwareEncryption(FSE),pp.239-253,1998.[M79] R. C. Merkle. Secrecy, Authentication, and Public Key Systems. PhD thesis,Stanford,CA,USA,1979.[MDK14]B.Möller,T.Duong,andK.Kotowicz.ThisPOODLEBites:ExploitingTheSSL3.0Fallback.SecurityAdvisory.Goole.Sep.2014.[MH81] R. Merkle and M. Hellman. On the Security of Multiple Encryption.CommunicationsoftheACM,Vol.24,N.7,pp.465-467,1981.[ML14]B.MöllerandA.Langley.TLSFallbackSignalingCipherSuiteValue (SCSV) forPreventingProtocolDowngradeAttacks(DRAFT).https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00,2014.[MOV96] A. Menezes, P. van Oorschot, and S. Vanstone. Handbook of AppliedCryptography.CRCPress,1996.[NIST12]NIST. Recommendation for KeyManagement - Part 1: General. NIST SpecialPublication800-57,Revision3(July):1-147,2012.[PS03] V.N. Padmanabhan and D.R. Simon. Secure Traceroute to Detect Faulty orMaliciousRouting.ACMSIGCOMMComputerCommunicationReview,Vol.33,N.1,pp.77-82,2013.[R92]R.Rivest.TheMD5Message-DigestAlgorithm(RFC1321),1992. [RLH06]Y.Rekhter,T.Li,S.Hares:ABorderGatewayProtocol4(RFC4271).Jan.2006.[RS92] C. Rackoff andD. Simon. Non-Interactive Zero-Knowledge Proof of KnowledgeandChosenCiphertextAttack.AdvancesinCryptology(CRYPTO),pp.433-444,1992.[RSA78]R.Rivest,A.Shamir,andL.Adleman.AMethodforObtainingDigitalSignaturesandPublic-KeyCryptosystems.CommunicationsoftheACM,Vol.21,N.2,pp.120–126,1978.[S15]B.Schneier.SHA-1FreestartCollision.https://www.schneier.com/blog/archives/2015/10/sha-1_freestart.html,2015.[S90]W.R.Stevens.UnixNetworkProgramming.PrenticeHall,NewYork,NY,1990.


[SCB13]Schlamp,J.,Carle,G.,Biersack,E.W.AForensicCaseStudyonasHijacking:theAttacker'sPerspective.ACMSIGCOMMComputerCommunicationReview,Vol.43,N.2,pp.5-12,2013.[SHS15] Y. Sheffer, R. Holz, and P. Saint-Andre. Summarizing Known Attacks onTransportLayerSecurity(TLS)andDatagramTLS(DTLS)(RFC7457),2015.[SKP15] M. Stevens, P. Karpman, and T. Peyrin. Freestart Collision on Full SHA-1.CryptologyePrintArchive,Report2015/967,2015.[SP10]E.StavrouandA.Pitsillides.ASurveyonSecureMultipathRoutingProtocolsinWSNs.ComputerNetworks,54(13):2215-2238,2010.[Ss12]B.Schneier.WhenWillWeSeeCollisionsforSHA-1?,2012.[S95] P. Shor. Polynomial-Time Algorithms for Prime Factorization and DiscreteLogarithms on a Quantum Computer. SIAM Journal on Scientific and StatisticalComputing,26:1484,1995.[St12]M.Stevens.AttacksonHashFunctionsandApplications.PhDthesis,2012.[STW12] R. Seggelmann,M. Tuexen, andM.Williams. Transport Layer Security (TLS)andDatagramTransportLayerSecurity(DTLS)HeartbeatExtension(RFC6520),2012.[V15] F. Valsorda. Logjam: the latest TLS vulnerability explained.https://blog.cloudare.com/logjam-the-latest-tls-vulnerability-explained/,2015.[VCB+13] G. S. Veronese, M. Correia, A. N. Bessani, L. C. Lung, P. Verissimo. EfficientByzantineFaultTolerance.IEEETransactionsonComputers,vol.62,n.1,pp.16-30,Jan.2013.[WY05] X. Wang and H. Yu. How to Break MD5 and Other Hash Functions. InProceedingsofthe24thAnnualInternationalConferenceonTheoryandApplicationsofCryptographicTechniques(EUROCRYPT),pp.19–35,2005.[YL06] T. Ylonen and C. Lonvick. The Secure Shell (SSH) Protocol Architecture (RFC4251),2006.[ZSR02]L.Zhou,F.B.Schneider,andR.VanRenesse.COCA:ASecureDistributedOnlineCertificationAuthority.ACMTransactionsonComputerSystemsVol.20,N.4,2002.

private communication middleware architecture d1...d1.1 - private communication middleware...

Documents