Efficient Quantum-Resistant Trust Infrastructure based onHIMMO

Oscar Garciacutea MorchoacutenPhilips Group Innovation

ResearchEindhoven The Netherlands

oscargarciaphilipscom

Sauvik BhattacharyaPhilips Group Innovation

ResearchRWTH Aachen University

Eindhoven The NetherlandsAachen Germany

sauvikbhattacharyaphilipscom

Ronald RietmanPhilips Group Innovation

ResearchEindhoven The Netherlands

ronaldrietmanphilipscom

Ludo TolhuizenPhilips Group Innovation

ResearchEindhoven The Netherlands

ludotolhuizenphilipscom

Jose Luis Torre-ArcePhilips Group Innovation

ResearchEindhoven The Netherlands

joseluistorrearcephilipscom

Maarten BodlaenderPhilips Group Innovation

ResearchEindhoven The Netherlandsmaartenbodlaenderphilipscom

ABSTRACTSecure Internet communications face conflicting demandswhile advances in (quantum) computers require strongerquantum-resistant cryptographic algorithms the Internetof Things demands better-performing protocols Finallycommunication links usually depend on a single root-of-trusteg a certification authority which forms a single point-of-failure that is too big of a risk for future systems

This paper addresses these problems by proposing a hybridinfrastructure that combines the quantum-resistant HIMMOkey pre-distribution scheme based on multiple Trusted ThirdParties with public-key cryptography During operationany pair of devices can use private HIMMO key materialand public keys to establish a secure and authenticated linkwhere their public keys are certified beforehand by multipleTTPs acting as roots of trust Our solution is resilient tothe capture of individual roots of trust without affecting per-formance while public-key cryptography provides featuressuch as forward-secrecy Combining HIMMO identities withpublic keys enables secure certification of public keys anddistribution of HIMMO key material from multiple TTPswithout requiring an out-of-band channel The infrastructurecan be tuned to fit Internet of Things use-cases benefitingfrom an efficient non-interactive and authenticated key ex-change or to fit use-cases where the use of multiple TTPsprovides privacy safe-guards when lawful interception is re-quired

Our TLS proof-of-concept shows the feasibility of our pro-posal by integrating the above security features with minimalchanges in the TLS protocol Our TLS implementation pro-vides classic and post-quantum confidentiality and authenti-

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page Copyrights for components of this work owned by others than ACMmust be honored Abstracting with credit is permitted To copy otherwise or republishto post on servers or to redistribute to lists requires prior specific permission andor afee Request permissions from permissionsacmorg

ccopy 2016 ACM ISBN 978-1-4503-2138-9

DOI 1011451235

cation all while adding a computation overhead of only 28and communication overhead of approximately 50 bytes to apre-quantum Elliptic Curve Diffie-Hellman ciphersuite

KeywordsPost-Quantum Cryptography Authentication Root of TrustHIMMO TLS Security Architecture

1 INTRODUCTIONSecure and (mutually) authenticated Internet communi-

cations are absolutely essential today especially in scenar-ios involving access to secure infrastructure or networkssuch as in remote procedure calls [36 25] server-server com-munication [25] virtual private networks (VPN) SCADA(Supervisory control and data acquisition) networks [35]Machine-to-Machine communication and in specific Internetof Things (IoT) use-cases However existing security infras-tructures are under stress due to several reasons First assoon as a large enough quantum computer is built Shorrsquosalgorithm [34] can be used to break all public-key algorithmscurrently used in security protocols such as the TransportLayer Security (TLS) protocol This threat has led to therecent NIST and ETSI announcement of future standard-ization plans of post-quantum cryptography [9] Howevermost existing candidates such as those summarized in theETSI report in [15] are not a direct drop-in replacementdue to their large key or signature sizes For instance theMcEliece crypto system [29] requires a 1 MByte public-keyand XMSS [6] involves signatures of tens of KBytes Sec-ond the manipulation of Certification Authorities (CAs) theroots of trust in existing Public-Key Infrastructure (PKI)can have catastrophic consequences as with the hack ofDiginotar Certification Authority (CA) [30] in 2011 or thealleged compromise of Gemaltorsquos key server [22] A thirdaspect to consider is that the scope of the Internet is increas-ing and millions of smart objects are getting connected thattypically have limited resources (energy computation powerstorage) and communicate through resource-constrained net-works Finally secure communications can be used for good

purposes but there are also situations in which they aremisused for crime

Thus the problem statement of this paper focuses on fourchallenges (i) ensuring the availability of security primi-tives and a security architecture that can be resistant toquantum-computers while (ii) still being practical and per-formant in particular taking into account new applicationareas such as the IoT Furthermore (iii) the architectureshould be resilient to the capture of roots of trust in orderto ensure confidentiality integrity and authenticity of com-munications At the same time (iv) the solution should beable to accommodate trade-offs between the right to privacyin legitimate communications and the lawful interception ofcommunication required in specific circumstances

This paper contributes a hybrid architecture combining de-sirable features of traditional PKI and the quantum-resistantHIMMO Key Pre-distribution (KPS) scheme [17][21] to ad-dress these problems specifically targeted at use-cases strictlyrequiring privacy and (mutual) authentication such as theones mentioned at the beginning of this section In our archi-tecture long-term public keys and parameters of devices arecertified by means of HIMMO (by HIMMO TTPs) so thatany pair of devices can efficiently authenticate themselves bymeans of symmetric-key cryptography This addresses theneed of quantum-resistance and efficiency in the solution Atthe same time the usage of public-key cryptography ensuresadvanced security properties such as forward-secrecy and alsoallows for the secure in-band initial distribution of secretHIMMO key material Furthermore the use of public-keycryptography (that is independent from HIMMO and thuscannot be compromised by its TTPs) in combination withHIMMO to protect the communication between parties en-sures confidentiality against eavesdropping by Trusted ThirdParties (TTPs) in strong contrast to how it typically is inthe case of Key Pre-distribution In contrast to a fully hier-archical PKI in which each public-key is usually certified bya single Certification Authority ndash thus forming a single pointof failure ndash our architecture uses multiple TTPs to ensurerobustness For instance multiple TTPs can be placed atdifferent locations and run by independently affiliated au-thorities so that the capture of individual TTPs does notbreak the whole system

Our architecture can be further configured to target differ-ent use cases relying on HIMMOrsquos lightweight nature andperformance to scale from the constrained IoT to more tra-ditional computer networks and the Internet A performantconfiguration for use cases in which operational performanceis critical (eg IoT or real-time communication links) can becreated by using only HIMMO to provide a non-interactiveauthenticated key exchange A generic hybrid configurationfor the Internet can be created by using a combination ofHIMMO and (quantum-resistant) public-key cryptographyto secure communication between parties where the indepen-dence of the public-key cryptosystem from HIMMO protectsagainst possible eavesdropping by TTPs The use of multipleTTPs to certify long-term public keys for authentication inthis configuration further makes it robust against the com-promise of individual TTPs Another configuration usingonly HIMMO to establish secure communication in the archi-tecture is possible specifically for use cases requiring lawfulinterception but with the guarantee of multiple TTPs (thatwould have to unanimously cooperate to intercept communi-cations) to preserve a trade-off with the right to privacy of

legitimate usersThe remainder of this paper is structured as follows After

summarizing background work in Section 2 Section 3 detailssecurity needs at system and protocol level limitations andgoals for our work Section 4 presents our hybrid architecturecombining HIMMO with public-key cryptography and ac-companying protocols Section 5 details our proof-of-conceptbased on TLS in which HIMMO is used to certify public keysand used to create a confidential authenticated TLS sessiondemonstrating integrations both with pre-quantum (ECC)and post-quantum (NTRU) public keys Section 6 providesan overall evaluation of the proposed solution Section 7concludes this paper and points out future research

2 BACKGROUNDThere are different types of security architecturesA Public-Key Infrastructure is built on a number of Certi-

fication Authorities (CAs) in charge of certifying the publickeys of the communicating parties In such an architectureAlice has a publicprivate key pair (PkA SkA) and her pub-lic key PkA is signed by a CA When Alice presents herpublic-key PkA and its certificate CA to Bob Bob can verifyAlicersquos certificate and therefore her public-key if it wassigned by a common CA PKI scales well in many use casesand it is widely used to protect the Internet

Security architectures based on Kerberos [27] rely on aTrusted Third Party (TTP) called a Key Distribution Cen-ter (KDC) The KDC enables secure and authenticatedcommunication between Alice and Bob When Alice wantsto communicate with Bob Alice will contact the KDC thatwill provide her with a ticket enabling her to communicatesecurely with Bob Kerberos is a widely used solution egin operating systems to enable the authentication of usersand services The main challenges with Kerberos are thatthe KDC is required during normal operation and that it iscapable of monitoring all communications

Architectures based on Key Pre-distribution (KPS) alsorely on a TTP which owns some secret root key material RWhen a party eg Alice enrolls with the TTP it providesher with key material that depends on R and her identityThis key material is thus unique to Alice and is kept privateby her Once two entities have been enrolled they canestablish a common symmetric-key based on their respectivekey materials and identities in a stand-alone manner Thiscommon symmetric-key can be used for achieving mutualauthentication or for securely exchanging data The mainchallenge of KPS since the introduction of the concept in1987 by Matsumoto and Imai [28] has been the design of aKPS that is operationally efficient and remains secure evenif many devices have been compromised

The advent of quantum computers has motivated theNIST announcement [9] of the standardization of quantum-resistant algorithms that should replace the currentlystandardized public-key primitives namely RSA and ECCused in PKI There are four main types of quantum-resistantpublic-key algorithms lattice-based code-based multivari-ate polynomials and hash-based Examples of these classesof algorithms are NewHope [2] and Frodo [4] McEliece [29]Rainbow [11] and XMSS [6] However none of the existingproposals seems to be a drop-in replacement for existingalgorithms in all use cases due to the lack of security analysisor low performance

The HIMMO scheme has been introduced as an efficient

and collusion- and quantum-resistant KPS [17][19][21] Inits basic version (see Appendix B for further details) thereis a single TTP owning secret root key material R(x y)During enrollment the TTP provides Alice with a secretfunction sA in a secure way known as Alicersquos HIMMO keymaterial During operation Alice and Bob can agree on acommon key KAB since sA(B) asymp sB(A) (with the smalldifference between them reconciled by exchanging some non-secret helper data) HIMMOrsquos cryptanalysis relies on latticetechniques [21] and therefore it is considered a potentialquantum-resistant candidate Although it is not a public-keyscheme it enables features such as key generation KAB =sA(B) using publicly-verifiable identities in the place of BIf two parties engage in a mutual authentication handshakeand this handshake is successful then both parties havesuccessfully verified each otherrsquos identities If the identitiesare computed as the hash function of a set of parametersthen all those parameters can also be easily verified

To the best of our knowledge HIMMO is the only knownscheme with these properties Considering related schemesthe work in [31] can be considered as a collusion-resistantKPS but it is not quantum-resistant The work in [33]based on the above protocol [31] achieves authenticated key-exchange however being based on pairings it is less efficientthan HIMMO and furthermore not quantum-resistant Fur-thermore HIMMO supports multiple TTPs efficiently wherean entity can enroll with multiple TTPs receive key materialfrom each of them and obtain its final keying material asthe (component-wise) combination of these individual keymaterials Thus each of the TTPs only has a partial knowl-edge of the final key material of the entity that is used togenerate the secret key preventing a single point of failureas in a single TTP scenario

The Transport Layer Security (TLS) protocol is used to-day to protect most of the communications in the InternetTLS runs between a client and a server and involves the ex-change of a number of messages during an initial handshakeIn this handshake client and server exchange their sup-ported ciphersuites and engage in a protocol usually basedon public-key cryptography that enables key establishment(mutual) authentication and depending on the protocol usedforward-secrecy Due to the advent of quantum-computersall available ciphersuites will be broken with the exception ofthe one based on pre-shared keys [13] In order to prepare forthis there have been publications in which quantum-resistantcandidates have been integrated with TLS including TLS-LWE [5] or DTLS-HIMMO [19]

In the IETF there are two initiatives to make TLS andInternet Key Exchange (IKEv2) more quantum-resistantThe hybrid TLS handshake in [32] extends TLS in a modularway with quantum-resistant key encapsulation or transportschemes such as NTRUEncrypt [24] In this hybrid hand-shake key establishment is performed by means of both aclassical key establishment scheme eg ECDH and a post-quantum scheme eg NTRUEncrypt in parallel The goalis to have the final secret that protects the actual data de-rived from both the classical and the post-quantum schemesso that an attacker who is recording message exchangesnow cannot later decrypt them once a quantum computer isavailable This hybrid handshake does not include quantum-resistant signatures due to the greater urgency of protectingkey establishment Furthermore there are no good signa-ture candidates exhibiting a good security confidence and

performanceThe Internet Draft in [16] aims at making the Internet

Key Exchange protocol IKEv2 quantum-resistant by usingpre-shared keys next to a standard key exchange aimingfor authenticated and confidential communication betweenan initiator and responder To this end the authors of [16]propose an optional key-exchange and mutual authenticationhandshake based on pre-shared keys This optional keyexchange would happen next to the normal key exchange inIKEv2 providing post-quantum security However [16] doesnot cover how the pre-shared keys can be pre-distributed inan efficient way

3 GOALS amp PROBLEM STATEMENTIn this section we first describe the threat model that we

consider for our security architecture (Section 31) Then westate the goals that our security architecture aims to achievein the context of security operational and performance re-quirements in Section 32 and formally describe the problemaddressed by this work in Section 33

31 Attack ModelIn the advent of a post-quantum world we consider an

attack model in which attackers (not necessary the sameone) can firstly own and run a quantum-computer and breakclassical public-key cryptography algorithms with a quantumcomputer Secondly the attackers are able to compromiseor weaken algorithms with classical attacks without othersknowing it [8] Thirdly attackers can harvest and storeexchanged messages over the Internet during a pre-quantumera and decrypt them once a quantum computer is availableFourthly they can monitor communication links Fifthlythe attackers are able to modify communications between apair of parties Sixthly they are able to compromise roots oftrust such as CAs or TTPs eg [22] or [30] Finally theseattackers are also able to compromise end devices

With these capabilities the goals of the attacker can be notonly to eavesdrop (passive attack) on one specific or multiplecommunication links but also to impersonate (active attack)a person and send fake messages on her behalf

32 Design GoalsIn order to prevent attackers possessing capabilities such as

those described in Section 31 from achieving their goals wewould like a security architecture with the following securityfeatures

bull Confidentiality and integrity of communication links

bull Identification and authentication of all communicatingparties

bull Resilience against the capture of some roots of trust

bull Protocols should be quantum-resistant

bull Advanced security features such as forward-secrecy

Furthermore we also wish to address the trade-off betweenthe right to privacy and the need for lawful interception [14]of communications to prevent or resolve crimes

In addition to above security goals it is of key importanceto also consider operational and performance goals

bull The architecture should facilitate a smooth transi-tion towards quantum resistant solutions with minimalchanges and overhead

bull The architecture should be applicable to as many usecases and applications as possible eg be applicablenot only to secure networks and traditional Internetapplications but also to new ones eg Internet ofThings

bull Apart from security goals performance should be asoptimal as possible in terms of bandwidth computationcost energy and memory

bull The design of constituent protocols in the architectureshould be modular in order to easily add multipleciphersuites also quantum-resistant ones for both keyexchange and digital signatures

33 Problem StatementWhen we consider the above design goals in Section 32

the attack model and the current state-of-the-art reviewedin Section 2 the problem statement of this paper is fourfold

Firstly despite there being many potential quantum-resistantcandidates for key-exchange and authentication none ofthem are a drop-in replacement of existing primitives creat-ing an urgent requirement for practical secure and quickly-deployable quantum-resistant primitives Current quantum-resistant signatures are especially bulky or operationallycumbersome to use For instance hash-based signaturesinvolve an overhead of tens of KBs and in some settingsrequire keeping some state [7] making private keys a criticalresource and key management extremely risky

Secondly the security of communication links in authen-ticated Internet protocols usually fully depends on a singleroot of trust eg a certification authority that is a singlepoint of complete failure This trust responsibility must bedistributed among multiple roots of trust without affectingperformance resulting in resilience to the compromise ofindividual roots of trust

Thirdly the right to privacy and the lawful interception ofcommunication are contradictory goals However both goalsneed to be accommodated in a common architecture so thatusers have the confidence that their data is not monitoredor manipulated but if required and agreed upon in specialcircumstances access by law enforcement to such data canbe enabled

Finally existing protocols and cryptographic primitivesare already considered to be too heavy for the Internet ofThings in particular concerning bandwidth consumptionenergy requirements and strict timing needs Therefore itis a challenge to find an overall solution that fulfills securityrequirements and also exhibits good performance

4 DESIGNThis section describes our hybrid trust infrastructure and

the rationale behind its design The basic design concept istwofold

Firstly use multiple HIMMO TTPs as roots of trust toenable efficient certification and verification of the public keysand other credentials of devices in one-to-one communicationscenarios while preventing single points of failure and thusadding robustness

Secondly use public-key cryptography (ideally quantum-resistant) to enable the secure distribution of HIMMO keymaterial to devices and to enable further advanced securityfeatures like forward-secrecy

The architecture can work with any type of public keysand any KPS We use HIMMO as the KPS since it is (tothe best of our knowledge) the only KPS that enables bothquantum resistant and collusion-resistant key agreement inan efficient way The only other schemes known to resemblea fully collusion-resistant KPS are [31 33 10] however theyare not quantum-resistant

This design approach combines desirable security featuresof both Public-Key Infrastructure and Key Pre-distributionsuch as efficiency offline operation secure initialization lowoverhead forward-secrecy and support for multiple roots oftrust In the following subsections we discuss three aspects(i) roots of trust (ii) the enrollment and certification pro-cedure for a party or device and (iii) operation of a securehandshake between two parties

41 Roots of Trust in a PQ WorldA fully general secure authenticated architecture can con-

sider roots of trust supporting (i) traditional public-key in-frastructure such as the ability to sign digital certificatescontaining public keys and (ii) TTP solutions either requir-ing an online interaction to enable a pair of parties to securelycommunicate with each other (similar to Kerberos) or withonly a TTP involved during the registration of a party (suchas with HIMMO)

In this paper our architecture relies on roots of trustbased on HIMMO TTPs since they are not involved duringoperation ie during actual communication of devicesnodesSecond multiple roots of trust can also be supported in anefficient way to prevent TTPs from becoming single pointsof failure Third the operational features of HIMMO fitin many IoT use cases low bandwidth consumption fastoperation low RAM needs Finally there is a lack of efficientquantum-safe public-key authentication schemes

Therefore our trust infrastructure relies on multiple HIMMOTTPs that maintain secret root key material for some givensecurity parameters These TTPs are managed by multipleindependently located and affiliated organizations so that asecurity breach in one of them does not affect the rest but ifrequired for lawful interception of communications only acoalition of all TTPs could monitor communications TTPsare in charge of certifying parameters of entities that wishto enroll and of distributing key material to them

42 Enrollment amp CertificationThe first phase of our architecturersquos operation is an enroll-

ment and certification phase during which a party can talkto any number of HIMMO roots of trust expose its identifi-cation information and public-key get them certified andsecurely receive HIMMO key material This is similar to thecertification of public keys in todayrsquos PKI or the distributionof key material in existing KPS

It is imperative that the HIMMO key material for a partyremains secret While for IoT scenarios an out-of-band chan-nel for distributing key material is a good option [18] this isnot the case for the Internet The challenge is therefore tosecurely distribute such key material over an open networkWe propose to solve this using the following general enroll-ment approach When an entity Alice wants to get enrolled

Alice TTP (Root of Trust)

Possesses asymmetric key-pair Pka Ska Possesses secret root key material R1 Pka Naminusminusminusminusminusminusminusminusrarr2 EPkaNtlarrminusminusminusminusminusminusminusminusminus

3 Decrypt Nt4 Ntminusminusminusminusrarr

5 Verify Nt

sa(x) = R(hash(Pka) x)6 EPkasa(x)|hash(sa(x)|Na)larrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminus

7 Decrypt key material sa(x)

Verify integrity and Na

Figure 1 Enrollment and Certification of a communicating entity Alice with a root of trust ie a HIMMOTTP resulting in Alice getting her long-term public-key Pka certified and securely receiving private HIMMOkey material sPka(x) that is bound to Pka This key material is created by the HIMMO TTP using itssecret root key material R Na and Nt are random ephemeral nonces that prevent replay attacks and enableverification of the enrolleersquos identity respectively

in the system she generates a publicprivate key-pair (ideallyquantum-resistant) and combines the public-key with anyother identification information Alice then enrolls with oneor several HIMMO TTPs To this end she must send toeach TTP this set of identification information that mustcontain at least her public-key Pka This is demonstrated inStep (1) of Figure 1 that depicts Alicersquos enrollment with asingle TTP

When the TTP receives Alicersquos information it can furtherverify it for consistency and optionally add additional param-eters eg an expiration date creating a certificate of Alicersquosidentity Before this the TTP ascertains Alicersquos identity(to thwart would-be impersonators) by using the public-keyreceived to encrypt and send a random fresh nonce Nt toAlice (Figure 1 Step (2)) that she must then decrypt andsend back to the TTP (Steps (34)) Next given Alicersquoscertificate the TTP computes a HIMMO identity for Aliceby hashing the certificate (containing at least her public-keyPka) and uses this to extract the corresponding HIMMO keymaterial sa(x) for her in Step (5) Therefore through Alicersquosidentity and in turn through the certificate containing Pka(or through Pka directly as in Figure 1) sa(x) generatedfor Alice is now cryptographically bound to Pka In Step(6) the TTP can use Alicersquos public-key Pka to encrypt andsend the computed HIMMO key material sa(x) to her sothat only the owner of Pka can decrypt sa(x) The TTPincludes a hash of the key material in the encrypted messagealong with a nonce Na originating from Alice that acts as anauthentication token This is decrypted and verified by Alicein Step (7) following which she can use her new HIMMOkey material

We note that the final HIMMO key material associatedto Alice can include the HIMMO key material received frommultiple TTPs This information can be stored either with-out being combined or combined into one single instance ofHIMMO key material by adding the componentscoefficientsof multiple HIMMO key materials received from differentTTPs one by one In case of multiple TTPs some commu-nication between them may be required to ensure that theyall generate the same HIMMO identity for Alice

43 Secure Operation

Following the successful enrollment of two entities Aliceand Bob with one or multiple roots of trust they should beable to establish a secure communication session in the abovesetting ie each of them has public keys Pka and Pkb boundto private HIMMO key materials sa(x) and sb(x) In case ofmultiple TTPs these are combinations of the individual keymaterials generated by the TTPs involved We believe thatmany security protocols can be designed in general (a fewexamples of which can be found in Appendix C) throughthe following steps

bull Alice exposes her supported TTPs to Bob

bull Bob decides whether Alice supports at least a minimumnumber of TTPs that he also trusts If not Bob abortsOtherwise Bob exchanges these TTPsrsquo identifiers withAlice so that she can also verify whether that set ofTTPs provides her with enough trust

bull Alice and Bob engage in a handshake for key exchangeand mutual authentication that relies on public-keycryptography (ideally quantum-resistant) to achievestrong properties such as forward-secrecy and on HIMMOto verify the identities of the communicating partiesand thus to ensure an authenticated channel

bull Upon the establishment of a secure channel Alice andBob exchange data in a secure way

The handshake between Alice and Bob resulting in a con-fidential authenticated channel is an adapted form of theBellare-Rogaway AKEP1 [3] with the final session key thatprotects both confidentiality and authentication of the com-munication between Alice and Bob being derived from anadditional random key established using asymmetric cryptog-raphy apart from the HIMMO key (and thus independentfrom HIMMO and its TTPs)

Authentication of public keys happens without traditionaldigital signatures but HIMMO The HIMMO key materialsa(x) of a party A is cryptographically bound to its identity

1authenticated key-exchange protocol

Alice Bob

Possesses asymmetric key-pair Pka Ska and secretHIMMO key material sa(x)

Possesses asymmetric key-pair Pkb Skb and secretHIMMO key material sb(x)

1 Pka Naminusminusminusminusminusminusminusminusrarr2 kHIMMO

ba HelperData = sb(Pka)

Create key k randomly

kba = KDF (kHIMMOba k)

MACba = MACkba (k|Nb|Na)3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusEPka (k) HelperData

4 Decrypt k

kHIMMOba = sa(Pkb) + HelperData

kba = KDF (kHIMMOba k)

Verify MACba using kba

MACab = MACkba (k|Na|Nb)5 MACabminusminusminusminusminusminusminusminusrarr

6 Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 2 Secure Operation for establishing a confidential authenticated channel between two parties Aliceand Bob Authentication is achieved using HIMMO key material bound to long-term certified public keysConfidentiality is achieved using a combination of HIMMO and a shared session key transported usingasymmetric cryptography ideally quantum-resistant Na and Nb are random ephemeral nonces used toprevent replay attacks

which in turn is bound to the partyrsquos public-key Pka Suc-cessful agreement of a HIMMO key between two parties usingauthentic key materials and authentic public-keys results ina successful mutual authentication

Prevention of single points of failure (as in traditional PKI)is accomplished by performing this authentication with keymaterial generated by multiple TTPs preventing imperson-ation of public keys even if some TTPs are compromisedFurthermore this does not affect performance due to the na-ture of HIMMOrsquos operation while using multiple TTPs Theuse of asymmetric-cryptography for key exchange ensuresthat TTPs cannot access the communication and enablesforward-secrecy for advanced use cases eg communicationover the Internet

The above general operational protocol is exemplified ina very specific operational handshake for key exchange andmutual authentication depicted in Figure 2 In this examplea single TTP is commonly supported by the communicatingentities Alice and Bob In Step (1) Alice sends her public-key Pka to Bob along with a fresh nonce Na In Step (2)Bob computes the HIMMO key kHIMMO

ba using HIMMO andadditionally generates a secret random key k Bob thensecurely combines both keys into a session key kba using itto compute a Message Authentication Code (MAC) basedon the random key k the nonce Na received from Alice andanother nonce Nb locally generated Next in Step (3) Bobreplies to Alice exchanging his long-term public-key Pkb hisown nonce Nb and the computed MAC so that in Step (4)Alice can perform equivalent steps at her side and verify thereceived MAC and that Bob computed the same HIMMO keykHIMMOba and therefore verify Bobrsquos public-key Furthermore

Bob also sends the session key k to Alice encrypted usingher public-key

After decrypting and recovering the random key k Al-

ice independently regenerates kHIMMOba by using non-secret

HIMMO helper data sent to her by Bob to reconcile any smalldifference between her own and Bobrsquos computed HIMMOkeys Following this both Alice and Bob possess the samesymmetric HIMMO key kHIMMO

ba the same random key kand thereby the same session key kba Finally in Step (5)Alice sends her MAC to Bob so that he can verify Alicersquoslong-term public-key and the random key k in Step (6) NextAlice and Bob can proceed to communicate in a secure au-thenticated way in Step (7) using the final key kba createdby combining kHIMMO

ba and k to protect their communicationThe structure of this handshake can further be extended to

support more generic use-cases and advanced security proper-ties such as forward-secrecy via the use of ephemeral publickeys to transport the session key between Alice and BobTo illustrate this Appendix C depicts three embodiments ofthis handshake ndash a generic version with any suitable public-key key-establishment scheme PKE and key pre-distributionscheme KPS a version instantiated with the post-quantumNTRU key-exchange and with HIMMO and finally a finalversion instantiated with the forward-secure classic ECDHkey-agreement and with HIMMO as the KPS scheme

5 PROOF-OF-CONCEPT WITH TLS TLS-HIMMO

As a proof of concept we illustrate the above generic archi-tecture by instantiating it in the context of the TLS protocolWe use HIMMO in our proof of concept since it enablesefficient distribution of pairwise keys implicit verification ofcredentials and supports multiple TTPsroots of trust Wefurther use ECDH and NTRUEncrypt [24] as the pre- andpost-quantum cryptographic primitives for key-establishmentand ECDSA as the pre-quantum cryptographic primitive forauthentication

Client Server

1 ClientHello = Ciphersuitesc + TTPListc1+ 2 ClientHellominusminusminusminusminusminusminusminusminusrarr

3 ServerHello = Ciphersuitess + TTPLists + 4 ServerHellolarrminusminusminusminusminusminusminusminusminusminus

5 kHIMMOcs HelperData = s1c(QshPks) +

s2c(QshPks) +

6 ClientKeyExchange =EClassicPks (ClassicS)|EQshPks

(CliS)

|HelperData27 ClientKeyExchangeminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarr

8 Decrypt ClassicS CliS

9 kHIMMOcs = s1s(QshPkc) + s2s(QshPkc) + +

HelperData

10 PMS3= Classic|CliS|kHIMMOcs 10 PMS = Classic|CliS|kHIMMO

cs 11 MasterSecret = PRF (PMS) 11 MasterSecret = PRF (PMS)

12Finishedaminusminusminusminusminusminusminusminusminusrarr13 Verify Finisheda

14Finishedblarrminusminusminusminusminusminusminusminusminus15 Verify Finishedb

16 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using MasterSecret 16 Application Data

1 List of supported HIMMO TTP IDs as per RFC 6066 [12]2 ClassicS CliS are the classic secret and client QSH (assuming [32]) secret respectively3 Pre-master Secret used to generate the TLS Master Secret by means of the TLS pseudo-random function PRF

Figure 3 TLS Handshake including the design proposed in this paper including negotiation of a common setof trusted TTPs and establishment of a confidential authenticated channel protected by a combination of aclassic secret a quantum-safe secret CliS and a quantum-safe HIMMO key The HIMMO key is created usinga combination of key materials obtained from multiple negotiated TTPs and the peerrsquos long-term public-keyideally quantum-resistant

Figure 3 shows the complete TLS handshake between aclient Client and a server Server extended with our designin Section 4 The required additions to support our exten-sions are not many and the main one refers to the capabilityof agreeing on a common set of roots of trust TTPs andagreeing on this type of their use For this we considerRFC 6066 [12] since it defines extensions to the ClientHelloand ServerHello messages in which supported certificationauthorities are exchanged We reuse this extension for ourpurposes as follows

If a client and server have registered with some HIMMOTTPs and obtained HIMMO key material as described in Sec-tion 4 then they exchange the identities of their supportedTTPs Thus in Step (1) of the handshake Client creates aClientHello message including its supported roots of trustie HIMMO TTPs as described in RFC 6066 [12] that isthen sent to Server in Step (2) In step (3) Server searchesfor a common set of HIMMO TTPs that it then includes inthe ServerHello message and sends back to Client in Step (4)If they agree on the usage of HIMMO TTPs they then ex-change certificates or public keys whose hashes are HIMMOidentifiers for which they already possess HIMMO key mate-rial If only classical ciphersuites are considered then suchcertificates correspond to classical primitives eg ECDSAthat are exchanged normally via the ClientCertificate and

ServerCertificate messages If post-quantum keys are sup-ported then an extension header in the ClientHello messageis used (as specified in the hybrid TLS handshake InternetDraft [32]) to exchange additional post-quantum public keysThe exchanged certificates or public keys and correspondingkey material associated to common TTPs allow Client andServer to independently generate pairwise HIMMO keys inSteps (5) and (9) (one key for each common TTP agreedupon) which they then use to independently derive the finalHIMMO key kHIMMO

cs by means of a pseudo-random functionof all previously generated HIMMO keys In the specificexample we describe in Figure 3 Client and Server use eachotherrsquos quantum-resistant public-key to generate kHIMMO

cs insteps (5) and (9) This offers stronger quantum-securityHowever classic public-keys may also be used for this purposeto ease widespread adoption Note that HIMMO requiresa key reconciliation step in which HelperData is exchangedfrom the client and server that we exchange via the Clien-tKeyExchange This is the only protocol field that wouldrequire standardization

To utilize the combined security of HIMMO the classicandor post-quantum key-establishment schemes the TLSMaster Secret used for protecting the TLS record layer iscomputed from a Pre-master secret PMS that is a combi-nation of the classical key Classic the post-quantum key

CliS and the HIMMO key kHIMMOcs This is similar to [32]

and [16] Since the HIMMO key kHIMMOcs is one of the in-

puts to the Master Secret in Steps (10) and (11) via thePre-master Secret PMS it ensures the confidentiality andauthentication of the messages exchanged in the record layerMost importantly it also implicitly verifies the certificatesand public keys of Client and Server since the Master Secretis used in the computation of a Message Authentication Codein the Finished message that both parties must indepen-dently compute exchange and verify (in steps (13) and (15))This MAC is thus bound to the kHIMMO

cs that both partiesindependently computed using the certificates of the otherparty and their own HIMMO key material and can there-fore be considered equal to the MACba exchanged as anauthentication token during the Secure Operation phase (seeFigure 2) The MACrsquos verification by Server and Client willfail unless they computed the right kHIMMO

cs using an authen-tic certificatepublic-key of the other party and proper keymaterial and its success automatically authenticates bothServer and Client to each other

Finally note that the above authentication using HIMMOcan be done using multiple TTPs while also being capableof forward-secrecy and non-repudiation (through the addedincorporation of standard digital signatures) Lawful in-terception use-cases would require the client and server toexclude the exchange of public keys during operation andthus rely only on HIMMO and multiple TTPs to provide aproper privacy trade-off

6 EVALUATIONIn this section we begin with an analysis of the security

provided by our hybrid architecture in Section 61 followedby a quantitative evaluation of its performance in Section 62Section 63 presents a qualitative discussion of the architec-turersquos contributions and quantitatively compares it with thestate of the art

61 Security AnalysisIn this subsection we look at our hybrid architecture and

analyze its security A core contribution of this architectureis imparting quantum-safe authentication and confidentialityto communication channels in a scalable and efficient man-ner The private information possessed by a party ie thesecret HIMMO key material plays a key part in this andmust therefore be securely allocated to the party beforehandSuch confidential distribution of HIMMO key material isachieved by the Enrollment phase as it allows parties toget their public keys certified by (multiple) root(s) of trustand securely receive key materials from them in a manneranalogous to traditional Public-Key Infrastructure Whileallocating a HIMMO key material to an enrolling party aroot of trust encrypts it using the recipient partyrsquos public-keybefore transmitting the key material to it thereby ensuringconfidentiality of the private key material Furthermore thetransmission of a cryptographically-secure hash of the keymaterial along with the actual key material itself allows itsintegrity to be checked by the recipient party Freshnessof the key material received by a party is also ensured andmessage-replay attacks are prevented by the transmission(and verification) of freshly-generated nonces A preventivemeasure against impersonators trying to enroll with the rootof trust is achieved by the use of encrypted nonces at thestart of Enrollment Finally we emphasize once again that

quantum-safe asymmetric cryptography should ideally beused during Enrollment to make sure that the key materialof enrolled parties remains confidential and to prevent re-covery of an enrolling partyrsquos secret HIMMO key materialby a quantum-capable attacker (leading to identity imper-sonation [1]) Using classic public-key cryptography sufficesonly for the short-term to ease widespread adoption

Next we discuss the security of the Secure Operation hand-shake between two parties Authentication of the two partiesrsquolong-term public keys is implicitly and mutually achievedby a successful agreement of the HIMMO key between theparties since it is derived from both the public keys of thecommunicating parties and their private HIMMO keying ma-terials Therefore a successful key agreement automaticallyverifies both partiesrsquo public keys to each other since thisagreement never works unless both parties perform this stepusing authentic certified public keys and proper HIMMOkey materials that have been cryptographically bound totheir certified public keys The same idea also preventsconventional attacks such as a Man-in-the-Middle (MITM)attack on the handshake between Alice and Bob since theauthentication involves both of their private key materialsand certified public keys (exchanged via verifiable certifi-cates) thus making it impossible for the attacker to eitherimpersonate Alice or Bob to the other party

The final key and therefore the actual communication be-tween the parties receives combined protection from bothHIMMO and public-key cryptography In [32] it is argued us-ing the Leftover Hash Lemma [26] that if a secret is composedof two other independent secrets an attacker cannot recoverthe combined secret as long as one of the constituent secretsis unknown to him As a result even if the attacker possessesquantum computing capabilities and is able to recover khe fails to learn the key kHIMMO

ba thus preventing him fromlearning the session key kba In [21] it has been shownthat all attacks on HIMMO found so far lead to lattice-basedcryptanalysis thereby HIMMO provides quantum-security toany scheme that uses keys derived using it Furthermore [20]explicitly contains an analysis of quantum-capable attacks onthe HIMMO scheme Thus the overall communication ben-efits from both classic- and quantum-secure confidentialityand authentication

The architecture is also flexible enough to incorporate addi-tional strong security properties such as forward-secrecy withminimal changes ndash such as using an ephemeral publicprivatekey-pair to transport the random key k between the com-municating parties during the Secure Operation phase (seeFigure 7 in Appendix C for an instantiation)

Finally we note that due to HIMMOrsquos use of multipleTTPs and consequently our architecturersquos use of multipleroots of trust the level of security can be increased n-fold(when using HIMMO key material obtained from n roots oftrust during the Enrollment phase) with almost no corre-sponding increase in computation or communication cost dueto the nature of HIMMOrsquos operation when using multipleTTPs Anything short of a total compromise of all roots oftrust would affect neither confidentiality nor authenticationas the final private HIMMO key material of the enrolledparties and therefore HIMMO symmetric keys generated bythem remain secret in turn ensuring that the final session orMaster secret and therefore the final communication channelalso remains secure

CiphersuiteHandshake time

(ms)Handshake size

(Bytes)

ECDHE ECDSA WITH AES 256 CBC SHA (nistp256) 491 3277

NTRU RSA WITH AES 256 CBC SHA (EES439EP1) 293 5381

ECDHE ECDSA WITH AES 256 CBC SHA HIMMO256 505 3330

NTRU RSA WITH AES 256 CBC SHA HIMMO256 316 5448

NTRU RSA WITH AES 256 CBC SHA HIMMO256 3 TTP 349 5640

Table 1 TLS performance for different ciphersuites including existing classical and hybrid post-quantumciphersuites extended with HIMMO key generation using key material bound with certified public keys asper our design (256-bit HIMMO key with a large security parameter t = 4000) Extensions using both single-TTP and multi-TTP HIMMO implementations are shown The Elliptic Curve key-exchange and signatureimplementations use the NIST P-256 curve providing 128-bits of security NTRUEncrypt key-exchange usethe NTRU parameter set EES439EP1 with a 608 byte public key at 128-bit security

62 Performance Evaluation amp BenchmarksTo validate our research we implement the protocol de-

scribed in Section 5 by extending the CyaSSL library andusing TLSv2 The TLS protocol is executed between twomachines within the same Local Area Network Each ma-chinePC uses Windows 7 Enterprise (64 bit) with an IntelCore i5-5300U 230 GHz Software was compiled for thex86_64 architecture with full optimization (Ox) using theMicrosoft Visual C compiler

Table 1 compares the performance of different TLS hand-shakes using pre- and post-quantum ciphersuites Pre-quantum ciphersuites use ECDHE ECDSA while post-quantumciphersuites rely on NTRU RSA (NTRU is used to encrypta secret that is exchanged the NTRU public-key is signedwith RSA) We compare them after adding HIMMO nextto them using a single TTP The HIMMO parameter b ischosen to be 32 Several HIMMO systems are used in parallelto obtain a 256 bit key The additional time or bandwidthconsumption is minimal while enabling the verification ofpublic keys and generation of a symmetric-secret Further-more the increase in running times of the TLS handshakefor the classic ECDHE ECDSA and the post-quantum ci-phersuite NTRU RSA when extended with HIMMO wherethe HIMMO key is computed from key material assigned bythree TTPs (as per the protocol in Section 5) is minimalEach TTP is managed by a different organization or has in-dependent locations thus preventing a single point of failureExtending the classical ECDHE ECDSA with a single-TTPHIMMO implementation results in a TLS handshake thatis slower by only 28 for the HIMMO security parametert = 4000 (505 ms for the extended ciphersuite as comparedto 491 ms for classic ECDHE+ECDSA) Note that this valueof t is quite conservative [21] the drop in speed of the TLShandshake is minimal by comparison For the post-quantumciphersuite NTRU RSA the increase in computation over-head is 78 for a single-TTP implementation (316 ms forthe single-TTP extended ciphersuite as compared to 293 msfor the original NTRU+RSA one) and 191 for a three-TTPimplementation (349 ms) both cases for t = 4000 A furtheroptimization is possible for the multiple-TTP implementa-tion instead of sequentially creating and combining threeHIMMO sub-keys it is possible to generate a single HIMMOkey after adding the coefficientscomponents of the key ma-terials obtained from different TTPs Once this optimizationis done we expect a timing similar to the usage of a single

of TTP irrespective of the number of TTPs used[21 17] present insights into the efficient lightweight per-

formance of HIMMO It is demonstrated that an increaseof the HIMMO security parameter t to a very high valuethat directly determines the dimension of the lattice thatneeds to be reduced in order to find a closeshort vector [21]still does not have a huge impact in the CPU needs whilebandwidth consumption remains practically constant andequal to a few bytes Memory increases but for applicationareas such as the Internet a storage requirement of a coupleof megabytes is affordable IoT applications have differentperformance criteria communication bandwidth energy con-sumption timing and memory For all of these HIMMO isoptimal By construction HIMMO has low communicationand energy needs since it is identity-based and since wirelesscommunication consumes most of the energy budget Timingis also optimal although key material size is on the high sideEven without optimizations memory is the least relevantcriteria IoT devices are getting bigger memories computersand phones have sufficient memory capabilities

63 Discussion amp ComparisonThe solution proposed in this paper exhibits advantageous

properties compared with other architectures as shown inTable 2 Firstly the usage of HIMMO to create the finalsession key that protects a secure channel between any pair ofdevices makes the operational communication link betweenthem quantum-resistant Secondly the use of an indepen-dent public-key cryptosystem ensures secure distributionof key material during the initial enrollment and preventseavesdropping by rogue TTPs during Secure Operation Thearchitecture supports multiple roots of trust (based onHIMMO TTPs) with low overhead ensuring that the systemremains secure even if individual roots of trust are compro-mised Operationally if a secure channel between partiesis established based on HIMMO only this results in a non-interactive method for key agreement and authenticationideal for IoT scenarios Together with the incorporationof multiple TTPs this configuration of our architecture (iebased on only HIMMO) provides a solid solution for use casesin which lawful interception of communication is requiredAt the same time this does not infringe upon the right toprivacy of legitimate communications since it would requirea unanimous cooperation among all TTPs involved in thecommunication preventing possible abuses of power

Supported Features Traditional PKI Kerberos KPS QSH-TLS [32] DTLS-HIMMO [19] This paper

Quantum-safe confidentiality Depends on PK Yes Yes Yes Yes Yes

Quantum-safe authentication Depends on PK Yes Yes No Yes Yes

Enrollment Secure in-band Out-of-band Out-of-band Secure in-band Out-of-band Secure in-band

Multiple roots of trust Yes (high overhead) No Yes Yes (high overhead) Yes Yes (low overhead)

Non-interactive operation No No Yes No Yes Yes

Forward-secrecy Yes No No Yes No Yes

Authentication overhead High (explicit High (online Low High (explicit Low Low

signature) interaction) (symmetric) signature) (symmetric) (symmetric)

Scalability High Medium Medium Medium High Higher

Table 2 Comparison of the hybrid infrastructure presented in this paper with existing security architecturesfor a number of security and operational features

Figure 4 Comparison of communication overhead in TLS authentication phase when using (a) HIMMO keygeneration-based authentication with one TTP (b) with two TTPs (c) with three TTPs (all using 256-bitHIMMO key with a large security parameter t = 4000) (d) XMSS with 82 bit security (e) NTRUMLS withparameter set 401 [23] and 112 bit security (f) classic ECDSA with the curve nistp256 Data exchanged forauthentication purposes when using our HIMMO-based solution amounts to only HIMMO helper data forkey reconciliation

Considering authentication a HIMMO key material as-signed to a node is bound to its public-key so that theHIMMO key material acts as the nodersquos implicit digital cer-tificate allowing a node to verify public parameters of otherdevices with very low overhead while supporting multipleroots of trust Upgrading to any public-key cryptosystem issimple through the use of the corresponding digital certifi-cate or public-key as the HIMMO identity

Thus the proposed architecture is highly scalable evenif an out-of-band channel is not available as is the case in theInternet and is applicable to a wide range of use cases In con-trast the hybrid TLS handshake in [32] focuses on traditionalInternet applications only and does not support authentica-tion by multiple roots of trust The DTLS-HIMMO work [19]addresses IoT use cases but lacks a solution for in-band en-rollment or the capability of providing forward-secrecy

Considering post-quantum authentication we quantify thegains of our solution by comparing it with two signature

schemes considered quantum-resistant namely XMSS [6]and NTRUMLS [23] XMSS with an h value equal to 8 (iethe height of the XMSS hash tree) allows creating at most 256signatures each approximately 2436 Bytes long and havinga signature verification time of 195 ms [15] NTRUMLSfor parameters 401 and 743 involve signatures of around853 and 1765 Bytes with verification times of 033 and 079ms respectively [15] We note that computationally theactual post-quantum authentication step in our solution iethe generation of the HIMMO symmetric key is 65 fasterthan that of XMSS (067 ms compared to XMSSrsquos 195 ms)and 15 faster than that of NTRUMLS (067 ms comparedto NTRUMLSrsquos 079 ms) considering the relatively secureNTRUMLS parameter set 743 and a high HIMMO securityparameter value of t = 4000

Furthermore Figure 4 compares the communication over-head during TLS authentication comparing the amount ofbytes exchanged by classic and existing post-quantum sig-

natures with that exchanged by the authentication in ourHIMMO-based solution Since this consists of only HIMMOhelper data as compared to full-fledged digital signatures inthe former case our solution has a strong advantage regard-ing communication overhead or signature sizes

Figure 4 also shows that even achieving higher securitythrough the use of multiple roots of trust (ie TTPs) comesat virtually no added cost since the size of the HIMMOhelper data exchanged between parties for key reconcilia-tion only grows logarithmically with the increase in numberof TTPs (ie roots of trust) and not linearly When a n-TTP implementation is used the final key is derived as acombination of n intermediate HIMMO keys each derivedfrom one key material instance (obtained from one root oftrust) with HIMMO parameters t and m However if theHIMMO parameter t is same for all intermediate key mate-rials then the final HIMMO key corresponds to a symbolicHIMMO key material with parameters t and nm The sizeu of the helper data for this HIMMO key would then beu = dlog2(4nmt + 1)e (see Appendix B) which essentiallygrows logarithmically with n For more details about the ex-act nature of HIMMO helper data that leads to this desirablebehavior see Appendix B

In comparison for traditional digital signatures such asXMSS and NTRUMLS (albeit quantum-resistant) to achievethe same increase in security usage of certifications frommultiple CAs is necessary This involves a linear growth ofcomputation overhead (key-pair generation signature gen-eration signature verification) as well as communicationoverhead (exchange of multiple signatures) with the numberof CAs involved Thus the main advantage of our approachrelates to the implicit verification of public keys thatinvolves minimal overhead even with stronger security con-ditions such as multiple roots of trust (see Section 62)

7 CONCLUSIONSWe presented a hybrid security architecture combining

public-key cryptography and key pre-distribution schemesWe chose HIMMO as the KPS instantiation since it is theonly known scheme that is both efficient and collusion- andquantum-resistant The hybrid architecture combines desir-able features of both worlds it is scalable supports secureenrollment and efficient support for multiple roots of trustDue to its non-interactive key agreement the scheme is idealfor use cases with strict timing constraints limited band-width or a tight energy budget as often encountered in theIoT The hybrid scheme also finds a broader application inthe Internet since it allows for efficient verification of pub-lic keys with minimal overhead while providing advancedfeatures such as forward-secrecy

The architecture can already be deployed to improve per-formance of Internet communications in todayrsquos pre-quantumworld while providing a path towards a quantum-resistantyet highly efficient Internet Our TLS proof-of-concept imple-mentation proves this by showing how existing non-quantumresistant communications based on ECC or quantum-safepublic keys such as NTRU public keys can be verified withan increased communication overhead of less than 1 andvery low computational overhead Due to the identity-basednature of the HIMMO scheme the exchanged amount ofdata and time required for key generation remain practicallyconstant even if the HIMMO security parameters are madeextremely large

8 REFERENCES[1] C Adams Impersonation Attack pages 596ndash596

Springer US Boston MA 2011

[2] E Alkim L Ducas T Poeppelmann and P SchwabePost-Quantum Key Exchange ndash A New Hope 2015Cryptology ePrint Archive Report 2015-1092

[3] M Bellare and P Rogaway Entity Authentication andKey Distribution pages 232ndash249 Springer BerlinHeidelberg Berlin Heidelberg 1994

[4] J Bos C Costello L Ducas I Mironov M NaehrigV Nikolaenko A Raghunathan and D Stebila FrodoTake off the ring practical quantum-secure keyexchange from lwe Cryptology ePrint Archive Report2016659 2016 httpeprintiacrorg2016659

[5] J Bos C Costello M Naehrig and D StebilaPost-quantum key exchange for the TLS protocol fromthe ring learning with errors problem 2014httpeprintiacrorg2014599

[6] J Buchmann E Dahmen and A Hulsing XMSS APractical Forward Secure Signature Scheme based onMinimal Security Assumptions 2011httpeprintiacrorg20151003

[7] D Butin S-L Gazdag and J Buchmann Real-worldpost-quantum digital signatures In Cyber Security andPrivacy pages 41ndash52 Springer 2015

[8] S Checkoway R Niederhagen A EverspaughM Green T Lange T Ristenpart D J BernsteinJ Maskiewicz H Shacham and M Fredrikson On thePractical Exploitability of Dual EC in TLSImplementations In 23rd USENIX Security Symposium(USENIX Security 14) pages 319ndash335 San Diego CAAug 2014 USENIX Association

[9] L Chen S Jordan Y-K Liu D Moody R PeraltaR Perlner and D Smith-Tone Report onPost-Quantum Cryptography NISTIR8105 2016httpcsrcnistgovpublicationsdraftsnistir-8105nistir 8105 draftpdf

[10] Y Chen Q Huang and Z ZhangSakai-ohgishi-kasahara identity-based non-interactivekey exchange revisited and more Cryptology ePrintArchive Report 2014310 2014httpeprintiacrorg2014310

[11] J Ding and D Schmidt Rainbow a new multivariablepolynomial signature scheme In Applied Cryptographyand Network Security pages 164ndash175 Springer 2005

[12] D Eastlake Transport Layer Security (TLS)Extensions Extension Definitions 2011 RFC6066

[13] P Eronen and H Tschofenig Pre-Shared KeyCiphersuites for Transport Layer Security (TLS) RFC4279 (Proposed Standard) Dec 2005

[14] ETSI TS 101 331 - V131 - Lawful Interception (LI)Requirements of Law Enforcement Agencies October2009httpsarchiveorgdetailsetsi ts 101 331 v010301

[15] ETSI GRQSC-001 - V111 - Quantum-SafeCryptography (QSC) Quantum-safe algorithmicframework July 2016httpwwwetsiorgdeliveretsi grQSC001 099001010101 60gr QSC001v010101ppdf

[16] S Fluhrer D McGrew and P Kampanakis AnExtension for Postquantum Security using PresharedKeys for IKEv2 2015

and collusion- and quantum-resistant KPS [17][19][21] Inits basic version (see Appendix B for further details) thereis a single TTP owning secret root key material R(x y)During enrollment the TTP provides Alice with a secretfunction sA in a secure way known as Alicersquos HIMMO keymaterial During operation Alice and Bob can agree on acommon key KAB since sA(B) asymp sB(A) (with the smalldifference between them reconciled by exchanging some non-secret helper data) HIMMOrsquos cryptanalysis relies on latticetechniques [21] and therefore it is considered a potentialquantum-resistant candidate Although it is not a public-keyscheme it enables features such as key generation KAB =sA(B) using publicly-verifiable identities in the place of BIf two parties engage in a mutual authentication handshakeand this handshake is successful then both parties havesuccessfully verified each otherrsquos identities If the identitiesare computed as the hash function of a set of parametersthen all those parameters can also be easily verified

To the best of our knowledge HIMMO is the only knownscheme with these properties Considering related schemesthe work in [31] can be considered as a collusion-resistantKPS but it is not quantum-resistant The work in [33]based on the above protocol [31] achieves authenticated key-exchange however being based on pairings it is less efficientthan HIMMO and furthermore not quantum-resistant Fur-thermore HIMMO supports multiple TTPs efficiently wherean entity can enroll with multiple TTPs receive key materialfrom each of them and obtain its final keying material asthe (component-wise) combination of these individual keymaterials Thus each of the TTPs only has a partial knowl-edge of the final key material of the entity that is used togenerate the secret key preventing a single point of failureas in a single TTP scenario

The Transport Layer Security (TLS) protocol is used to-day to protect most of the communications in the InternetTLS runs between a client and a server and involves the ex-change of a number of messages during an initial handshakeIn this handshake client and server exchange their sup-ported ciphersuites and engage in a protocol usually basedon public-key cryptography that enables key establishment(mutual) authentication and depending on the protocol usedforward-secrecy Due to the advent of quantum-computersall available ciphersuites will be broken with the exception ofthe one based on pre-shared keys [13] In order to prepare forthis there have been publications in which quantum-resistantcandidates have been integrated with TLS including TLS-LWE [5] or DTLS-HIMMO [19]

In the IETF there are two initiatives to make TLS andInternet Key Exchange (IKEv2) more quantum-resistantThe hybrid TLS handshake in [32] extends TLS in a modularway with quantum-resistant key encapsulation or transportschemes such as NTRUEncrypt [24] In this hybrid hand-shake key establishment is performed by means of both aclassical key establishment scheme eg ECDH and a post-quantum scheme eg NTRUEncrypt in parallel The goalis to have the final secret that protects the actual data de-rived from both the classical and the post-quantum schemesso that an attacker who is recording message exchangesnow cannot later decrypt them once a quantum computer isavailable This hybrid handshake does not include quantum-resistant signatures due to the greater urgency of protectingkey establishment Furthermore there are no good signa-ture candidates exhibiting a good security confidence and

performanceThe Internet Draft in [16] aims at making the Internet

Key Exchange protocol IKEv2 quantum-resistant by usingpre-shared keys next to a standard key exchange aimingfor authenticated and confidential communication betweenan initiator and responder To this end the authors of [16]propose an optional key-exchange and mutual authenticationhandshake based on pre-shared keys This optional keyexchange would happen next to the normal key exchange inIKEv2 providing post-quantum security However [16] doesnot cover how the pre-shared keys can be pre-distributed inan efficient way

3 GOALS amp PROBLEM STATEMENTIn this section we first describe the threat model that we

consider for our security architecture (Section 31) Then westate the goals that our security architecture aims to achievein the context of security operational and performance re-quirements in Section 32 and formally describe the problemaddressed by this work in Section 33

31 Attack ModelIn the advent of a post-quantum world we consider an

attack model in which attackers (not necessary the sameone) can firstly own and run a quantum-computer and breakclassical public-key cryptography algorithms with a quantumcomputer Secondly the attackers are able to compromiseor weaken algorithms with classical attacks without othersknowing it [8] Thirdly attackers can harvest and storeexchanged messages over the Internet during a pre-quantumera and decrypt them once a quantum computer is availableFourthly they can monitor communication links Fifthlythe attackers are able to modify communications between apair of parties Sixthly they are able to compromise roots oftrust such as CAs or TTPs eg [22] or [30] Finally theseattackers are also able to compromise end devices

With these capabilities the goals of the attacker can be notonly to eavesdrop (passive attack) on one specific or multiplecommunication links but also to impersonate (active attack)a person and send fake messages on her behalf

32 Design GoalsIn order to prevent attackers possessing capabilities such as

those described in Section 31 from achieving their goals wewould like a security architecture with the following securityfeatures

bull Confidentiality and integrity of communication links

bull Identification and authentication of all communicatingparties

bull Resilience against the capture of some roots of trust

bull Protocols should be quantum-resistant

bull Advanced security features such as forward-secrecy

Furthermore we also wish to address the trade-off betweenthe right to privacy and the need for lawful interception [14]of communications to prevent or resolve crimes

In addition to above security goals it is of key importanceto also consider operational and performance goals

bull The architecture should facilitate a smooth transi-tion towards quantum resistant solutions with minimalchanges and overhead

bull The architecture should be applicable to as many usecases and applications as possible eg be applicablenot only to secure networks and traditional Internetapplications but also to new ones eg Internet ofThings

bull Apart from security goals performance should be asoptimal as possible in terms of bandwidth computationcost energy and memory

bull The design of constituent protocols in the architectureshould be modular in order to easily add multipleciphersuites also quantum-resistant ones for both keyexchange and digital signatures

33 Problem StatementWhen we consider the above design goals in Section 32

the attack model and the current state-of-the-art reviewedin Section 2 the problem statement of this paper is fourfold

Firstly despite there being many potential quantum-resistantcandidates for key-exchange and authentication none ofthem are a drop-in replacement of existing primitives creat-ing an urgent requirement for practical secure and quickly-deployable quantum-resistant primitives Current quantum-resistant signatures are especially bulky or operationallycumbersome to use For instance hash-based signaturesinvolve an overhead of tens of KBs and in some settingsrequire keeping some state [7] making private keys a criticalresource and key management extremely risky

Secondly the security of communication links in authen-ticated Internet protocols usually fully depends on a singleroot of trust eg a certification authority that is a singlepoint of complete failure This trust responsibility must bedistributed among multiple roots of trust without affectingperformance resulting in resilience to the compromise ofindividual roots of trust

Thirdly the right to privacy and the lawful interception ofcommunication are contradictory goals However both goalsneed to be accommodated in a common architecture so thatusers have the confidence that their data is not monitoredor manipulated but if required and agreed upon in specialcircumstances access by law enforcement to such data canbe enabled

Finally existing protocols and cryptographic primitivesare already considered to be too heavy for the Internet ofThings in particular concerning bandwidth consumptionenergy requirements and strict timing needs Therefore itis a challenge to find an overall solution that fulfills securityrequirements and also exhibits good performance

4 DESIGNThis section describes our hybrid trust infrastructure and

the rationale behind its design The basic design concept istwofold

Firstly use multiple HIMMO TTPs as roots of trust toenable efficient certification and verification of the public keysand other credentials of devices in one-to-one communicationscenarios while preventing single points of failure and thusadding robustness

Secondly use public-key cryptography (ideally quantum-resistant) to enable the secure distribution of HIMMO keymaterial to devices and to enable further advanced securityfeatures like forward-secrecy

The architecture can work with any type of public keysand any KPS We use HIMMO as the KPS since it is (tothe best of our knowledge) the only KPS that enables bothquantum resistant and collusion-resistant key agreement inan efficient way The only other schemes known to resemblea fully collusion-resistant KPS are [31 33 10] however theyare not quantum-resistant

This design approach combines desirable security featuresof both Public-Key Infrastructure and Key Pre-distributionsuch as efficiency offline operation secure initialization lowoverhead forward-secrecy and support for multiple roots oftrust In the following subsections we discuss three aspects(i) roots of trust (ii) the enrollment and certification pro-cedure for a party or device and (iii) operation of a securehandshake between two parties

41 Roots of Trust in a PQ WorldA fully general secure authenticated architecture can con-

sider roots of trust supporting (i) traditional public-key in-frastructure such as the ability to sign digital certificatescontaining public keys and (ii) TTP solutions either requir-ing an online interaction to enable a pair of parties to securelycommunicate with each other (similar to Kerberos) or withonly a TTP involved during the registration of a party (suchas with HIMMO)

In this paper our architecture relies on roots of trustbased on HIMMO TTPs since they are not involved duringoperation ie during actual communication of devicesnodesSecond multiple roots of trust can also be supported in anefficient way to prevent TTPs from becoming single pointsof failure Third the operational features of HIMMO fitin many IoT use cases low bandwidth consumption fastoperation low RAM needs Finally there is a lack of efficientquantum-safe public-key authentication schemes

Therefore our trust infrastructure relies on multiple HIMMOTTPs that maintain secret root key material for some givensecurity parameters These TTPs are managed by multipleindependently located and affiliated organizations so that asecurity breach in one of them does not affect the rest but ifrequired for lawful interception of communications only acoalition of all TTPs could monitor communications TTPsare in charge of certifying parameters of entities that wishto enroll and of distributing key material to them

42 Enrollment amp CertificationThe first phase of our architecturersquos operation is an enroll-

ment and certification phase during which a party can talkto any number of HIMMO roots of trust expose its identifi-cation information and public-key get them certified andsecurely receive HIMMO key material This is similar to thecertification of public keys in todayrsquos PKI or the distributionof key material in existing KPS

It is imperative that the HIMMO key material for a partyremains secret While for IoT scenarios an out-of-band chan-nel for distributing key material is a good option [18] this isnot the case for the Internet The challenge is therefore tosecurely distribute such key material over an open networkWe propose to solve this using the following general enroll-ment approach When an entity Alice wants to get enrolled

Alice TTP (Root of Trust)

Possesses asymmetric key-pair Pka Ska Possesses secret root key material R1 Pka Naminusminusminusminusminusminusminusminusrarr2 EPkaNtlarrminusminusminusminusminusminusminusminusminus

3 Decrypt Nt4 Ntminusminusminusminusrarr

5 Verify Nt

sa(x) = R(hash(Pka) x)6 EPkasa(x)|hash(sa(x)|Na)larrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminus

7 Decrypt key material sa(x)

Verify integrity and Na

Figure 1 Enrollment and Certification of a communicating entity Alice with a root of trust ie a HIMMOTTP resulting in Alice getting her long-term public-key Pka certified and securely receiving private HIMMOkey material sPka(x) that is bound to Pka This key material is created by the HIMMO TTP using itssecret root key material R Na and Nt are random ephemeral nonces that prevent replay attacks and enableverification of the enrolleersquos identity respectively

in the system she generates a publicprivate key-pair (ideallyquantum-resistant) and combines the public-key with anyother identification information Alice then enrolls with oneor several HIMMO TTPs To this end she must send toeach TTP this set of identification information that mustcontain at least her public-key Pka This is demonstrated inStep (1) of Figure 1 that depicts Alicersquos enrollment with asingle TTP

When the TTP receives Alicersquos information it can furtherverify it for consistency and optionally add additional param-eters eg an expiration date creating a certificate of Alicersquosidentity Before this the TTP ascertains Alicersquos identity(to thwart would-be impersonators) by using the public-keyreceived to encrypt and send a random fresh nonce Nt toAlice (Figure 1 Step (2)) that she must then decrypt andsend back to the TTP (Steps (34)) Next given Alicersquoscertificate the TTP computes a HIMMO identity for Aliceby hashing the certificate (containing at least her public-keyPka) and uses this to extract the corresponding HIMMO keymaterial sa(x) for her in Step (5) Therefore through Alicersquosidentity and in turn through the certificate containing Pka(or through Pka directly as in Figure 1) sa(x) generatedfor Alice is now cryptographically bound to Pka In Step(6) the TTP can use Alicersquos public-key Pka to encrypt andsend the computed HIMMO key material sa(x) to her sothat only the owner of Pka can decrypt sa(x) The TTPincludes a hash of the key material in the encrypted messagealong with a nonce Na originating from Alice that acts as anauthentication token This is decrypted and verified by Alicein Step (7) following which she can use her new HIMMOkey material

We note that the final HIMMO key material associatedto Alice can include the HIMMO key material received frommultiple TTPs This information can be stored either with-out being combined or combined into one single instance ofHIMMO key material by adding the componentscoefficientsof multiple HIMMO key materials received from differentTTPs one by one In case of multiple TTPs some commu-nication between them may be required to ensure that theyall generate the same HIMMO identity for Alice

43 Secure Operation

Following the successful enrollment of two entities Aliceand Bob with one or multiple roots of trust they should beable to establish a secure communication session in the abovesetting ie each of them has public keys Pka and Pkb boundto private HIMMO key materials sa(x) and sb(x) In case ofmultiple TTPs these are combinations of the individual keymaterials generated by the TTPs involved We believe thatmany security protocols can be designed in general (a fewexamples of which can be found in Appendix C) throughthe following steps

bull Alice exposes her supported TTPs to Bob

bull Bob decides whether Alice supports at least a minimumnumber of TTPs that he also trusts If not Bob abortsOtherwise Bob exchanges these TTPsrsquo identifiers withAlice so that she can also verify whether that set ofTTPs provides her with enough trust

bull Alice and Bob engage in a handshake for key exchangeand mutual authentication that relies on public-keycryptography (ideally quantum-resistant) to achievestrong properties such as forward-secrecy and on HIMMOto verify the identities of the communicating partiesand thus to ensure an authenticated channel

bull Upon the establishment of a secure channel Alice andBob exchange data in a secure way

The handshake between Alice and Bob resulting in a con-fidential authenticated channel is an adapted form of theBellare-Rogaway AKEP1 [3] with the final session key thatprotects both confidentiality and authentication of the com-munication between Alice and Bob being derived from anadditional random key established using asymmetric cryptog-raphy apart from the HIMMO key (and thus independentfrom HIMMO and its TTPs)

Authentication of public keys happens without traditionaldigital signatures but HIMMO The HIMMO key materialsa(x) of a party A is cryptographically bound to its identity

1authenticated key-exchange protocol

Alice Bob

Possesses asymmetric key-pair Pka Ska and secretHIMMO key material sa(x)

Possesses asymmetric key-pair Pkb Skb and secretHIMMO key material sb(x)

1 Pka Naminusminusminusminusminusminusminusminusrarr2 kHIMMO

ba HelperData = sb(Pka)

Create key k randomly

kba = KDF (kHIMMOba k)

MACba = MACkba (k|Nb|Na)3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusEPka (k) HelperData

4 Decrypt k

kHIMMOba = sa(Pkb) + HelperData

kba = KDF (kHIMMOba k)

Verify MACba using kba

MACab = MACkba (k|Na|Nb)5 MACabminusminusminusminusminusminusminusminusrarr

6 Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 2 Secure Operation for establishing a confidential authenticated channel between two parties Aliceand Bob Authentication is achieved using HIMMO key material bound to long-term certified public keysConfidentiality is achieved using a combination of HIMMO and a shared session key transported usingasymmetric cryptography ideally quantum-resistant Na and Nb are random ephemeral nonces used toprevent replay attacks

which in turn is bound to the partyrsquos public-key Pka Suc-cessful agreement of a HIMMO key between two parties usingauthentic key materials and authentic public-keys results ina successful mutual authentication

Prevention of single points of failure (as in traditional PKI)is accomplished by performing this authentication with keymaterial generated by multiple TTPs preventing imperson-ation of public keys even if some TTPs are compromisedFurthermore this does not affect performance due to the na-ture of HIMMOrsquos operation while using multiple TTPs Theuse of asymmetric-cryptography for key exchange ensuresthat TTPs cannot access the communication and enablesforward-secrecy for advanced use cases eg communicationover the Internet

The above general operational protocol is exemplified ina very specific operational handshake for key exchange andmutual authentication depicted in Figure 2 In this examplea single TTP is commonly supported by the communicatingentities Alice and Bob In Step (1) Alice sends her public-key Pka to Bob along with a fresh nonce Na In Step (2)Bob computes the HIMMO key kHIMMO

ba using HIMMO andadditionally generates a secret random key k Bob thensecurely combines both keys into a session key kba using itto compute a Message Authentication Code (MAC) basedon the random key k the nonce Na received from Alice andanother nonce Nb locally generated Next in Step (3) Bobreplies to Alice exchanging his long-term public-key Pkb hisown nonce Nb and the computed MAC so that in Step (4)Alice can perform equivalent steps at her side and verify thereceived MAC and that Bob computed the same HIMMO keykHIMMOba and therefore verify Bobrsquos public-key Furthermore

Bob also sends the session key k to Alice encrypted usingher public-key

After decrypting and recovering the random key k Al-

ice independently regenerates kHIMMOba by using non-secret

HIMMO helper data sent to her by Bob to reconcile any smalldifference between her own and Bobrsquos computed HIMMOkeys Following this both Alice and Bob possess the samesymmetric HIMMO key kHIMMO

ba the same random key kand thereby the same session key kba Finally in Step (5)Alice sends her MAC to Bob so that he can verify Alicersquoslong-term public-key and the random key k in Step (6) NextAlice and Bob can proceed to communicate in a secure au-thenticated way in Step (7) using the final key kba createdby combining kHIMMO

ba and k to protect their communicationThe structure of this handshake can further be extended to

support more generic use-cases and advanced security proper-ties such as forward-secrecy via the use of ephemeral publickeys to transport the session key between Alice and BobTo illustrate this Appendix C depicts three embodiments ofthis handshake ndash a generic version with any suitable public-key key-establishment scheme PKE and key pre-distributionscheme KPS a version instantiated with the post-quantumNTRU key-exchange and with HIMMO and finally a finalversion instantiated with the forward-secure classic ECDHkey-agreement and with HIMMO as the KPS scheme

5 PROOF-OF-CONCEPT WITH TLS TLS-HIMMO

As a proof of concept we illustrate the above generic archi-tecture by instantiating it in the context of the TLS protocolWe use HIMMO in our proof of concept since it enablesefficient distribution of pairwise keys implicit verification ofcredentials and supports multiple TTPsroots of trust Wefurther use ECDH and NTRUEncrypt [24] as the pre- andpost-quantum cryptographic primitives for key-establishmentand ECDSA as the pre-quantum cryptographic primitive forauthentication

Client Server

1 ClientHello = Ciphersuitesc + TTPListc1+ 2 ClientHellominusminusminusminusminusminusminusminusminusrarr

3 ServerHello = Ciphersuitess + TTPLists + 4 ServerHellolarrminusminusminusminusminusminusminusminusminusminus

5 kHIMMOcs HelperData = s1c(QshPks) +

s2c(QshPks) +

6 ClientKeyExchange =EClassicPks (ClassicS)|EQshPks

(CliS)

|HelperData27 ClientKeyExchangeminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarr

8 Decrypt ClassicS CliS

9 kHIMMOcs = s1s(QshPkc) + s2s(QshPkc) + +

HelperData

10 PMS3= Classic|CliS|kHIMMOcs 10 PMS = Classic|CliS|kHIMMO

cs 11 MasterSecret = PRF (PMS) 11 MasterSecret = PRF (PMS)

12Finishedaminusminusminusminusminusminusminusminusminusrarr13 Verify Finisheda

14Finishedblarrminusminusminusminusminusminusminusminusminus15 Verify Finishedb

16 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using MasterSecret 16 Application Data

1 List of supported HIMMO TTP IDs as per RFC 6066 [12]2 ClassicS CliS are the classic secret and client QSH (assuming [32]) secret respectively3 Pre-master Secret used to generate the TLS Master Secret by means of the TLS pseudo-random function PRF

Figure 3 TLS Handshake including the design proposed in this paper including negotiation of a common setof trusted TTPs and establishment of a confidential authenticated channel protected by a combination of aclassic secret a quantum-safe secret CliS and a quantum-safe HIMMO key The HIMMO key is created usinga combination of key materials obtained from multiple negotiated TTPs and the peerrsquos long-term public-keyideally quantum-resistant

Figure 3 shows the complete TLS handshake between aclient Client and a server Server extended with our designin Section 4 The required additions to support our exten-sions are not many and the main one refers to the capabilityof agreeing on a common set of roots of trust TTPs andagreeing on this type of their use For this we considerRFC 6066 [12] since it defines extensions to the ClientHelloand ServerHello messages in which supported certificationauthorities are exchanged We reuse this extension for ourpurposes as follows

If a client and server have registered with some HIMMOTTPs and obtained HIMMO key material as described in Sec-tion 4 then they exchange the identities of their supportedTTPs Thus in Step (1) of the handshake Client creates aClientHello message including its supported roots of trustie HIMMO TTPs as described in RFC 6066 [12] that isthen sent to Server in Step (2) In step (3) Server searchesfor a common set of HIMMO TTPs that it then includes inthe ServerHello message and sends back to Client in Step (4)If they agree on the usage of HIMMO TTPs they then ex-change certificates or public keys whose hashes are HIMMOidentifiers for which they already possess HIMMO key mate-rial If only classical ciphersuites are considered then suchcertificates correspond to classical primitives eg ECDSAthat are exchanged normally via the ClientCertificate and

ServerCertificate messages If post-quantum keys are sup-ported then an extension header in the ClientHello messageis used (as specified in the hybrid TLS handshake InternetDraft [32]) to exchange additional post-quantum public keysThe exchanged certificates or public keys and correspondingkey material associated to common TTPs allow Client andServer to independently generate pairwise HIMMO keys inSteps (5) and (9) (one key for each common TTP agreedupon) which they then use to independently derive the finalHIMMO key kHIMMO

cs by means of a pseudo-random functionof all previously generated HIMMO keys In the specificexample we describe in Figure 3 Client and Server use eachotherrsquos quantum-resistant public-key to generate kHIMMO

cs insteps (5) and (9) This offers stronger quantum-securityHowever classic public-keys may also be used for this purposeto ease widespread adoption Note that HIMMO requiresa key reconciliation step in which HelperData is exchangedfrom the client and server that we exchange via the Clien-tKeyExchange This is the only protocol field that wouldrequire standardization

To utilize the combined security of HIMMO the classicandor post-quantum key-establishment schemes the TLSMaster Secret used for protecting the TLS record layer iscomputed from a Pre-master secret PMS that is a combi-nation of the classical key Classic the post-quantum key

CliS and the HIMMO key kHIMMOcs This is similar to [32]

and [16] Since the HIMMO key kHIMMOcs is one of the in-

puts to the Master Secret in Steps (10) and (11) via thePre-master Secret PMS it ensures the confidentiality andauthentication of the messages exchanged in the record layerMost importantly it also implicitly verifies the certificatesand public keys of Client and Server since the Master Secretis used in the computation of a Message Authentication Codein the Finished message that both parties must indepen-dently compute exchange and verify (in steps (13) and (15))This MAC is thus bound to the kHIMMO

cs that both partiesindependently computed using the certificates of the otherparty and their own HIMMO key material and can there-fore be considered equal to the MACba exchanged as anauthentication token during the Secure Operation phase (seeFigure 2) The MACrsquos verification by Server and Client willfail unless they computed the right kHIMMO

cs using an authen-tic certificatepublic-key of the other party and proper keymaterial and its success automatically authenticates bothServer and Client to each other

Finally note that the above authentication using HIMMOcan be done using multiple TTPs while also being capableof forward-secrecy and non-repudiation (through the addedincorporation of standard digital signatures) Lawful in-terception use-cases would require the client and server toexclude the exchange of public keys during operation andthus rely only on HIMMO and multiple TTPs to provide aproper privacy trade-off

6 EVALUATIONIn this section we begin with an analysis of the security

provided by our hybrid architecture in Section 61 followedby a quantitative evaluation of its performance in Section 62Section 63 presents a qualitative discussion of the architec-turersquos contributions and quantitatively compares it with thestate of the art

61 Security AnalysisIn this subsection we look at our hybrid architecture and

analyze its security A core contribution of this architectureis imparting quantum-safe authentication and confidentialityto communication channels in a scalable and efficient man-ner The private information possessed by a party ie thesecret HIMMO key material plays a key part in this andmust therefore be securely allocated to the party beforehandSuch confidential distribution of HIMMO key material isachieved by the Enrollment phase as it allows parties toget their public keys certified by (multiple) root(s) of trustand securely receive key materials from them in a manneranalogous to traditional Public-Key Infrastructure Whileallocating a HIMMO key material to an enrolling party aroot of trust encrypts it using the recipient partyrsquos public-keybefore transmitting the key material to it thereby ensuringconfidentiality of the private key material Furthermore thetransmission of a cryptographically-secure hash of the keymaterial along with the actual key material itself allows itsintegrity to be checked by the recipient party Freshnessof the key material received by a party is also ensured andmessage-replay attacks are prevented by the transmission(and verification) of freshly-generated nonces A preventivemeasure against impersonators trying to enroll with the rootof trust is achieved by the use of encrypted nonces at thestart of Enrollment Finally we emphasize once again that

quantum-safe asymmetric cryptography should ideally beused during Enrollment to make sure that the key materialof enrolled parties remains confidential and to prevent re-covery of an enrolling partyrsquos secret HIMMO key materialby a quantum-capable attacker (leading to identity imper-sonation [1]) Using classic public-key cryptography sufficesonly for the short-term to ease widespread adoption

Next we discuss the security of the Secure Operation hand-shake between two parties Authentication of the two partiesrsquolong-term public keys is implicitly and mutually achievedby a successful agreement of the HIMMO key between theparties since it is derived from both the public keys of thecommunicating parties and their private HIMMO keying ma-terials Therefore a successful key agreement automaticallyverifies both partiesrsquo public keys to each other since thisagreement never works unless both parties perform this stepusing authentic certified public keys and proper HIMMOkey materials that have been cryptographically bound totheir certified public keys The same idea also preventsconventional attacks such as a Man-in-the-Middle (MITM)attack on the handshake between Alice and Bob since theauthentication involves both of their private key materialsand certified public keys (exchanged via verifiable certifi-cates) thus making it impossible for the attacker to eitherimpersonate Alice or Bob to the other party

The final key and therefore the actual communication be-tween the parties receives combined protection from bothHIMMO and public-key cryptography In [32] it is argued us-ing the Leftover Hash Lemma [26] that if a secret is composedof two other independent secrets an attacker cannot recoverthe combined secret as long as one of the constituent secretsis unknown to him As a result even if the attacker possessesquantum computing capabilities and is able to recover khe fails to learn the key kHIMMO

ba thus preventing him fromlearning the session key kba In [21] it has been shownthat all attacks on HIMMO found so far lead to lattice-basedcryptanalysis thereby HIMMO provides quantum-security toany scheme that uses keys derived using it Furthermore [20]explicitly contains an analysis of quantum-capable attacks onthe HIMMO scheme Thus the overall communication ben-efits from both classic- and quantum-secure confidentialityand authentication

The architecture is also flexible enough to incorporate addi-tional strong security properties such as forward-secrecy withminimal changes ndash such as using an ephemeral publicprivatekey-pair to transport the random key k between the com-municating parties during the Secure Operation phase (seeFigure 7 in Appendix C for an instantiation)

Finally we note that due to HIMMOrsquos use of multipleTTPs and consequently our architecturersquos use of multipleroots of trust the level of security can be increased n-fold(when using HIMMO key material obtained from n roots oftrust during the Enrollment phase) with almost no corre-sponding increase in computation or communication cost dueto the nature of HIMMOrsquos operation when using multipleTTPs Anything short of a total compromise of all roots oftrust would affect neither confidentiality nor authenticationas the final private HIMMO key material of the enrolledparties and therefore HIMMO symmetric keys generated bythem remain secret in turn ensuring that the final session orMaster secret and therefore the final communication channelalso remains secure

CiphersuiteHandshake time

(ms)Handshake size

(Bytes)

ECDHE ECDSA WITH AES 256 CBC SHA (nistp256) 491 3277

NTRU RSA WITH AES 256 CBC SHA (EES439EP1) 293 5381

ECDHE ECDSA WITH AES 256 CBC SHA HIMMO256 505 3330

NTRU RSA WITH AES 256 CBC SHA HIMMO256 316 5448

NTRU RSA WITH AES 256 CBC SHA HIMMO256 3 TTP 349 5640

Table 1 TLS performance for different ciphersuites including existing classical and hybrid post-quantumciphersuites extended with HIMMO key generation using key material bound with certified public keys asper our design (256-bit HIMMO key with a large security parameter t = 4000) Extensions using both single-TTP and multi-TTP HIMMO implementations are shown The Elliptic Curve key-exchange and signatureimplementations use the NIST P-256 curve providing 128-bits of security NTRUEncrypt key-exchange usethe NTRU parameter set EES439EP1 with a 608 byte public key at 128-bit security

62 Performance Evaluation amp BenchmarksTo validate our research we implement the protocol de-

scribed in Section 5 by extending the CyaSSL library andusing TLSv2 The TLS protocol is executed between twomachines within the same Local Area Network Each ma-chinePC uses Windows 7 Enterprise (64 bit) with an IntelCore i5-5300U 230 GHz Software was compiled for thex86_64 architecture with full optimization (Ox) using theMicrosoft Visual C compiler

Table 1 compares the performance of different TLS hand-shakes using pre- and post-quantum ciphersuites Pre-quantum ciphersuites use ECDHE ECDSA while post-quantumciphersuites rely on NTRU RSA (NTRU is used to encrypta secret that is exchanged the NTRU public-key is signedwith RSA) We compare them after adding HIMMO nextto them using a single TTP The HIMMO parameter b ischosen to be 32 Several HIMMO systems are used in parallelto obtain a 256 bit key The additional time or bandwidthconsumption is minimal while enabling the verification ofpublic keys and generation of a symmetric-secret Further-more the increase in running times of the TLS handshakefor the classic ECDHE ECDSA and the post-quantum ci-phersuite NTRU RSA when extended with HIMMO wherethe HIMMO key is computed from key material assigned bythree TTPs (as per the protocol in Section 5) is minimalEach TTP is managed by a different organization or has in-dependent locations thus preventing a single point of failureExtending the classical ECDHE ECDSA with a single-TTPHIMMO implementation results in a TLS handshake thatis slower by only 28 for the HIMMO security parametert = 4000 (505 ms for the extended ciphersuite as comparedto 491 ms for classic ECDHE+ECDSA) Note that this valueof t is quite conservative [21] the drop in speed of the TLShandshake is minimal by comparison For the post-quantumciphersuite NTRU RSA the increase in computation over-head is 78 for a single-TTP implementation (316 ms forthe single-TTP extended ciphersuite as compared to 293 msfor the original NTRU+RSA one) and 191 for a three-TTPimplementation (349 ms) both cases for t = 4000 A furtheroptimization is possible for the multiple-TTP implementa-tion instead of sequentially creating and combining threeHIMMO sub-keys it is possible to generate a single HIMMOkey after adding the coefficientscomponents of the key ma-terials obtained from different TTPs Once this optimizationis done we expect a timing similar to the usage of a single

of TTP irrespective of the number of TTPs used[21 17] present insights into the efficient lightweight per-

formance of HIMMO It is demonstrated that an increaseof the HIMMO security parameter t to a very high valuethat directly determines the dimension of the lattice thatneeds to be reduced in order to find a closeshort vector [21]still does not have a huge impact in the CPU needs whilebandwidth consumption remains practically constant andequal to a few bytes Memory increases but for applicationareas such as the Internet a storage requirement of a coupleof megabytes is affordable IoT applications have differentperformance criteria communication bandwidth energy con-sumption timing and memory For all of these HIMMO isoptimal By construction HIMMO has low communicationand energy needs since it is identity-based and since wirelesscommunication consumes most of the energy budget Timingis also optimal although key material size is on the high sideEven without optimizations memory is the least relevantcriteria IoT devices are getting bigger memories computersand phones have sufficient memory capabilities

63 Discussion amp ComparisonThe solution proposed in this paper exhibits advantageous

properties compared with other architectures as shown inTable 2 Firstly the usage of HIMMO to create the finalsession key that protects a secure channel between any pair ofdevices makes the operational communication link betweenthem quantum-resistant Secondly the use of an indepen-dent public-key cryptosystem ensures secure distributionof key material during the initial enrollment and preventseavesdropping by rogue TTPs during Secure Operation Thearchitecture supports multiple roots of trust (based onHIMMO TTPs) with low overhead ensuring that the systemremains secure even if individual roots of trust are compro-mised Operationally if a secure channel between partiesis established based on HIMMO only this results in a non-interactive method for key agreement and authenticationideal for IoT scenarios Together with the incorporationof multiple TTPs this configuration of our architecture (iebased on only HIMMO) provides a solid solution for use casesin which lawful interception of communication is requiredAt the same time this does not infringe upon the right toprivacy of legitimate communications since it would requirea unanimous cooperation among all TTPs involved in thecommunication preventing possible abuses of power

Supported Features Traditional PKI Kerberos KPS QSH-TLS [32] DTLS-HIMMO [19] This paper

Quantum-safe confidentiality Depends on PK Yes Yes Yes Yes Yes

Quantum-safe authentication Depends on PK Yes Yes No Yes Yes

Enrollment Secure in-band Out-of-band Out-of-band Secure in-band Out-of-band Secure in-band

Multiple roots of trust Yes (high overhead) No Yes Yes (high overhead) Yes Yes (low overhead)

Non-interactive operation No No Yes No Yes Yes

Forward-secrecy Yes No No Yes No Yes

Authentication overhead High (explicit High (online Low High (explicit Low Low

signature) interaction) (symmetric) signature) (symmetric) (symmetric)

Scalability High Medium Medium Medium High Higher

Table 2 Comparison of the hybrid infrastructure presented in this paper with existing security architecturesfor a number of security and operational features

Figure 4 Comparison of communication overhead in TLS authentication phase when using (a) HIMMO keygeneration-based authentication with one TTP (b) with two TTPs (c) with three TTPs (all using 256-bitHIMMO key with a large security parameter t = 4000) (d) XMSS with 82 bit security (e) NTRUMLS withparameter set 401 [23] and 112 bit security (f) classic ECDSA with the curve nistp256 Data exchanged forauthentication purposes when using our HIMMO-based solution amounts to only HIMMO helper data forkey reconciliation

Considering authentication a HIMMO key material as-signed to a node is bound to its public-key so that theHIMMO key material acts as the nodersquos implicit digital cer-tificate allowing a node to verify public parameters of otherdevices with very low overhead while supporting multipleroots of trust Upgrading to any public-key cryptosystem issimple through the use of the corresponding digital certifi-cate or public-key as the HIMMO identity

Thus the proposed architecture is highly scalable evenif an out-of-band channel is not available as is the case in theInternet and is applicable to a wide range of use cases In con-trast the hybrid TLS handshake in [32] focuses on traditionalInternet applications only and does not support authentica-tion by multiple roots of trust The DTLS-HIMMO work [19]addresses IoT use cases but lacks a solution for in-band en-rollment or the capability of providing forward-secrecy

Considering post-quantum authentication we quantify thegains of our solution by comparing it with two signature

schemes considered quantum-resistant namely XMSS [6]and NTRUMLS [23] XMSS with an h value equal to 8 (iethe height of the XMSS hash tree) allows creating at most 256signatures each approximately 2436 Bytes long and havinga signature verification time of 195 ms [15] NTRUMLSfor parameters 401 and 743 involve signatures of around853 and 1765 Bytes with verification times of 033 and 079ms respectively [15] We note that computationally theactual post-quantum authentication step in our solution iethe generation of the HIMMO symmetric key is 65 fasterthan that of XMSS (067 ms compared to XMSSrsquos 195 ms)and 15 faster than that of NTRUMLS (067 ms comparedto NTRUMLSrsquos 079 ms) considering the relatively secureNTRUMLS parameter set 743 and a high HIMMO securityparameter value of t = 4000

Furthermore Figure 4 compares the communication over-head during TLS authentication comparing the amount ofbytes exchanged by classic and existing post-quantum sig-

natures with that exchanged by the authentication in ourHIMMO-based solution Since this consists of only HIMMOhelper data as compared to full-fledged digital signatures inthe former case our solution has a strong advantage regard-ing communication overhead or signature sizes

Figure 4 also shows that even achieving higher securitythrough the use of multiple roots of trust (ie TTPs) comesat virtually no added cost since the size of the HIMMOhelper data exchanged between parties for key reconcilia-tion only grows logarithmically with the increase in numberof TTPs (ie roots of trust) and not linearly When a n-TTP implementation is used the final key is derived as acombination of n intermediate HIMMO keys each derivedfrom one key material instance (obtained from one root oftrust) with HIMMO parameters t and m However if theHIMMO parameter t is same for all intermediate key mate-rials then the final HIMMO key corresponds to a symbolicHIMMO key material with parameters t and nm The sizeu of the helper data for this HIMMO key would then beu = dlog2(4nmt + 1)e (see Appendix B) which essentiallygrows logarithmically with n For more details about the ex-act nature of HIMMO helper data that leads to this desirablebehavior see Appendix B

In comparison for traditional digital signatures such asXMSS and NTRUMLS (albeit quantum-resistant) to achievethe same increase in security usage of certifications frommultiple CAs is necessary This involves a linear growth ofcomputation overhead (key-pair generation signature gen-eration signature verification) as well as communicationoverhead (exchange of multiple signatures) with the numberof CAs involved Thus the main advantage of our approachrelates to the implicit verification of public keys thatinvolves minimal overhead even with stronger security con-ditions such as multiple roots of trust (see Section 62)

7 CONCLUSIONSWe presented a hybrid security architecture combining

public-key cryptography and key pre-distribution schemesWe chose HIMMO as the KPS instantiation since it is theonly known scheme that is both efficient and collusion- andquantum-resistant The hybrid architecture combines desir-able features of both worlds it is scalable supports secureenrollment and efficient support for multiple roots of trustDue to its non-interactive key agreement the scheme is idealfor use cases with strict timing constraints limited band-width or a tight energy budget as often encountered in theIoT The hybrid scheme also finds a broader application inthe Internet since it allows for efficient verification of pub-lic keys with minimal overhead while providing advancedfeatures such as forward-secrecy

The architecture can already be deployed to improve per-formance of Internet communications in todayrsquos pre-quantumworld while providing a path towards a quantum-resistantyet highly efficient Internet Our TLS proof-of-concept imple-mentation proves this by showing how existing non-quantumresistant communications based on ECC or quantum-safepublic keys such as NTRU public keys can be verified withan increased communication overhead of less than 1 andvery low computational overhead Due to the identity-basednature of the HIMMO scheme the exchanged amount ofdata and time required for key generation remain practicallyconstant even if the HIMMO security parameters are madeextremely large

8 REFERENCES[1] C Adams Impersonation Attack pages 596ndash596

Springer US Boston MA 2011

[2] E Alkim L Ducas T Poeppelmann and P SchwabePost-Quantum Key Exchange ndash A New Hope 2015Cryptology ePrint Archive Report 2015-1092

[3] M Bellare and P Rogaway Entity Authentication andKey Distribution pages 232ndash249 Springer BerlinHeidelberg Berlin Heidelberg 1994

[4] J Bos C Costello L Ducas I Mironov M NaehrigV Nikolaenko A Raghunathan and D Stebila FrodoTake off the ring practical quantum-secure keyexchange from lwe Cryptology ePrint Archive Report2016659 2016 httpeprintiacrorg2016659

[5] J Bos C Costello M Naehrig and D StebilaPost-quantum key exchange for the TLS protocol fromthe ring learning with errors problem 2014httpeprintiacrorg2014599

[6] J Buchmann E Dahmen and A Hulsing XMSS APractical Forward Secure Signature Scheme based onMinimal Security Assumptions 2011httpeprintiacrorg20151003

[7] D Butin S-L Gazdag and J Buchmann Real-worldpost-quantum digital signatures In Cyber Security andPrivacy pages 41ndash52 Springer 2015

[8] S Checkoway R Niederhagen A EverspaughM Green T Lange T Ristenpart D J BernsteinJ Maskiewicz H Shacham and M Fredrikson On thePractical Exploitability of Dual EC in TLSImplementations In 23rd USENIX Security Symposium(USENIX Security 14) pages 319ndash335 San Diego CAAug 2014 USENIX Association

[9] L Chen S Jordan Y-K Liu D Moody R PeraltaR Perlner and D Smith-Tone Report onPost-Quantum Cryptography NISTIR8105 2016httpcsrcnistgovpublicationsdraftsnistir-8105nistir 8105 draftpdf

[10] Y Chen Q Huang and Z ZhangSakai-ohgishi-kasahara identity-based non-interactivekey exchange revisited and more Cryptology ePrintArchive Report 2014310 2014httpeprintiacrorg2014310

[11] J Ding and D Schmidt Rainbow a new multivariablepolynomial signature scheme In Applied Cryptographyand Network Security pages 164ndash175 Springer 2005

[12] D Eastlake Transport Layer Security (TLS)Extensions Extension Definitions 2011 RFC6066

[13] P Eronen and H Tschofenig Pre-Shared KeyCiphersuites for Transport Layer Security (TLS) RFC4279 (Proposed Standard) Dec 2005

[14] ETSI TS 101 331 - V131 - Lawful Interception (LI)Requirements of Law Enforcement Agencies October2009httpsarchiveorgdetailsetsi ts 101 331 v010301

[15] ETSI GRQSC-001 - V111 - Quantum-SafeCryptography (QSC) Quantum-safe algorithmicframework July 2016httpwwwetsiorgdeliveretsi grQSC001 099001010101 60gr QSC001v010101ppdf

[16] S Fluhrer D McGrew and P Kampanakis AnExtension for Postquantum Security using PresharedKeys for IKEv2 2015

bull The architecture should facilitate a smooth transi-tion towards quantum resistant solutions with minimalchanges and overhead

bull The architecture should be applicable to as many usecases and applications as possible eg be applicablenot only to secure networks and traditional Internetapplications but also to new ones eg Internet ofThings

bull Apart from security goals performance should be asoptimal as possible in terms of bandwidth computationcost energy and memory

bull The design of constituent protocols in the architectureshould be modular in order to easily add multipleciphersuites also quantum-resistant ones for both keyexchange and digital signatures

33 Problem StatementWhen we consider the above design goals in Section 32

the attack model and the current state-of-the-art reviewedin Section 2 the problem statement of this paper is fourfold

Firstly despite there being many potential quantum-resistantcandidates for key-exchange and authentication none ofthem are a drop-in replacement of existing primitives creat-ing an urgent requirement for practical secure and quickly-deployable quantum-resistant primitives Current quantum-resistant signatures are especially bulky or operationallycumbersome to use For instance hash-based signaturesinvolve an overhead of tens of KBs and in some settingsrequire keeping some state [7] making private keys a criticalresource and key management extremely risky

Secondly the security of communication links in authen-ticated Internet protocols usually fully depends on a singleroot of trust eg a certification authority that is a singlepoint of complete failure This trust responsibility must bedistributed among multiple roots of trust without affectingperformance resulting in resilience to the compromise ofindividual roots of trust

Thirdly the right to privacy and the lawful interception ofcommunication are contradictory goals However both goalsneed to be accommodated in a common architecture so thatusers have the confidence that their data is not monitoredor manipulated but if required and agreed upon in specialcircumstances access by law enforcement to such data canbe enabled

Finally existing protocols and cryptographic primitivesare already considered to be too heavy for the Internet ofThings in particular concerning bandwidth consumptionenergy requirements and strict timing needs Therefore itis a challenge to find an overall solution that fulfills securityrequirements and also exhibits good performance

4 DESIGNThis section describes our hybrid trust infrastructure and

the rationale behind its design The basic design concept istwofold

Firstly use multiple HIMMO TTPs as roots of trust toenable efficient certification and verification of the public keysand other credentials of devices in one-to-one communicationscenarios while preventing single points of failure and thusadding robustness

Secondly use public-key cryptography (ideally quantum-resistant) to enable the secure distribution of HIMMO keymaterial to devices and to enable further advanced securityfeatures like forward-secrecy

The architecture can work with any type of public keysand any KPS We use HIMMO as the KPS since it is (tothe best of our knowledge) the only KPS that enables bothquantum resistant and collusion-resistant key agreement inan efficient way The only other schemes known to resemblea fully collusion-resistant KPS are [31 33 10] however theyare not quantum-resistant

This design approach combines desirable security featuresof both Public-Key Infrastructure and Key Pre-distributionsuch as efficiency offline operation secure initialization lowoverhead forward-secrecy and support for multiple roots oftrust In the following subsections we discuss three aspects(i) roots of trust (ii) the enrollment and certification pro-cedure for a party or device and (iii) operation of a securehandshake between two parties

41 Roots of Trust in a PQ WorldA fully general secure authenticated architecture can con-

sider roots of trust supporting (i) traditional public-key in-frastructure such as the ability to sign digital certificatescontaining public keys and (ii) TTP solutions either requir-ing an online interaction to enable a pair of parties to securelycommunicate with each other (similar to Kerberos) or withonly a TTP involved during the registration of a party (suchas with HIMMO)

In this paper our architecture relies on roots of trustbased on HIMMO TTPs since they are not involved duringoperation ie during actual communication of devicesnodesSecond multiple roots of trust can also be supported in anefficient way to prevent TTPs from becoming single pointsof failure Third the operational features of HIMMO fitin many IoT use cases low bandwidth consumption fastoperation low RAM needs Finally there is a lack of efficientquantum-safe public-key authentication schemes

Therefore our trust infrastructure relies on multiple HIMMOTTPs that maintain secret root key material for some givensecurity parameters These TTPs are managed by multipleindependently located and affiliated organizations so that asecurity breach in one of them does not affect the rest but ifrequired for lawful interception of communications only acoalition of all TTPs could monitor communications TTPsare in charge of certifying parameters of entities that wishto enroll and of distributing key material to them

42 Enrollment amp CertificationThe first phase of our architecturersquos operation is an enroll-

ment and certification phase during which a party can talkto any number of HIMMO roots of trust expose its identifi-cation information and public-key get them certified andsecurely receive HIMMO key material This is similar to thecertification of public keys in todayrsquos PKI or the distributionof key material in existing KPS

It is imperative that the HIMMO key material for a partyremains secret While for IoT scenarios an out-of-band chan-nel for distributing key material is a good option [18] this isnot the case for the Internet The challenge is therefore tosecurely distribute such key material over an open networkWe propose to solve this using the following general enroll-ment approach When an entity Alice wants to get enrolled

Alice TTP (Root of Trust)

Possesses asymmetric key-pair Pka Ska Possesses secret root key material R1 Pka Naminusminusminusminusminusminusminusminusrarr2 EPkaNtlarrminusminusminusminusminusminusminusminusminus

3 Decrypt Nt4 Ntminusminusminusminusrarr

5 Verify Nt

sa(x) = R(hash(Pka) x)6 EPkasa(x)|hash(sa(x)|Na)larrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminus

7 Decrypt key material sa(x)

Verify integrity and Na

Figure 1 Enrollment and Certification of a communicating entity Alice with a root of trust ie a HIMMOTTP resulting in Alice getting her long-term public-key Pka certified and securely receiving private HIMMOkey material sPka(x) that is bound to Pka This key material is created by the HIMMO TTP using itssecret root key material R Na and Nt are random ephemeral nonces that prevent replay attacks and enableverification of the enrolleersquos identity respectively

in the system she generates a publicprivate key-pair (ideallyquantum-resistant) and combines the public-key with anyother identification information Alice then enrolls with oneor several HIMMO TTPs To this end she must send toeach TTP this set of identification information that mustcontain at least her public-key Pka This is demonstrated inStep (1) of Figure 1 that depicts Alicersquos enrollment with asingle TTP

When the TTP receives Alicersquos information it can furtherverify it for consistency and optionally add additional param-eters eg an expiration date creating a certificate of Alicersquosidentity Before this the TTP ascertains Alicersquos identity(to thwart would-be impersonators) by using the public-keyreceived to encrypt and send a random fresh nonce Nt toAlice (Figure 1 Step (2)) that she must then decrypt andsend back to the TTP (Steps (34)) Next given Alicersquoscertificate the TTP computes a HIMMO identity for Aliceby hashing the certificate (containing at least her public-keyPka) and uses this to extract the corresponding HIMMO keymaterial sa(x) for her in Step (5) Therefore through Alicersquosidentity and in turn through the certificate containing Pka(or through Pka directly as in Figure 1) sa(x) generatedfor Alice is now cryptographically bound to Pka In Step(6) the TTP can use Alicersquos public-key Pka to encrypt andsend the computed HIMMO key material sa(x) to her sothat only the owner of Pka can decrypt sa(x) The TTPincludes a hash of the key material in the encrypted messagealong with a nonce Na originating from Alice that acts as anauthentication token This is decrypted and verified by Alicein Step (7) following which she can use her new HIMMOkey material

We note that the final HIMMO key material associatedto Alice can include the HIMMO key material received frommultiple TTPs This information can be stored either with-out being combined or combined into one single instance ofHIMMO key material by adding the componentscoefficientsof multiple HIMMO key materials received from differentTTPs one by one In case of multiple TTPs some commu-nication between them may be required to ensure that theyall generate the same HIMMO identity for Alice

43 Secure Operation

Following the successful enrollment of two entities Aliceand Bob with one or multiple roots of trust they should beable to establish a secure communication session in the abovesetting ie each of them has public keys Pka and Pkb boundto private HIMMO key materials sa(x) and sb(x) In case ofmultiple TTPs these are combinations of the individual keymaterials generated by the TTPs involved We believe thatmany security protocols can be designed in general (a fewexamples of which can be found in Appendix C) throughthe following steps

bull Alice exposes her supported TTPs to Bob

bull Bob decides whether Alice supports at least a minimumnumber of TTPs that he also trusts If not Bob abortsOtherwise Bob exchanges these TTPsrsquo identifiers withAlice so that she can also verify whether that set ofTTPs provides her with enough trust

bull Alice and Bob engage in a handshake for key exchangeand mutual authentication that relies on public-keycryptography (ideally quantum-resistant) to achievestrong properties such as forward-secrecy and on HIMMOto verify the identities of the communicating partiesand thus to ensure an authenticated channel

bull Upon the establishment of a secure channel Alice andBob exchange data in a secure way

The handshake between Alice and Bob resulting in a con-fidential authenticated channel is an adapted form of theBellare-Rogaway AKEP1 [3] with the final session key thatprotects both confidentiality and authentication of the com-munication between Alice and Bob being derived from anadditional random key established using asymmetric cryptog-raphy apart from the HIMMO key (and thus independentfrom HIMMO and its TTPs)

Authentication of public keys happens without traditionaldigital signatures but HIMMO The HIMMO key materialsa(x) of a party A is cryptographically bound to its identity

1authenticated key-exchange protocol

Alice Bob

Possesses asymmetric key-pair Pka Ska and secretHIMMO key material sa(x)

Possesses asymmetric key-pair Pkb Skb and secretHIMMO key material sb(x)

1 Pka Naminusminusminusminusminusminusminusminusrarr2 kHIMMO

ba HelperData = sb(Pka)

Create key k randomly

kba = KDF (kHIMMOba k)

MACba = MACkba (k|Nb|Na)3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusEPka (k) HelperData

4 Decrypt k

kHIMMOba = sa(Pkb) + HelperData

kba = KDF (kHIMMOba k)

Verify MACba using kba

MACab = MACkba (k|Na|Nb)5 MACabminusminusminusminusminusminusminusminusrarr

6 Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 2 Secure Operation for establishing a confidential authenticated channel between two parties Aliceand Bob Authentication is achieved using HIMMO key material bound to long-term certified public keysConfidentiality is achieved using a combination of HIMMO and a shared session key transported usingasymmetric cryptography ideally quantum-resistant Na and Nb are random ephemeral nonces used toprevent replay attacks

which in turn is bound to the partyrsquos public-key Pka Suc-cessful agreement of a HIMMO key between two parties usingauthentic key materials and authentic public-keys results ina successful mutual authentication

Prevention of single points of failure (as in traditional PKI)is accomplished by performing this authentication with keymaterial generated by multiple TTPs preventing imperson-ation of public keys even if some TTPs are compromisedFurthermore this does not affect performance due to the na-ture of HIMMOrsquos operation while using multiple TTPs Theuse of asymmetric-cryptography for key exchange ensuresthat TTPs cannot access the communication and enablesforward-secrecy for advanced use cases eg communicationover the Internet

The above general operational protocol is exemplified ina very specific operational handshake for key exchange andmutual authentication depicted in Figure 2 In this examplea single TTP is commonly supported by the communicatingentities Alice and Bob In Step (1) Alice sends her public-key Pka to Bob along with a fresh nonce Na In Step (2)Bob computes the HIMMO key kHIMMO

ba using HIMMO andadditionally generates a secret random key k Bob thensecurely combines both keys into a session key kba using itto compute a Message Authentication Code (MAC) basedon the random key k the nonce Na received from Alice andanother nonce Nb locally generated Next in Step (3) Bobreplies to Alice exchanging his long-term public-key Pkb hisown nonce Nb and the computed MAC so that in Step (4)Alice can perform equivalent steps at her side and verify thereceived MAC and that Bob computed the same HIMMO keykHIMMOba and therefore verify Bobrsquos public-key Furthermore

Bob also sends the session key k to Alice encrypted usingher public-key

After decrypting and recovering the random key k Al-

ice independently regenerates kHIMMOba by using non-secret

HIMMO helper data sent to her by Bob to reconcile any smalldifference between her own and Bobrsquos computed HIMMOkeys Following this both Alice and Bob possess the samesymmetric HIMMO key kHIMMO

ba the same random key kand thereby the same session key kba Finally in Step (5)Alice sends her MAC to Bob so that he can verify Alicersquoslong-term public-key and the random key k in Step (6) NextAlice and Bob can proceed to communicate in a secure au-thenticated way in Step (7) using the final key kba createdby combining kHIMMO

ba and k to protect their communicationThe structure of this handshake can further be extended to

support more generic use-cases and advanced security proper-ties such as forward-secrecy via the use of ephemeral publickeys to transport the session key between Alice and BobTo illustrate this Appendix C depicts three embodiments ofthis handshake ndash a generic version with any suitable public-key key-establishment scheme PKE and key pre-distributionscheme KPS a version instantiated with the post-quantumNTRU key-exchange and with HIMMO and finally a finalversion instantiated with the forward-secure classic ECDHkey-agreement and with HIMMO as the KPS scheme

5 PROOF-OF-CONCEPT WITH TLS TLS-HIMMO

As a proof of concept we illustrate the above generic archi-tecture by instantiating it in the context of the TLS protocolWe use HIMMO in our proof of concept since it enablesefficient distribution of pairwise keys implicit verification ofcredentials and supports multiple TTPsroots of trust Wefurther use ECDH and NTRUEncrypt [24] as the pre- andpost-quantum cryptographic primitives for key-establishmentand ECDSA as the pre-quantum cryptographic primitive forauthentication

Client Server

1 ClientHello = Ciphersuitesc + TTPListc1+ 2 ClientHellominusminusminusminusminusminusminusminusminusrarr

3 ServerHello = Ciphersuitess + TTPLists + 4 ServerHellolarrminusminusminusminusminusminusminusminusminusminus

5 kHIMMOcs HelperData = s1c(QshPks) +

s2c(QshPks) +

6 ClientKeyExchange =EClassicPks (ClassicS)|EQshPks

(CliS)

|HelperData27 ClientKeyExchangeminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarr

8 Decrypt ClassicS CliS

9 kHIMMOcs = s1s(QshPkc) + s2s(QshPkc) + +

HelperData

10 PMS3= Classic|CliS|kHIMMOcs 10 PMS = Classic|CliS|kHIMMO

cs 11 MasterSecret = PRF (PMS) 11 MasterSecret = PRF (PMS)

12Finishedaminusminusminusminusminusminusminusminusminusrarr13 Verify Finisheda

14Finishedblarrminusminusminusminusminusminusminusminusminus15 Verify Finishedb

16 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using MasterSecret 16 Application Data

1 List of supported HIMMO TTP IDs as per RFC 6066 [12]2 ClassicS CliS are the classic secret and client QSH (assuming [32]) secret respectively3 Pre-master Secret used to generate the TLS Master Secret by means of the TLS pseudo-random function PRF

Figure 3 TLS Handshake including the design proposed in this paper including negotiation of a common setof trusted TTPs and establishment of a confidential authenticated channel protected by a combination of aclassic secret a quantum-safe secret CliS and a quantum-safe HIMMO key The HIMMO key is created usinga combination of key materials obtained from multiple negotiated TTPs and the peerrsquos long-term public-keyideally quantum-resistant

Figure 3 shows the complete TLS handshake between aclient Client and a server Server extended with our designin Section 4 The required additions to support our exten-sions are not many and the main one refers to the capabilityof agreeing on a common set of roots of trust TTPs andagreeing on this type of their use For this we considerRFC 6066 [12] since it defines extensions to the ClientHelloand ServerHello messages in which supported certificationauthorities are exchanged We reuse this extension for ourpurposes as follows

If a client and server have registered with some HIMMOTTPs and obtained HIMMO key material as described in Sec-tion 4 then they exchange the identities of their supportedTTPs Thus in Step (1) of the handshake Client creates aClientHello message including its supported roots of trustie HIMMO TTPs as described in RFC 6066 [12] that isthen sent to Server in Step (2) In step (3) Server searchesfor a common set of HIMMO TTPs that it then includes inthe ServerHello message and sends back to Client in Step (4)If they agree on the usage of HIMMO TTPs they then ex-change certificates or public keys whose hashes are HIMMOidentifiers for which they already possess HIMMO key mate-rial If only classical ciphersuites are considered then suchcertificates correspond to classical primitives eg ECDSAthat are exchanged normally via the ClientCertificate and

ServerCertificate messages If post-quantum keys are sup-ported then an extension header in the ClientHello messageis used (as specified in the hybrid TLS handshake InternetDraft [32]) to exchange additional post-quantum public keysThe exchanged certificates or public keys and correspondingkey material associated to common TTPs allow Client andServer to independently generate pairwise HIMMO keys inSteps (5) and (9) (one key for each common TTP agreedupon) which they then use to independently derive the finalHIMMO key kHIMMO

cs by means of a pseudo-random functionof all previously generated HIMMO keys In the specificexample we describe in Figure 3 Client and Server use eachotherrsquos quantum-resistant public-key to generate kHIMMO

cs insteps (5) and (9) This offers stronger quantum-securityHowever classic public-keys may also be used for this purposeto ease widespread adoption Note that HIMMO requiresa key reconciliation step in which HelperData is exchangedfrom the client and server that we exchange via the Clien-tKeyExchange This is the only protocol field that wouldrequire standardization

To utilize the combined security of HIMMO the classicandor post-quantum key-establishment schemes the TLSMaster Secret used for protecting the TLS record layer iscomputed from a Pre-master secret PMS that is a combi-nation of the classical key Classic the post-quantum key

CliS and the HIMMO key kHIMMOcs This is similar to [32]

and [16] Since the HIMMO key kHIMMOcs is one of the in-

puts to the Master Secret in Steps (10) and (11) via thePre-master Secret PMS it ensures the confidentiality andauthentication of the messages exchanged in the record layerMost importantly it also implicitly verifies the certificatesand public keys of Client and Server since the Master Secretis used in the computation of a Message Authentication Codein the Finished message that both parties must indepen-dently compute exchange and verify (in steps (13) and (15))This MAC is thus bound to the kHIMMO

cs that both partiesindependently computed using the certificates of the otherparty and their own HIMMO key material and can there-fore be considered equal to the MACba exchanged as anauthentication token during the Secure Operation phase (seeFigure 2) The MACrsquos verification by Server and Client willfail unless they computed the right kHIMMO

cs using an authen-tic certificatepublic-key of the other party and proper keymaterial and its success automatically authenticates bothServer and Client to each other

Finally note that the above authentication using HIMMOcan be done using multiple TTPs while also being capableof forward-secrecy and non-repudiation (through the addedincorporation of standard digital signatures) Lawful in-terception use-cases would require the client and server toexclude the exchange of public keys during operation andthus rely only on HIMMO and multiple TTPs to provide aproper privacy trade-off

6 EVALUATIONIn this section we begin with an analysis of the security

provided by our hybrid architecture in Section 61 followedby a quantitative evaluation of its performance in Section 62Section 63 presents a qualitative discussion of the architec-turersquos contributions and quantitatively compares it with thestate of the art

61 Security AnalysisIn this subsection we look at our hybrid architecture and

analyze its security A core contribution of this architectureis imparting quantum-safe authentication and confidentialityto communication channels in a scalable and efficient man-ner The private information possessed by a party ie thesecret HIMMO key material plays a key part in this andmust therefore be securely allocated to the party beforehandSuch confidential distribution of HIMMO key material isachieved by the Enrollment phase as it allows parties toget their public keys certified by (multiple) root(s) of trustand securely receive key materials from them in a manneranalogous to traditional Public-Key Infrastructure Whileallocating a HIMMO key material to an enrolling party aroot of trust encrypts it using the recipient partyrsquos public-keybefore transmitting the key material to it thereby ensuringconfidentiality of the private key material Furthermore thetransmission of a cryptographically-secure hash of the keymaterial along with the actual key material itself allows itsintegrity to be checked by the recipient party Freshnessof the key material received by a party is also ensured andmessage-replay attacks are prevented by the transmission(and verification) of freshly-generated nonces A preventivemeasure against impersonators trying to enroll with the rootof trust is achieved by the use of encrypted nonces at thestart of Enrollment Finally we emphasize once again that

quantum-safe asymmetric cryptography should ideally beused during Enrollment to make sure that the key materialof enrolled parties remains confidential and to prevent re-covery of an enrolling partyrsquos secret HIMMO key materialby a quantum-capable attacker (leading to identity imper-sonation [1]) Using classic public-key cryptography sufficesonly for the short-term to ease widespread adoption

Next we discuss the security of the Secure Operation hand-shake between two parties Authentication of the two partiesrsquolong-term public keys is implicitly and mutually achievedby a successful agreement of the HIMMO key between theparties since it is derived from both the public keys of thecommunicating parties and their private HIMMO keying ma-terials Therefore a successful key agreement automaticallyverifies both partiesrsquo public keys to each other since thisagreement never works unless both parties perform this stepusing authentic certified public keys and proper HIMMOkey materials that have been cryptographically bound totheir certified public keys The same idea also preventsconventional attacks such as a Man-in-the-Middle (MITM)attack on the handshake between Alice and Bob since theauthentication involves both of their private key materialsand certified public keys (exchanged via verifiable certifi-cates) thus making it impossible for the attacker to eitherimpersonate Alice or Bob to the other party

The final key and therefore the actual communication be-tween the parties receives combined protection from bothHIMMO and public-key cryptography In [32] it is argued us-ing the Leftover Hash Lemma [26] that if a secret is composedof two other independent secrets an attacker cannot recoverthe combined secret as long as one of the constituent secretsis unknown to him As a result even if the attacker possessesquantum computing capabilities and is able to recover khe fails to learn the key kHIMMO

ba thus preventing him fromlearning the session key kba In [21] it has been shownthat all attacks on HIMMO found so far lead to lattice-basedcryptanalysis thereby HIMMO provides quantum-security toany scheme that uses keys derived using it Furthermore [20]explicitly contains an analysis of quantum-capable attacks onthe HIMMO scheme Thus the overall communication ben-efits from both classic- and quantum-secure confidentialityand authentication

The architecture is also flexible enough to incorporate addi-tional strong security properties such as forward-secrecy withminimal changes ndash such as using an ephemeral publicprivatekey-pair to transport the random key k between the com-municating parties during the Secure Operation phase (seeFigure 7 in Appendix C for an instantiation)

Finally we note that due to HIMMOrsquos use of multipleTTPs and consequently our architecturersquos use of multipleroots of trust the level of security can be increased n-fold(when using HIMMO key material obtained from n roots oftrust during the Enrollment phase) with almost no corre-sponding increase in computation or communication cost dueto the nature of HIMMOrsquos operation when using multipleTTPs Anything short of a total compromise of all roots oftrust would affect neither confidentiality nor authenticationas the final private HIMMO key material of the enrolledparties and therefore HIMMO symmetric keys generated bythem remain secret in turn ensuring that the final session orMaster secret and therefore the final communication channelalso remains secure

CiphersuiteHandshake time

(ms)Handshake size

(Bytes)

ECDHE ECDSA WITH AES 256 CBC SHA (nistp256) 491 3277

NTRU RSA WITH AES 256 CBC SHA (EES439EP1) 293 5381

ECDHE ECDSA WITH AES 256 CBC SHA HIMMO256 505 3330

NTRU RSA WITH AES 256 CBC SHA HIMMO256 316 5448

NTRU RSA WITH AES 256 CBC SHA HIMMO256 3 TTP 349 5640

Table 1 TLS performance for different ciphersuites including existing classical and hybrid post-quantumciphersuites extended with HIMMO key generation using key material bound with certified public keys asper our design (256-bit HIMMO key with a large security parameter t = 4000) Extensions using both single-TTP and multi-TTP HIMMO implementations are shown The Elliptic Curve key-exchange and signatureimplementations use the NIST P-256 curve providing 128-bits of security NTRUEncrypt key-exchange usethe NTRU parameter set EES439EP1 with a 608 byte public key at 128-bit security

62 Performance Evaluation amp BenchmarksTo validate our research we implement the protocol de-

scribed in Section 5 by extending the CyaSSL library andusing TLSv2 The TLS protocol is executed between twomachines within the same Local Area Network Each ma-chinePC uses Windows 7 Enterprise (64 bit) with an IntelCore i5-5300U 230 GHz Software was compiled for thex86_64 architecture with full optimization (Ox) using theMicrosoft Visual C compiler

Table 1 compares the performance of different TLS hand-shakes using pre- and post-quantum ciphersuites Pre-quantum ciphersuites use ECDHE ECDSA while post-quantumciphersuites rely on NTRU RSA (NTRU is used to encrypta secret that is exchanged the NTRU public-key is signedwith RSA) We compare them after adding HIMMO nextto them using a single TTP The HIMMO parameter b ischosen to be 32 Several HIMMO systems are used in parallelto obtain a 256 bit key The additional time or bandwidthconsumption is minimal while enabling the verification ofpublic keys and generation of a symmetric-secret Further-more the increase in running times of the TLS handshakefor the classic ECDHE ECDSA and the post-quantum ci-phersuite NTRU RSA when extended with HIMMO wherethe HIMMO key is computed from key material assigned bythree TTPs (as per the protocol in Section 5) is minimalEach TTP is managed by a different organization or has in-dependent locations thus preventing a single point of failureExtending the classical ECDHE ECDSA with a single-TTPHIMMO implementation results in a TLS handshake thatis slower by only 28 for the HIMMO security parametert = 4000 (505 ms for the extended ciphersuite as comparedto 491 ms for classic ECDHE+ECDSA) Note that this valueof t is quite conservative [21] the drop in speed of the TLShandshake is minimal by comparison For the post-quantumciphersuite NTRU RSA the increase in computation over-head is 78 for a single-TTP implementation (316 ms forthe single-TTP extended ciphersuite as compared to 293 msfor the original NTRU+RSA one) and 191 for a three-TTPimplementation (349 ms) both cases for t = 4000 A furtheroptimization is possible for the multiple-TTP implementa-tion instead of sequentially creating and combining threeHIMMO sub-keys it is possible to generate a single HIMMOkey after adding the coefficientscomponents of the key ma-terials obtained from different TTPs Once this optimizationis done we expect a timing similar to the usage of a single

of TTP irrespective of the number of TTPs used[21 17] present insights into the efficient lightweight per-

formance of HIMMO It is demonstrated that an increaseof the HIMMO security parameter t to a very high valuethat directly determines the dimension of the lattice thatneeds to be reduced in order to find a closeshort vector [21]still does not have a huge impact in the CPU needs whilebandwidth consumption remains practically constant andequal to a few bytes Memory increases but for applicationareas such as the Internet a storage requirement of a coupleof megabytes is affordable IoT applications have differentperformance criteria communication bandwidth energy con-sumption timing and memory For all of these HIMMO isoptimal By construction HIMMO has low communicationand energy needs since it is identity-based and since wirelesscommunication consumes most of the energy budget Timingis also optimal although key material size is on the high sideEven without optimizations memory is the least relevantcriteria IoT devices are getting bigger memories computersand phones have sufficient memory capabilities

63 Discussion amp ComparisonThe solution proposed in this paper exhibits advantageous

properties compared with other architectures as shown inTable 2 Firstly the usage of HIMMO to create the finalsession key that protects a secure channel between any pair ofdevices makes the operational communication link betweenthem quantum-resistant Secondly the use of an indepen-dent public-key cryptosystem ensures secure distributionof key material during the initial enrollment and preventseavesdropping by rogue TTPs during Secure Operation Thearchitecture supports multiple roots of trust (based onHIMMO TTPs) with low overhead ensuring that the systemremains secure even if individual roots of trust are compro-mised Operationally if a secure channel between partiesis established based on HIMMO only this results in a non-interactive method for key agreement and authenticationideal for IoT scenarios Together with the incorporationof multiple TTPs this configuration of our architecture (iebased on only HIMMO) provides a solid solution for use casesin which lawful interception of communication is requiredAt the same time this does not infringe upon the right toprivacy of legitimate communications since it would requirea unanimous cooperation among all TTPs involved in thecommunication preventing possible abuses of power

Supported Features Traditional PKI Kerberos KPS QSH-TLS [32] DTLS-HIMMO [19] This paper

Quantum-safe confidentiality Depends on PK Yes Yes Yes Yes Yes

Quantum-safe authentication Depends on PK Yes Yes No Yes Yes

Enrollment Secure in-band Out-of-band Out-of-band Secure in-band Out-of-band Secure in-band

Multiple roots of trust Yes (high overhead) No Yes Yes (high overhead) Yes Yes (low overhead)

Non-interactive operation No No Yes No Yes Yes

Forward-secrecy Yes No No Yes No Yes

Authentication overhead High (explicit High (online Low High (explicit Low Low

signature) interaction) (symmetric) signature) (symmetric) (symmetric)

Scalability High Medium Medium Medium High Higher

Table 2 Comparison of the hybrid infrastructure presented in this paper with existing security architecturesfor a number of security and operational features

Figure 4 Comparison of communication overhead in TLS authentication phase when using (a) HIMMO keygeneration-based authentication with one TTP (b) with two TTPs (c) with three TTPs (all using 256-bitHIMMO key with a large security parameter t = 4000) (d) XMSS with 82 bit security (e) NTRUMLS withparameter set 401 [23] and 112 bit security (f) classic ECDSA with the curve nistp256 Data exchanged forauthentication purposes when using our HIMMO-based solution amounts to only HIMMO helper data forkey reconciliation

Considering authentication a HIMMO key material as-signed to a node is bound to its public-key so that theHIMMO key material acts as the nodersquos implicit digital cer-tificate allowing a node to verify public parameters of otherdevices with very low overhead while supporting multipleroots of trust Upgrading to any public-key cryptosystem issimple through the use of the corresponding digital certifi-cate or public-key as the HIMMO identity

Thus the proposed architecture is highly scalable evenif an out-of-band channel is not available as is the case in theInternet and is applicable to a wide range of use cases In con-trast the hybrid TLS handshake in [32] focuses on traditionalInternet applications only and does not support authentica-tion by multiple roots of trust The DTLS-HIMMO work [19]addresses IoT use cases but lacks a solution for in-band en-rollment or the capability of providing forward-secrecy

Considering post-quantum authentication we quantify thegains of our solution by comparing it with two signature

schemes considered quantum-resistant namely XMSS [6]and NTRUMLS [23] XMSS with an h value equal to 8 (iethe height of the XMSS hash tree) allows creating at most 256signatures each approximately 2436 Bytes long and havinga signature verification time of 195 ms [15] NTRUMLSfor parameters 401 and 743 involve signatures of around853 and 1765 Bytes with verification times of 033 and 079ms respectively [15] We note that computationally theactual post-quantum authentication step in our solution iethe generation of the HIMMO symmetric key is 65 fasterthan that of XMSS (067 ms compared to XMSSrsquos 195 ms)and 15 faster than that of NTRUMLS (067 ms comparedto NTRUMLSrsquos 079 ms) considering the relatively secureNTRUMLS parameter set 743 and a high HIMMO securityparameter value of t = 4000

Furthermore Figure 4 compares the communication over-head during TLS authentication comparing the amount ofbytes exchanged by classic and existing post-quantum sig-

natures with that exchanged by the authentication in ourHIMMO-based solution Since this consists of only HIMMOhelper data as compared to full-fledged digital signatures inthe former case our solution has a strong advantage regard-ing communication overhead or signature sizes

Figure 4 also shows that even achieving higher securitythrough the use of multiple roots of trust (ie TTPs) comesat virtually no added cost since the size of the HIMMOhelper data exchanged between parties for key reconcilia-tion only grows logarithmically with the increase in numberof TTPs (ie roots of trust) and not linearly When a n-TTP implementation is used the final key is derived as acombination of n intermediate HIMMO keys each derivedfrom one key material instance (obtained from one root oftrust) with HIMMO parameters t and m However if theHIMMO parameter t is same for all intermediate key mate-rials then the final HIMMO key corresponds to a symbolicHIMMO key material with parameters t and nm The sizeu of the helper data for this HIMMO key would then beu = dlog2(4nmt + 1)e (see Appendix B) which essentiallygrows logarithmically with n For more details about the ex-act nature of HIMMO helper data that leads to this desirablebehavior see Appendix B

In comparison for traditional digital signatures such asXMSS and NTRUMLS (albeit quantum-resistant) to achievethe same increase in security usage of certifications frommultiple CAs is necessary This involves a linear growth ofcomputation overhead (key-pair generation signature gen-eration signature verification) as well as communicationoverhead (exchange of multiple signatures) with the numberof CAs involved Thus the main advantage of our approachrelates to the implicit verification of public keys thatinvolves minimal overhead even with stronger security con-ditions such as multiple roots of trust (see Section 62)

7 CONCLUSIONSWe presented a hybrid security architecture combining

public-key cryptography and key pre-distribution schemesWe chose HIMMO as the KPS instantiation since it is theonly known scheme that is both efficient and collusion- andquantum-resistant The hybrid architecture combines desir-able features of both worlds it is scalable supports secureenrollment and efficient support for multiple roots of trustDue to its non-interactive key agreement the scheme is idealfor use cases with strict timing constraints limited band-width or a tight energy budget as often encountered in theIoT The hybrid scheme also finds a broader application inthe Internet since it allows for efficient verification of pub-lic keys with minimal overhead while providing advancedfeatures such as forward-secrecy

The architecture can already be deployed to improve per-formance of Internet communications in todayrsquos pre-quantumworld while providing a path towards a quantum-resistantyet highly efficient Internet Our TLS proof-of-concept imple-mentation proves this by showing how existing non-quantumresistant communications based on ECC or quantum-safepublic keys such as NTRU public keys can be verified withan increased communication overhead of less than 1 andvery low computational overhead Due to the identity-basednature of the HIMMO scheme the exchanged amount ofdata and time required for key generation remain practicallyconstant even if the HIMMO security parameters are madeextremely large

8 REFERENCES[1] C Adams Impersonation Attack pages 596ndash596

Springer US Boston MA 2011

[2] E Alkim L Ducas T Poeppelmann and P SchwabePost-Quantum Key Exchange ndash A New Hope 2015Cryptology ePrint Archive Report 2015-1092

[3] M Bellare and P Rogaway Entity Authentication andKey Distribution pages 232ndash249 Springer BerlinHeidelberg Berlin Heidelberg 1994

[4] J Bos C Costello L Ducas I Mironov M NaehrigV Nikolaenko A Raghunathan and D Stebila FrodoTake off the ring practical quantum-secure keyexchange from lwe Cryptology ePrint Archive Report2016659 2016 httpeprintiacrorg2016659

[5] J Bos C Costello M Naehrig and D StebilaPost-quantum key exchange for the TLS protocol fromthe ring learning with errors problem 2014httpeprintiacrorg2014599

[6] J Buchmann E Dahmen and A Hulsing XMSS APractical Forward Secure Signature Scheme based onMinimal Security Assumptions 2011httpeprintiacrorg20151003

[7] D Butin S-L Gazdag and J Buchmann Real-worldpost-quantum digital signatures In Cyber Security andPrivacy pages 41ndash52 Springer 2015

[8] S Checkoway R Niederhagen A EverspaughM Green T Lange T Ristenpart D J BernsteinJ Maskiewicz H Shacham and M Fredrikson On thePractical Exploitability of Dual EC in TLSImplementations In 23rd USENIX Security Symposium(USENIX Security 14) pages 319ndash335 San Diego CAAug 2014 USENIX Association

[9] L Chen S Jordan Y-K Liu D Moody R PeraltaR Perlner and D Smith-Tone Report onPost-Quantum Cryptography NISTIR8105 2016httpcsrcnistgovpublicationsdraftsnistir-8105nistir 8105 draftpdf

[10] Y Chen Q Huang and Z ZhangSakai-ohgishi-kasahara identity-based non-interactivekey exchange revisited and more Cryptology ePrintArchive Report 2014310 2014httpeprintiacrorg2014310

[11] J Ding and D Schmidt Rainbow a new multivariablepolynomial signature scheme In Applied Cryptographyand Network Security pages 164ndash175 Springer 2005

[12] D Eastlake Transport Layer Security (TLS)Extensions Extension Definitions 2011 RFC6066

[13] P Eronen and H Tschofenig Pre-Shared KeyCiphersuites for Transport Layer Security (TLS) RFC4279 (Proposed Standard) Dec 2005

[14] ETSI TS 101 331 - V131 - Lawful Interception (LI)Requirements of Law Enforcement Agencies October2009httpsarchiveorgdetailsetsi ts 101 331 v010301

[15] ETSI GRQSC-001 - V111 - Quantum-SafeCryptography (QSC) Quantum-safe algorithmicframework July 2016httpwwwetsiorgdeliveretsi grQSC001 099001010101 60gr QSC001v010101ppdf

[16] S Fluhrer D McGrew and P Kampanakis AnExtension for Postquantum Security using PresharedKeys for IKEv2 2015

Alice TTP (Root of Trust)

Possesses asymmetric key-pair Pka Ska Possesses secret root key material R1 Pka Naminusminusminusminusminusminusminusminusrarr2 EPkaNtlarrminusminusminusminusminusminusminusminusminus

3 Decrypt Nt4 Ntminusminusminusminusrarr

5 Verify Nt

sa(x) = R(hash(Pka) x)6 EPkasa(x)|hash(sa(x)|Na)larrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminus

7 Decrypt key material sa(x)

Verify integrity and Na

Figure 1 Enrollment and Certification of a communicating entity Alice with a root of trust ie a HIMMOTTP resulting in Alice getting her long-term public-key Pka certified and securely receiving private HIMMOkey material sPka(x) that is bound to Pka This key material is created by the HIMMO TTP using itssecret root key material R Na and Nt are random ephemeral nonces that prevent replay attacks and enableverification of the enrolleersquos identity respectively

in the system she generates a publicprivate key-pair (ideallyquantum-resistant) and combines the public-key with anyother identification information Alice then enrolls with oneor several HIMMO TTPs To this end she must send toeach TTP this set of identification information that mustcontain at least her public-key Pka This is demonstrated inStep (1) of Figure 1 that depicts Alicersquos enrollment with asingle TTP

When the TTP receives Alicersquos information it can furtherverify it for consistency and optionally add additional param-eters eg an expiration date creating a certificate of Alicersquosidentity Before this the TTP ascertains Alicersquos identity(to thwart would-be impersonators) by using the public-keyreceived to encrypt and send a random fresh nonce Nt toAlice (Figure 1 Step (2)) that she must then decrypt andsend back to the TTP (Steps (34)) Next given Alicersquoscertificate the TTP computes a HIMMO identity for Aliceby hashing the certificate (containing at least her public-keyPka) and uses this to extract the corresponding HIMMO keymaterial sa(x) for her in Step (5) Therefore through Alicersquosidentity and in turn through the certificate containing Pka(or through Pka directly as in Figure 1) sa(x) generatedfor Alice is now cryptographically bound to Pka In Step(6) the TTP can use Alicersquos public-key Pka to encrypt andsend the computed HIMMO key material sa(x) to her sothat only the owner of Pka can decrypt sa(x) The TTPincludes a hash of the key material in the encrypted messagealong with a nonce Na originating from Alice that acts as anauthentication token This is decrypted and verified by Alicein Step (7) following which she can use her new HIMMOkey material

We note that the final HIMMO key material associatedto Alice can include the HIMMO key material received frommultiple TTPs This information can be stored either with-out being combined or combined into one single instance ofHIMMO key material by adding the componentscoefficientsof multiple HIMMO key materials received from differentTTPs one by one In case of multiple TTPs some commu-nication between them may be required to ensure that theyall generate the same HIMMO identity for Alice

43 Secure Operation

Following the successful enrollment of two entities Aliceand Bob with one or multiple roots of trust they should beable to establish a secure communication session in the abovesetting ie each of them has public keys Pka and Pkb boundto private HIMMO key materials sa(x) and sb(x) In case ofmultiple TTPs these are combinations of the individual keymaterials generated by the TTPs involved We believe thatmany security protocols can be designed in general (a fewexamples of which can be found in Appendix C) throughthe following steps

bull Alice exposes her supported TTPs to Bob

bull Bob decides whether Alice supports at least a minimumnumber of TTPs that he also trusts If not Bob abortsOtherwise Bob exchanges these TTPsrsquo identifiers withAlice so that she can also verify whether that set ofTTPs provides her with enough trust

bull Alice and Bob engage in a handshake for key exchangeand mutual authentication that relies on public-keycryptography (ideally quantum-resistant) to achievestrong properties such as forward-secrecy and on HIMMOto verify the identities of the communicating partiesand thus to ensure an authenticated channel

bull Upon the establishment of a secure channel Alice andBob exchange data in a secure way

The handshake between Alice and Bob resulting in a con-fidential authenticated channel is an adapted form of theBellare-Rogaway AKEP1 [3] with the final session key thatprotects both confidentiality and authentication of the com-munication between Alice and Bob being derived from anadditional random key established using asymmetric cryptog-raphy apart from the HIMMO key (and thus independentfrom HIMMO and its TTPs)

Authentication of public keys happens without traditionaldigital signatures but HIMMO The HIMMO key materialsa(x) of a party A is cryptographically bound to its identity

1authenticated key-exchange protocol

Alice Bob

Possesses asymmetric key-pair Pka Ska and secretHIMMO key material sa(x)

Possesses asymmetric key-pair Pkb Skb and secretHIMMO key material sb(x)

1 Pka Naminusminusminusminusminusminusminusminusrarr2 kHIMMO

ba HelperData = sb(Pka)

Create key k randomly

kba = KDF (kHIMMOba k)

MACba = MACkba (k|Nb|Na)3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusEPka (k) HelperData

4 Decrypt k

kHIMMOba = sa(Pkb) + HelperData

kba = KDF (kHIMMOba k)

Verify MACba using kba

MACab = MACkba (k|Na|Nb)5 MACabminusminusminusminusminusminusminusminusrarr

6 Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 2 Secure Operation for establishing a confidential authenticated channel between two parties Aliceand Bob Authentication is achieved using HIMMO key material bound to long-term certified public keysConfidentiality is achieved using a combination of HIMMO and a shared session key transported usingasymmetric cryptography ideally quantum-resistant Na and Nb are random ephemeral nonces used toprevent replay attacks

which in turn is bound to the partyrsquos public-key Pka Suc-cessful agreement of a HIMMO key between two parties usingauthentic key materials and authentic public-keys results ina successful mutual authentication

Prevention of single points of failure (as in traditional PKI)is accomplished by performing this authentication with keymaterial generated by multiple TTPs preventing imperson-ation of public keys even if some TTPs are compromisedFurthermore this does not affect performance due to the na-ture of HIMMOrsquos operation while using multiple TTPs Theuse of asymmetric-cryptography for key exchange ensuresthat TTPs cannot access the communication and enablesforward-secrecy for advanced use cases eg communicationover the Internet

The above general operational protocol is exemplified ina very specific operational handshake for key exchange andmutual authentication depicted in Figure 2 In this examplea single TTP is commonly supported by the communicatingentities Alice and Bob In Step (1) Alice sends her public-key Pka to Bob along with a fresh nonce Na In Step (2)Bob computes the HIMMO key kHIMMO

ba using HIMMO andadditionally generates a secret random key k Bob thensecurely combines both keys into a session key kba using itto compute a Message Authentication Code (MAC) basedon the random key k the nonce Na received from Alice andanother nonce Nb locally generated Next in Step (3) Bobreplies to Alice exchanging his long-term public-key Pkb hisown nonce Nb and the computed MAC so that in Step (4)Alice can perform equivalent steps at her side and verify thereceived MAC and that Bob computed the same HIMMO keykHIMMOba and therefore verify Bobrsquos public-key Furthermore

Bob also sends the session key k to Alice encrypted usingher public-key

After decrypting and recovering the random key k Al-

ice independently regenerates kHIMMOba by using non-secret

HIMMO helper data sent to her by Bob to reconcile any smalldifference between her own and Bobrsquos computed HIMMOkeys Following this both Alice and Bob possess the samesymmetric HIMMO key kHIMMO

ba the same random key kand thereby the same session key kba Finally in Step (5)Alice sends her MAC to Bob so that he can verify Alicersquoslong-term public-key and the random key k in Step (6) NextAlice and Bob can proceed to communicate in a secure au-thenticated way in Step (7) using the final key kba createdby combining kHIMMO

ba and k to protect their communicationThe structure of this handshake can further be extended to

support more generic use-cases and advanced security proper-ties such as forward-secrecy via the use of ephemeral publickeys to transport the session key between Alice and BobTo illustrate this Appendix C depicts three embodiments ofthis handshake ndash a generic version with any suitable public-key key-establishment scheme PKE and key pre-distributionscheme KPS a version instantiated with the post-quantumNTRU key-exchange and with HIMMO and finally a finalversion instantiated with the forward-secure classic ECDHkey-agreement and with HIMMO as the KPS scheme

5 PROOF-OF-CONCEPT WITH TLS TLS-HIMMO

As a proof of concept we illustrate the above generic archi-tecture by instantiating it in the context of the TLS protocolWe use HIMMO in our proof of concept since it enablesefficient distribution of pairwise keys implicit verification ofcredentials and supports multiple TTPsroots of trust Wefurther use ECDH and NTRUEncrypt [24] as the pre- andpost-quantum cryptographic primitives for key-establishmentand ECDSA as the pre-quantum cryptographic primitive forauthentication

Client Server

1 ClientHello = Ciphersuitesc + TTPListc1+ 2 ClientHellominusminusminusminusminusminusminusminusminusrarr

3 ServerHello = Ciphersuitess + TTPLists + 4 ServerHellolarrminusminusminusminusminusminusminusminusminusminus

5 kHIMMOcs HelperData = s1c(QshPks) +

s2c(QshPks) +

6 ClientKeyExchange =EClassicPks (ClassicS)|EQshPks

(CliS)

|HelperData27 ClientKeyExchangeminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarr

8 Decrypt ClassicS CliS

9 kHIMMOcs = s1s(QshPkc) + s2s(QshPkc) + +

HelperData

10 PMS3= Classic|CliS|kHIMMOcs 10 PMS = Classic|CliS|kHIMMO

cs 11 MasterSecret = PRF (PMS) 11 MasterSecret = PRF (PMS)

12Finishedaminusminusminusminusminusminusminusminusminusrarr13 Verify Finisheda

14Finishedblarrminusminusminusminusminusminusminusminusminus15 Verify Finishedb

16 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using MasterSecret 16 Application Data

1 List of supported HIMMO TTP IDs as per RFC 6066 [12]2 ClassicS CliS are the classic secret and client QSH (assuming [32]) secret respectively3 Pre-master Secret used to generate the TLS Master Secret by means of the TLS pseudo-random function PRF

Figure 3 TLS Handshake including the design proposed in this paper including negotiation of a common setof trusted TTPs and establishment of a confidential authenticated channel protected by a combination of aclassic secret a quantum-safe secret CliS and a quantum-safe HIMMO key The HIMMO key is created usinga combination of key materials obtained from multiple negotiated TTPs and the peerrsquos long-term public-keyideally quantum-resistant

Figure 3 shows the complete TLS handshake between aclient Client and a server Server extended with our designin Section 4 The required additions to support our exten-sions are not many and the main one refers to the capabilityof agreeing on a common set of roots of trust TTPs andagreeing on this type of their use For this we considerRFC 6066 [12] since it defines extensions to the ClientHelloand ServerHello messages in which supported certificationauthorities are exchanged We reuse this extension for ourpurposes as follows

If a client and server have registered with some HIMMOTTPs and obtained HIMMO key material as described in Sec-tion 4 then they exchange the identities of their supportedTTPs Thus in Step (1) of the handshake Client creates aClientHello message including its supported roots of trustie HIMMO TTPs as described in RFC 6066 [12] that isthen sent to Server in Step (2) In step (3) Server searchesfor a common set of HIMMO TTPs that it then includes inthe ServerHello message and sends back to Client in Step (4)If they agree on the usage of HIMMO TTPs they then ex-change certificates or public keys whose hashes are HIMMOidentifiers for which they already possess HIMMO key mate-rial If only classical ciphersuites are considered then suchcertificates correspond to classical primitives eg ECDSAthat are exchanged normally via the ClientCertificate and

ServerCertificate messages If post-quantum keys are sup-ported then an extension header in the ClientHello messageis used (as specified in the hybrid TLS handshake InternetDraft [32]) to exchange additional post-quantum public keysThe exchanged certificates or public keys and correspondingkey material associated to common TTPs allow Client andServer to independently generate pairwise HIMMO keys inSteps (5) and (9) (one key for each common TTP agreedupon) which they then use to independently derive the finalHIMMO key kHIMMO

cs by means of a pseudo-random functionof all previously generated HIMMO keys In the specificexample we describe in Figure 3 Client and Server use eachotherrsquos quantum-resistant public-key to generate kHIMMO

cs insteps (5) and (9) This offers stronger quantum-securityHowever classic public-keys may also be used for this purposeto ease widespread adoption Note that HIMMO requiresa key reconciliation step in which HelperData is exchangedfrom the client and server that we exchange via the Clien-tKeyExchange This is the only protocol field that wouldrequire standardization

To utilize the combined security of HIMMO the classicandor post-quantum key-establishment schemes the TLSMaster Secret used for protecting the TLS record layer iscomputed from a Pre-master secret PMS that is a combi-nation of the classical key Classic the post-quantum key

CliS and the HIMMO key kHIMMOcs This is similar to [32]

and [16] Since the HIMMO key kHIMMOcs is one of the in-

puts to the Master Secret in Steps (10) and (11) via thePre-master Secret PMS it ensures the confidentiality andauthentication of the messages exchanged in the record layerMost importantly it also implicitly verifies the certificatesand public keys of Client and Server since the Master Secretis used in the computation of a Message Authentication Codein the Finished message that both parties must indepen-dently compute exchange and verify (in steps (13) and (15))This MAC is thus bound to the kHIMMO

cs that both partiesindependently computed using the certificates of the otherparty and their own HIMMO key material and can there-fore be considered equal to the MACba exchanged as anauthentication token during the Secure Operation phase (seeFigure 2) The MACrsquos verification by Server and Client willfail unless they computed the right kHIMMO

cs using an authen-tic certificatepublic-key of the other party and proper keymaterial and its success automatically authenticates bothServer and Client to each other

Finally note that the above authentication using HIMMOcan be done using multiple TTPs while also being capableof forward-secrecy and non-repudiation (through the addedincorporation of standard digital signatures) Lawful in-terception use-cases would require the client and server toexclude the exchange of public keys during operation andthus rely only on HIMMO and multiple TTPs to provide aproper privacy trade-off

6 EVALUATIONIn this section we begin with an analysis of the security

provided by our hybrid architecture in Section 61 followedby a quantitative evaluation of its performance in Section 62Section 63 presents a qualitative discussion of the architec-turersquos contributions and quantitatively compares it with thestate of the art

61 Security AnalysisIn this subsection we look at our hybrid architecture and

analyze its security A core contribution of this architectureis imparting quantum-safe authentication and confidentialityto communication channels in a scalable and efficient man-ner The private information possessed by a party ie thesecret HIMMO key material plays a key part in this andmust therefore be securely allocated to the party beforehandSuch confidential distribution of HIMMO key material isachieved by the Enrollment phase as it allows parties toget their public keys certified by (multiple) root(s) of trustand securely receive key materials from them in a manneranalogous to traditional Public-Key Infrastructure Whileallocating a HIMMO key material to an enrolling party aroot of trust encrypts it using the recipient partyrsquos public-keybefore transmitting the key material to it thereby ensuringconfidentiality of the private key material Furthermore thetransmission of a cryptographically-secure hash of the keymaterial along with the actual key material itself allows itsintegrity to be checked by the recipient party Freshnessof the key material received by a party is also ensured andmessage-replay attacks are prevented by the transmission(and verification) of freshly-generated nonces A preventivemeasure against impersonators trying to enroll with the rootof trust is achieved by the use of encrypted nonces at thestart of Enrollment Finally we emphasize once again that

quantum-safe asymmetric cryptography should ideally beused during Enrollment to make sure that the key materialof enrolled parties remains confidential and to prevent re-covery of an enrolling partyrsquos secret HIMMO key materialby a quantum-capable attacker (leading to identity imper-sonation [1]) Using classic public-key cryptography sufficesonly for the short-term to ease widespread adoption

Next we discuss the security of the Secure Operation hand-shake between two parties Authentication of the two partiesrsquolong-term public keys is implicitly and mutually achievedby a successful agreement of the HIMMO key between theparties since it is derived from both the public keys of thecommunicating parties and their private HIMMO keying ma-terials Therefore a successful key agreement automaticallyverifies both partiesrsquo public keys to each other since thisagreement never works unless both parties perform this stepusing authentic certified public keys and proper HIMMOkey materials that have been cryptographically bound totheir certified public keys The same idea also preventsconventional attacks such as a Man-in-the-Middle (MITM)attack on the handshake between Alice and Bob since theauthentication involves both of their private key materialsand certified public keys (exchanged via verifiable certifi-cates) thus making it impossible for the attacker to eitherimpersonate Alice or Bob to the other party

The final key and therefore the actual communication be-tween the parties receives combined protection from bothHIMMO and public-key cryptography In [32] it is argued us-ing the Leftover Hash Lemma [26] that if a secret is composedof two other independent secrets an attacker cannot recoverthe combined secret as long as one of the constituent secretsis unknown to him As a result even if the attacker possessesquantum computing capabilities and is able to recover khe fails to learn the key kHIMMO

ba thus preventing him fromlearning the session key kba In [21] it has been shownthat all attacks on HIMMO found so far lead to lattice-basedcryptanalysis thereby HIMMO provides quantum-security toany scheme that uses keys derived using it Furthermore [20]explicitly contains an analysis of quantum-capable attacks onthe HIMMO scheme Thus the overall communication ben-efits from both classic- and quantum-secure confidentialityand authentication

The architecture is also flexible enough to incorporate addi-tional strong security properties such as forward-secrecy withminimal changes ndash such as using an ephemeral publicprivatekey-pair to transport the random key k between the com-municating parties during the Secure Operation phase (seeFigure 7 in Appendix C for an instantiation)

Finally we note that due to HIMMOrsquos use of multipleTTPs and consequently our architecturersquos use of multipleroots of trust the level of security can be increased n-fold(when using HIMMO key material obtained from n roots oftrust during the Enrollment phase) with almost no corre-sponding increase in computation or communication cost dueto the nature of HIMMOrsquos operation when using multipleTTPs Anything short of a total compromise of all roots oftrust would affect neither confidentiality nor authenticationas the final private HIMMO key material of the enrolledparties and therefore HIMMO symmetric keys generated bythem remain secret in turn ensuring that the final session orMaster secret and therefore the final communication channelalso remains secure

CiphersuiteHandshake time

(ms)Handshake size

(Bytes)

ECDHE ECDSA WITH AES 256 CBC SHA (nistp256) 491 3277

NTRU RSA WITH AES 256 CBC SHA (EES439EP1) 293 5381

ECDHE ECDSA WITH AES 256 CBC SHA HIMMO256 505 3330

NTRU RSA WITH AES 256 CBC SHA HIMMO256 316 5448

NTRU RSA WITH AES 256 CBC SHA HIMMO256 3 TTP 349 5640

Table 1 TLS performance for different ciphersuites including existing classical and hybrid post-quantumciphersuites extended with HIMMO key generation using key material bound with certified public keys asper our design (256-bit HIMMO key with a large security parameter t = 4000) Extensions using both single-TTP and multi-TTP HIMMO implementations are shown The Elliptic Curve key-exchange and signatureimplementations use the NIST P-256 curve providing 128-bits of security NTRUEncrypt key-exchange usethe NTRU parameter set EES439EP1 with a 608 byte public key at 128-bit security

62 Performance Evaluation amp BenchmarksTo validate our research we implement the protocol de-

scribed in Section 5 by extending the CyaSSL library andusing TLSv2 The TLS protocol is executed between twomachines within the same Local Area Network Each ma-chinePC uses Windows 7 Enterprise (64 bit) with an IntelCore i5-5300U 230 GHz Software was compiled for thex86_64 architecture with full optimization (Ox) using theMicrosoft Visual C compiler

Table 1 compares the performance of different TLS hand-shakes using pre- and post-quantum ciphersuites Pre-quantum ciphersuites use ECDHE ECDSA while post-quantumciphersuites rely on NTRU RSA (NTRU is used to encrypta secret that is exchanged the NTRU public-key is signedwith RSA) We compare them after adding HIMMO nextto them using a single TTP The HIMMO parameter b ischosen to be 32 Several HIMMO systems are used in parallelto obtain a 256 bit key The additional time or bandwidthconsumption is minimal while enabling the verification ofpublic keys and generation of a symmetric-secret Further-more the increase in running times of the TLS handshakefor the classic ECDHE ECDSA and the post-quantum ci-phersuite NTRU RSA when extended with HIMMO wherethe HIMMO key is computed from key material assigned bythree TTPs (as per the protocol in Section 5) is minimalEach TTP is managed by a different organization or has in-dependent locations thus preventing a single point of failureExtending the classical ECDHE ECDSA with a single-TTPHIMMO implementation results in a TLS handshake thatis slower by only 28 for the HIMMO security parametert = 4000 (505 ms for the extended ciphersuite as comparedto 491 ms for classic ECDHE+ECDSA) Note that this valueof t is quite conservative [21] the drop in speed of the TLShandshake is minimal by comparison For the post-quantumciphersuite NTRU RSA the increase in computation over-head is 78 for a single-TTP implementation (316 ms forthe single-TTP extended ciphersuite as compared to 293 msfor the original NTRU+RSA one) and 191 for a three-TTPimplementation (349 ms) both cases for t = 4000 A furtheroptimization is possible for the multiple-TTP implementa-tion instead of sequentially creating and combining threeHIMMO sub-keys it is possible to generate a single HIMMOkey after adding the coefficientscomponents of the key ma-terials obtained from different TTPs Once this optimizationis done we expect a timing similar to the usage of a single

of TTP irrespective of the number of TTPs used[21 17] present insights into the efficient lightweight per-

formance of HIMMO It is demonstrated that an increaseof the HIMMO security parameter t to a very high valuethat directly determines the dimension of the lattice thatneeds to be reduced in order to find a closeshort vector [21]still does not have a huge impact in the CPU needs whilebandwidth consumption remains practically constant andequal to a few bytes Memory increases but for applicationareas such as the Internet a storage requirement of a coupleof megabytes is affordable IoT applications have differentperformance criteria communication bandwidth energy con-sumption timing and memory For all of these HIMMO isoptimal By construction HIMMO has low communicationand energy needs since it is identity-based and since wirelesscommunication consumes most of the energy budget Timingis also optimal although key material size is on the high sideEven without optimizations memory is the least relevantcriteria IoT devices are getting bigger memories computersand phones have sufficient memory capabilities

63 Discussion amp ComparisonThe solution proposed in this paper exhibits advantageous

properties compared with other architectures as shown inTable 2 Firstly the usage of HIMMO to create the finalsession key that protects a secure channel between any pair ofdevices makes the operational communication link betweenthem quantum-resistant Secondly the use of an indepen-dent public-key cryptosystem ensures secure distributionof key material during the initial enrollment and preventseavesdropping by rogue TTPs during Secure Operation Thearchitecture supports multiple roots of trust (based onHIMMO TTPs) with low overhead ensuring that the systemremains secure even if individual roots of trust are compro-mised Operationally if a secure channel between partiesis established based on HIMMO only this results in a non-interactive method for key agreement and authenticationideal for IoT scenarios Together with the incorporationof multiple TTPs this configuration of our architecture (iebased on only HIMMO) provides a solid solution for use casesin which lawful interception of communication is requiredAt the same time this does not infringe upon the right toprivacy of legitimate communications since it would requirea unanimous cooperation among all TTPs involved in thecommunication preventing possible abuses of power

Supported Features Traditional PKI Kerberos KPS QSH-TLS [32] DTLS-HIMMO [19] This paper

Quantum-safe confidentiality Depends on PK Yes Yes Yes Yes Yes

Quantum-safe authentication Depends on PK Yes Yes No Yes Yes

Enrollment Secure in-band Out-of-band Out-of-band Secure in-band Out-of-band Secure in-band

Multiple roots of trust Yes (high overhead) No Yes Yes (high overhead) Yes Yes (low overhead)

Non-interactive operation No No Yes No Yes Yes

Forward-secrecy Yes No No Yes No Yes

Authentication overhead High (explicit High (online Low High (explicit Low Low

signature) interaction) (symmetric) signature) (symmetric) (symmetric)

Scalability High Medium Medium Medium High Higher

Table 2 Comparison of the hybrid infrastructure presented in this paper with existing security architecturesfor a number of security and operational features

Figure 4 Comparison of communication overhead in TLS authentication phase when using (a) HIMMO keygeneration-based authentication with one TTP (b) with two TTPs (c) with three TTPs (all using 256-bitHIMMO key with a large security parameter t = 4000) (d) XMSS with 82 bit security (e) NTRUMLS withparameter set 401 [23] and 112 bit security (f) classic ECDSA with the curve nistp256 Data exchanged forauthentication purposes when using our HIMMO-based solution amounts to only HIMMO helper data forkey reconciliation

Considering authentication a HIMMO key material as-signed to a node is bound to its public-key so that theHIMMO key material acts as the nodersquos implicit digital cer-tificate allowing a node to verify public parameters of otherdevices with very low overhead while supporting multipleroots of trust Upgrading to any public-key cryptosystem issimple through the use of the corresponding digital certifi-cate or public-key as the HIMMO identity

Thus the proposed architecture is highly scalable evenif an out-of-band channel is not available as is the case in theInternet and is applicable to a wide range of use cases In con-trast the hybrid TLS handshake in [32] focuses on traditionalInternet applications only and does not support authentica-tion by multiple roots of trust The DTLS-HIMMO work [19]addresses IoT use cases but lacks a solution for in-band en-rollment or the capability of providing forward-secrecy

Considering post-quantum authentication we quantify thegains of our solution by comparing it with two signature

schemes considered quantum-resistant namely XMSS [6]and NTRUMLS [23] XMSS with an h value equal to 8 (iethe height of the XMSS hash tree) allows creating at most 256signatures each approximately 2436 Bytes long and havinga signature verification time of 195 ms [15] NTRUMLSfor parameters 401 and 743 involve signatures of around853 and 1765 Bytes with verification times of 033 and 079ms respectively [15] We note that computationally theactual post-quantum authentication step in our solution iethe generation of the HIMMO symmetric key is 65 fasterthan that of XMSS (067 ms compared to XMSSrsquos 195 ms)and 15 faster than that of NTRUMLS (067 ms comparedto NTRUMLSrsquos 079 ms) considering the relatively secureNTRUMLS parameter set 743 and a high HIMMO securityparameter value of t = 4000

Furthermore Figure 4 compares the communication over-head during TLS authentication comparing the amount ofbytes exchanged by classic and existing post-quantum sig-

natures with that exchanged by the authentication in ourHIMMO-based solution Since this consists of only HIMMOhelper data as compared to full-fledged digital signatures inthe former case our solution has a strong advantage regard-ing communication overhead or signature sizes

Figure 4 also shows that even achieving higher securitythrough the use of multiple roots of trust (ie TTPs) comesat virtually no added cost since the size of the HIMMOhelper data exchanged between parties for key reconcilia-tion only grows logarithmically with the increase in numberof TTPs (ie roots of trust) and not linearly When a n-TTP implementation is used the final key is derived as acombination of n intermediate HIMMO keys each derivedfrom one key material instance (obtained from one root oftrust) with HIMMO parameters t and m However if theHIMMO parameter t is same for all intermediate key mate-rials then the final HIMMO key corresponds to a symbolicHIMMO key material with parameters t and nm The sizeu of the helper data for this HIMMO key would then beu = dlog2(4nmt + 1)e (see Appendix B) which essentiallygrows logarithmically with n For more details about the ex-act nature of HIMMO helper data that leads to this desirablebehavior see Appendix B

In comparison for traditional digital signatures such asXMSS and NTRUMLS (albeit quantum-resistant) to achievethe same increase in security usage of certifications frommultiple CAs is necessary This involves a linear growth ofcomputation overhead (key-pair generation signature gen-eration signature verification) as well as communicationoverhead (exchange of multiple signatures) with the numberof CAs involved Thus the main advantage of our approachrelates to the implicit verification of public keys thatinvolves minimal overhead even with stronger security con-ditions such as multiple roots of trust (see Section 62)

7 CONCLUSIONSWe presented a hybrid security architecture combining

public-key cryptography and key pre-distribution schemesWe chose HIMMO as the KPS instantiation since it is theonly known scheme that is both efficient and collusion- andquantum-resistant The hybrid architecture combines desir-able features of both worlds it is scalable supports secureenrollment and efficient support for multiple roots of trustDue to its non-interactive key agreement the scheme is idealfor use cases with strict timing constraints limited band-width or a tight energy budget as often encountered in theIoT The hybrid scheme also finds a broader application inthe Internet since it allows for efficient verification of pub-lic keys with minimal overhead while providing advancedfeatures such as forward-secrecy

The architecture can already be deployed to improve per-formance of Internet communications in todayrsquos pre-quantumworld while providing a path towards a quantum-resistantyet highly efficient Internet Our TLS proof-of-concept imple-mentation proves this by showing how existing non-quantumresistant communications based on ECC or quantum-safepublic keys such as NTRU public keys can be verified withan increased communication overhead of less than 1 andvery low computational overhead Due to the identity-basednature of the HIMMO scheme the exchanged amount ofdata and time required for key generation remain practicallyconstant even if the HIMMO security parameters are madeextremely large

8 REFERENCES[1] C Adams Impersonation Attack pages 596ndash596

Springer US Boston MA 2011

[2] E Alkim L Ducas T Poeppelmann and P SchwabePost-Quantum Key Exchange ndash A New Hope 2015Cryptology ePrint Archive Report 2015-1092

[3] M Bellare and P Rogaway Entity Authentication andKey Distribution pages 232ndash249 Springer BerlinHeidelberg Berlin Heidelberg 1994

[4] J Bos C Costello L Ducas I Mironov M NaehrigV Nikolaenko A Raghunathan and D Stebila FrodoTake off the ring practical quantum-secure keyexchange from lwe Cryptology ePrint Archive Report2016659 2016 httpeprintiacrorg2016659

[5] J Bos C Costello M Naehrig and D StebilaPost-quantum key exchange for the TLS protocol fromthe ring learning with errors problem 2014httpeprintiacrorg2014599

[6] J Buchmann E Dahmen and A Hulsing XMSS APractical Forward Secure Signature Scheme based onMinimal Security Assumptions 2011httpeprintiacrorg20151003

[7] D Butin S-L Gazdag and J Buchmann Real-worldpost-quantum digital signatures In Cyber Security andPrivacy pages 41ndash52 Springer 2015

[8] S Checkoway R Niederhagen A EverspaughM Green T Lange T Ristenpart D J BernsteinJ Maskiewicz H Shacham and M Fredrikson On thePractical Exploitability of Dual EC in TLSImplementations In 23rd USENIX Security Symposium(USENIX Security 14) pages 319ndash335 San Diego CAAug 2014 USENIX Association

[9] L Chen S Jordan Y-K Liu D Moody R PeraltaR Perlner and D Smith-Tone Report onPost-Quantum Cryptography NISTIR8105 2016httpcsrcnistgovpublicationsdraftsnistir-8105nistir 8105 draftpdf

[10] Y Chen Q Huang and Z ZhangSakai-ohgishi-kasahara identity-based non-interactivekey exchange revisited and more Cryptology ePrintArchive Report 2014310 2014httpeprintiacrorg2014310

[11] J Ding and D Schmidt Rainbow a new multivariablepolynomial signature scheme In Applied Cryptographyand Network Security pages 164ndash175 Springer 2005

[12] D Eastlake Transport Layer Security (TLS)Extensions Extension Definitions 2011 RFC6066

[13] P Eronen and H Tschofenig Pre-Shared KeyCiphersuites for Transport Layer Security (TLS) RFC4279 (Proposed Standard) Dec 2005

[14] ETSI TS 101 331 - V131 - Lawful Interception (LI)Requirements of Law Enforcement Agencies October2009httpsarchiveorgdetailsetsi ts 101 331 v010301

[15] ETSI GRQSC-001 - V111 - Quantum-SafeCryptography (QSC) Quantum-safe algorithmicframework July 2016httpwwwetsiorgdeliveretsi grQSC001 099001010101 60gr QSC001v010101ppdf

[16] S Fluhrer D McGrew and P Kampanakis AnExtension for Postquantum Security using PresharedKeys for IKEv2 2015

Alice Bob

Possesses asymmetric key-pair Pka Ska and secretHIMMO key material sa(x)

Possesses asymmetric key-pair Pkb Skb and secretHIMMO key material sb(x)

1 Pka Naminusminusminusminusminusminusminusminusrarr2 kHIMMO

ba HelperData = sb(Pka)

Create key k randomly

kba = KDF (kHIMMOba k)

MACba = MACkba (k|Nb|Na)3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusEPka (k) HelperData

4 Decrypt k

kHIMMOba = sa(Pkb) + HelperData

kba = KDF (kHIMMOba k)

Verify MACba using kba

MACab = MACkba (k|Na|Nb)5 MACabminusminusminusminusminusminusminusminusrarr

6 Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 2 Secure Operation for establishing a confidential authenticated channel between two parties Aliceand Bob Authentication is achieved using HIMMO key material bound to long-term certified public keysConfidentiality is achieved using a combination of HIMMO and a shared session key transported usingasymmetric cryptography ideally quantum-resistant Na and Nb are random ephemeral nonces used toprevent replay attacks

which in turn is bound to the partyrsquos public-key Pka Suc-cessful agreement of a HIMMO key between two parties usingauthentic key materials and authentic public-keys results ina successful mutual authentication

Prevention of single points of failure (as in traditional PKI)is accomplished by performing this authentication with keymaterial generated by multiple TTPs preventing imperson-ation of public keys even if some TTPs are compromisedFurthermore this does not affect performance due to the na-ture of HIMMOrsquos operation while using multiple TTPs Theuse of asymmetric-cryptography for key exchange ensuresthat TTPs cannot access the communication and enablesforward-secrecy for advanced use cases eg communicationover the Internet

The above general operational protocol is exemplified ina very specific operational handshake for key exchange andmutual authentication depicted in Figure 2 In this examplea single TTP is commonly supported by the communicatingentities Alice and Bob In Step (1) Alice sends her public-key Pka to Bob along with a fresh nonce Na In Step (2)Bob computes the HIMMO key kHIMMO

ba using HIMMO andadditionally generates a secret random key k Bob thensecurely combines both keys into a session key kba using itto compute a Message Authentication Code (MAC) basedon the random key k the nonce Na received from Alice andanother nonce Nb locally generated Next in Step (3) Bobreplies to Alice exchanging his long-term public-key Pkb hisown nonce Nb and the computed MAC so that in Step (4)Alice can perform equivalent steps at her side and verify thereceived MAC and that Bob computed the same HIMMO keykHIMMOba and therefore verify Bobrsquos public-key Furthermore

Bob also sends the session key k to Alice encrypted usingher public-key

After decrypting and recovering the random key k Al-

ice independently regenerates kHIMMOba by using non-secret

HIMMO helper data sent to her by Bob to reconcile any smalldifference between her own and Bobrsquos computed HIMMOkeys Following this both Alice and Bob possess the samesymmetric HIMMO key kHIMMO

ba the same random key kand thereby the same session key kba Finally in Step (5)Alice sends her MAC to Bob so that he can verify Alicersquoslong-term public-key and the random key k in Step (6) NextAlice and Bob can proceed to communicate in a secure au-thenticated way in Step (7) using the final key kba createdby combining kHIMMO

ba and k to protect their communicationThe structure of this handshake can further be extended to

support more generic use-cases and advanced security proper-ties such as forward-secrecy via the use of ephemeral publickeys to transport the session key between Alice and BobTo illustrate this Appendix C depicts three embodiments ofthis handshake ndash a generic version with any suitable public-key key-establishment scheme PKE and key pre-distributionscheme KPS a version instantiated with the post-quantumNTRU key-exchange and with HIMMO and finally a finalversion instantiated with the forward-secure classic ECDHkey-agreement and with HIMMO as the KPS scheme

5 PROOF-OF-CONCEPT WITH TLS TLS-HIMMO

As a proof of concept we illustrate the above generic archi-tecture by instantiating it in the context of the TLS protocolWe use HIMMO in our proof of concept since it enablesefficient distribution of pairwise keys implicit verification ofcredentials and supports multiple TTPsroots of trust Wefurther use ECDH and NTRUEncrypt [24] as the pre- andpost-quantum cryptographic primitives for key-establishmentand ECDSA as the pre-quantum cryptographic primitive forauthentication

Client Server

1 ClientHello = Ciphersuitesc + TTPListc1+ 2 ClientHellominusminusminusminusminusminusminusminusminusrarr

3 ServerHello = Ciphersuitess + TTPLists + 4 ServerHellolarrminusminusminusminusminusminusminusminusminusminus

5 kHIMMOcs HelperData = s1c(QshPks) +

s2c(QshPks) +

6 ClientKeyExchange =EClassicPks (ClassicS)|EQshPks

(CliS)

|HelperData27 ClientKeyExchangeminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarr

8 Decrypt ClassicS CliS

9 kHIMMOcs = s1s(QshPkc) + s2s(QshPkc) + +

HelperData

10 PMS3= Classic|CliS|kHIMMOcs 10 PMS = Classic|CliS|kHIMMO

cs 11 MasterSecret = PRF (PMS) 11 MasterSecret = PRF (PMS)

12Finishedaminusminusminusminusminusminusminusminusminusrarr13 Verify Finisheda

14Finishedblarrminusminusminusminusminusminusminusminusminus15 Verify Finishedb

16 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using MasterSecret 16 Application Data

1 List of supported HIMMO TTP IDs as per RFC 6066 [12]2 ClassicS CliS are the classic secret and client QSH (assuming [32]) secret respectively3 Pre-master Secret used to generate the TLS Master Secret by means of the TLS pseudo-random function PRF

Figure 3 TLS Handshake including the design proposed in this paper including negotiation of a common setof trusted TTPs and establishment of a confidential authenticated channel protected by a combination of aclassic secret a quantum-safe secret CliS and a quantum-safe HIMMO key The HIMMO key is created usinga combination of key materials obtained from multiple negotiated TTPs and the peerrsquos long-term public-keyideally quantum-resistant

Figure 3 shows the complete TLS handshake between aclient Client and a server Server extended with our designin Section 4 The required additions to support our exten-sions are not many and the main one refers to the capabilityof agreeing on a common set of roots of trust TTPs andagreeing on this type of their use For this we considerRFC 6066 [12] since it defines extensions to the ClientHelloand ServerHello messages in which supported certificationauthorities are exchanged We reuse this extension for ourpurposes as follows

If a client and server have registered with some HIMMOTTPs and obtained HIMMO key material as described in Sec-tion 4 then they exchange the identities of their supportedTTPs Thus in Step (1) of the handshake Client creates aClientHello message including its supported roots of trustie HIMMO TTPs as described in RFC 6066 [12] that isthen sent to Server in Step (2) In step (3) Server searchesfor a common set of HIMMO TTPs that it then includes inthe ServerHello message and sends back to Client in Step (4)If they agree on the usage of HIMMO TTPs they then ex-change certificates or public keys whose hashes are HIMMOidentifiers for which they already possess HIMMO key mate-rial If only classical ciphersuites are considered then suchcertificates correspond to classical primitives eg ECDSAthat are exchanged normally via the ClientCertificate and

ServerCertificate messages If post-quantum keys are sup-ported then an extension header in the ClientHello messageis used (as specified in the hybrid TLS handshake InternetDraft [32]) to exchange additional post-quantum public keysThe exchanged certificates or public keys and correspondingkey material associated to common TTPs allow Client andServer to independently generate pairwise HIMMO keys inSteps (5) and (9) (one key for each common TTP agreedupon) which they then use to independently derive the finalHIMMO key kHIMMO

cs by means of a pseudo-random functionof all previously generated HIMMO keys In the specificexample we describe in Figure 3 Client and Server use eachotherrsquos quantum-resistant public-key to generate kHIMMO

cs insteps (5) and (9) This offers stronger quantum-securityHowever classic public-keys may also be used for this purposeto ease widespread adoption Note that HIMMO requiresa key reconciliation step in which HelperData is exchangedfrom the client and server that we exchange via the Clien-tKeyExchange This is the only protocol field that wouldrequire standardization

To utilize the combined security of HIMMO the classicandor post-quantum key-establishment schemes the TLSMaster Secret used for protecting the TLS record layer iscomputed from a Pre-master secret PMS that is a combi-nation of the classical key Classic the post-quantum key

CliS and the HIMMO key kHIMMOcs This is similar to [32]

and [16] Since the HIMMO key kHIMMOcs is one of the in-

puts to the Master Secret in Steps (10) and (11) via thePre-master Secret PMS it ensures the confidentiality andauthentication of the messages exchanged in the record layerMost importantly it also implicitly verifies the certificatesand public keys of Client and Server since the Master Secretis used in the computation of a Message Authentication Codein the Finished message that both parties must indepen-dently compute exchange and verify (in steps (13) and (15))This MAC is thus bound to the kHIMMO

cs that both partiesindependently computed using the certificates of the otherparty and their own HIMMO key material and can there-fore be considered equal to the MACba exchanged as anauthentication token during the Secure Operation phase (seeFigure 2) The MACrsquos verification by Server and Client willfail unless they computed the right kHIMMO

cs using an authen-tic certificatepublic-key of the other party and proper keymaterial and its success automatically authenticates bothServer and Client to each other

Finally note that the above authentication using HIMMOcan be done using multiple TTPs while also being capableof forward-secrecy and non-repudiation (through the addedincorporation of standard digital signatures) Lawful in-terception use-cases would require the client and server toexclude the exchange of public keys during operation andthus rely only on HIMMO and multiple TTPs to provide aproper privacy trade-off

6 EVALUATIONIn this section we begin with an analysis of the security

provided by our hybrid architecture in Section 61 followedby a quantitative evaluation of its performance in Section 62Section 63 presents a qualitative discussion of the architec-turersquos contributions and quantitatively compares it with thestate of the art

61 Security AnalysisIn this subsection we look at our hybrid architecture and

analyze its security A core contribution of this architectureis imparting quantum-safe authentication and confidentialityto communication channels in a scalable and efficient man-ner The private information possessed by a party ie thesecret HIMMO key material plays a key part in this andmust therefore be securely allocated to the party beforehandSuch confidential distribution of HIMMO key material isachieved by the Enrollment phase as it allows parties toget their public keys certified by (multiple) root(s) of trustand securely receive key materials from them in a manneranalogous to traditional Public-Key Infrastructure Whileallocating a HIMMO key material to an enrolling party aroot of trust encrypts it using the recipient partyrsquos public-keybefore transmitting the key material to it thereby ensuringconfidentiality of the private key material Furthermore thetransmission of a cryptographically-secure hash of the keymaterial along with the actual key material itself allows itsintegrity to be checked by the recipient party Freshnessof the key material received by a party is also ensured andmessage-replay attacks are prevented by the transmission(and verification) of freshly-generated nonces A preventivemeasure against impersonators trying to enroll with the rootof trust is achieved by the use of encrypted nonces at thestart of Enrollment Finally we emphasize once again that

quantum-safe asymmetric cryptography should ideally beused during Enrollment to make sure that the key materialof enrolled parties remains confidential and to prevent re-covery of an enrolling partyrsquos secret HIMMO key materialby a quantum-capable attacker (leading to identity imper-sonation [1]) Using classic public-key cryptography sufficesonly for the short-term to ease widespread adoption

Next we discuss the security of the Secure Operation hand-shake between two parties Authentication of the two partiesrsquolong-term public keys is implicitly and mutually achievedby a successful agreement of the HIMMO key between theparties since it is derived from both the public keys of thecommunicating parties and their private HIMMO keying ma-terials Therefore a successful key agreement automaticallyverifies both partiesrsquo public keys to each other since thisagreement never works unless both parties perform this stepusing authentic certified public keys and proper HIMMOkey materials that have been cryptographically bound totheir certified public keys The same idea also preventsconventional attacks such as a Man-in-the-Middle (MITM)attack on the handshake between Alice and Bob since theauthentication involves both of their private key materialsand certified public keys (exchanged via verifiable certifi-cates) thus making it impossible for the attacker to eitherimpersonate Alice or Bob to the other party

The final key and therefore the actual communication be-tween the parties receives combined protection from bothHIMMO and public-key cryptography In [32] it is argued us-ing the Leftover Hash Lemma [26] that if a secret is composedof two other independent secrets an attacker cannot recoverthe combined secret as long as one of the constituent secretsis unknown to him As a result even if the attacker possessesquantum computing capabilities and is able to recover khe fails to learn the key kHIMMO

ba thus preventing him fromlearning the session key kba In [21] it has been shownthat all attacks on HIMMO found so far lead to lattice-basedcryptanalysis thereby HIMMO provides quantum-security toany scheme that uses keys derived using it Furthermore [20]explicitly contains an analysis of quantum-capable attacks onthe HIMMO scheme Thus the overall communication ben-efits from both classic- and quantum-secure confidentialityand authentication

The architecture is also flexible enough to incorporate addi-tional strong security properties such as forward-secrecy withminimal changes ndash such as using an ephemeral publicprivatekey-pair to transport the random key k between the com-municating parties during the Secure Operation phase (seeFigure 7 in Appendix C for an instantiation)

Finally we note that due to HIMMOrsquos use of multipleTTPs and consequently our architecturersquos use of multipleroots of trust the level of security can be increased n-fold(when using HIMMO key material obtained from n roots oftrust during the Enrollment phase) with almost no corre-sponding increase in computation or communication cost dueto the nature of HIMMOrsquos operation when using multipleTTPs Anything short of a total compromise of all roots oftrust would affect neither confidentiality nor authenticationas the final private HIMMO key material of the enrolledparties and therefore HIMMO symmetric keys generated bythem remain secret in turn ensuring that the final session orMaster secret and therefore the final communication channelalso remains secure

CiphersuiteHandshake time

(ms)Handshake size

(Bytes)

ECDHE ECDSA WITH AES 256 CBC SHA (nistp256) 491 3277

NTRU RSA WITH AES 256 CBC SHA (EES439EP1) 293 5381

ECDHE ECDSA WITH AES 256 CBC SHA HIMMO256 505 3330

NTRU RSA WITH AES 256 CBC SHA HIMMO256 316 5448

NTRU RSA WITH AES 256 CBC SHA HIMMO256 3 TTP 349 5640

Table 1 TLS performance for different ciphersuites including existing classical and hybrid post-quantumciphersuites extended with HIMMO key generation using key material bound with certified public keys asper our design (256-bit HIMMO key with a large security parameter t = 4000) Extensions using both single-TTP and multi-TTP HIMMO implementations are shown The Elliptic Curve key-exchange and signatureimplementations use the NIST P-256 curve providing 128-bits of security NTRUEncrypt key-exchange usethe NTRU parameter set EES439EP1 with a 608 byte public key at 128-bit security

62 Performance Evaluation amp BenchmarksTo validate our research we implement the protocol de-

scribed in Section 5 by extending the CyaSSL library andusing TLSv2 The TLS protocol is executed between twomachines within the same Local Area Network Each ma-chinePC uses Windows 7 Enterprise (64 bit) with an IntelCore i5-5300U 230 GHz Software was compiled for thex86_64 architecture with full optimization (Ox) using theMicrosoft Visual C compiler

Table 1 compares the performance of different TLS hand-shakes using pre- and post-quantum ciphersuites Pre-quantum ciphersuites use ECDHE ECDSA while post-quantumciphersuites rely on NTRU RSA (NTRU is used to encrypta secret that is exchanged the NTRU public-key is signedwith RSA) We compare them after adding HIMMO nextto them using a single TTP The HIMMO parameter b ischosen to be 32 Several HIMMO systems are used in parallelto obtain a 256 bit key The additional time or bandwidthconsumption is minimal while enabling the verification ofpublic keys and generation of a symmetric-secret Further-more the increase in running times of the TLS handshakefor the classic ECDHE ECDSA and the post-quantum ci-phersuite NTRU RSA when extended with HIMMO wherethe HIMMO key is computed from key material assigned bythree TTPs (as per the protocol in Section 5) is minimalEach TTP is managed by a different organization or has in-dependent locations thus preventing a single point of failureExtending the classical ECDHE ECDSA with a single-TTPHIMMO implementation results in a TLS handshake thatis slower by only 28 for the HIMMO security parametert = 4000 (505 ms for the extended ciphersuite as comparedto 491 ms for classic ECDHE+ECDSA) Note that this valueof t is quite conservative [21] the drop in speed of the TLShandshake is minimal by comparison For the post-quantumciphersuite NTRU RSA the increase in computation over-head is 78 for a single-TTP implementation (316 ms forthe single-TTP extended ciphersuite as compared to 293 msfor the original NTRU+RSA one) and 191 for a three-TTPimplementation (349 ms) both cases for t = 4000 A furtheroptimization is possible for the multiple-TTP implementa-tion instead of sequentially creating and combining threeHIMMO sub-keys it is possible to generate a single HIMMOkey after adding the coefficientscomponents of the key ma-terials obtained from different TTPs Once this optimizationis done we expect a timing similar to the usage of a single

of TTP irrespective of the number of TTPs used[21 17] present insights into the efficient lightweight per-

formance of HIMMO It is demonstrated that an increaseof the HIMMO security parameter t to a very high valuethat directly determines the dimension of the lattice thatneeds to be reduced in order to find a closeshort vector [21]still does not have a huge impact in the CPU needs whilebandwidth consumption remains practically constant andequal to a few bytes Memory increases but for applicationareas such as the Internet a storage requirement of a coupleof megabytes is affordable IoT applications have differentperformance criteria communication bandwidth energy con-sumption timing and memory For all of these HIMMO isoptimal By construction HIMMO has low communicationand energy needs since it is identity-based and since wirelesscommunication consumes most of the energy budget Timingis also optimal although key material size is on the high sideEven without optimizations memory is the least relevantcriteria IoT devices are getting bigger memories computersand phones have sufficient memory capabilities

63 Discussion amp ComparisonThe solution proposed in this paper exhibits advantageous

properties compared with other architectures as shown inTable 2 Firstly the usage of HIMMO to create the finalsession key that protects a secure channel between any pair ofdevices makes the operational communication link betweenthem quantum-resistant Secondly the use of an indepen-dent public-key cryptosystem ensures secure distributionof key material during the initial enrollment and preventseavesdropping by rogue TTPs during Secure Operation Thearchitecture supports multiple roots of trust (based onHIMMO TTPs) with low overhead ensuring that the systemremains secure even if individual roots of trust are compro-mised Operationally if a secure channel between partiesis established based on HIMMO only this results in a non-interactive method for key agreement and authenticationideal for IoT scenarios Together with the incorporationof multiple TTPs this configuration of our architecture (iebased on only HIMMO) provides a solid solution for use casesin which lawful interception of communication is requiredAt the same time this does not infringe upon the right toprivacy of legitimate communications since it would requirea unanimous cooperation among all TTPs involved in thecommunication preventing possible abuses of power

Supported Features Traditional PKI Kerberos KPS QSH-TLS [32] DTLS-HIMMO [19] This paper

Quantum-safe confidentiality Depends on PK Yes Yes Yes Yes Yes

Quantum-safe authentication Depends on PK Yes Yes No Yes Yes

Enrollment Secure in-band Out-of-band Out-of-band Secure in-band Out-of-band Secure in-band

Multiple roots of trust Yes (high overhead) No Yes Yes (high overhead) Yes Yes (low overhead)

Non-interactive operation No No Yes No Yes Yes

Forward-secrecy Yes No No Yes No Yes

Authentication overhead High (explicit High (online Low High (explicit Low Low

signature) interaction) (symmetric) signature) (symmetric) (symmetric)

Scalability High Medium Medium Medium High Higher

Table 2 Comparison of the hybrid infrastructure presented in this paper with existing security architecturesfor a number of security and operational features

Figure 4 Comparison of communication overhead in TLS authentication phase when using (a) HIMMO keygeneration-based authentication with one TTP (b) with two TTPs (c) with three TTPs (all using 256-bitHIMMO key with a large security parameter t = 4000) (d) XMSS with 82 bit security (e) NTRUMLS withparameter set 401 [23] and 112 bit security (f) classic ECDSA with the curve nistp256 Data exchanged forauthentication purposes when using our HIMMO-based solution amounts to only HIMMO helper data forkey reconciliation

Considering authentication a HIMMO key material as-signed to a node is bound to its public-key so that theHIMMO key material acts as the nodersquos implicit digital cer-tificate allowing a node to verify public parameters of otherdevices with very low overhead while supporting multipleroots of trust Upgrading to any public-key cryptosystem issimple through the use of the corresponding digital certifi-cate or public-key as the HIMMO identity

Thus the proposed architecture is highly scalable evenif an out-of-band channel is not available as is the case in theInternet and is applicable to a wide range of use cases In con-trast the hybrid TLS handshake in [32] focuses on traditionalInternet applications only and does not support authentica-tion by multiple roots of trust The DTLS-HIMMO work [19]addresses IoT use cases but lacks a solution for in-band en-rollment or the capability of providing forward-secrecy

Considering post-quantum authentication we quantify thegains of our solution by comparing it with two signature

schemes considered quantum-resistant namely XMSS [6]and NTRUMLS [23] XMSS with an h value equal to 8 (iethe height of the XMSS hash tree) allows creating at most 256signatures each approximately 2436 Bytes long and havinga signature verification time of 195 ms [15] NTRUMLSfor parameters 401 and 743 involve signatures of around853 and 1765 Bytes with verification times of 033 and 079ms respectively [15] We note that computationally theactual post-quantum authentication step in our solution iethe generation of the HIMMO symmetric key is 65 fasterthan that of XMSS (067 ms compared to XMSSrsquos 195 ms)and 15 faster than that of NTRUMLS (067 ms comparedto NTRUMLSrsquos 079 ms) considering the relatively secureNTRUMLS parameter set 743 and a high HIMMO securityparameter value of t = 4000

Furthermore Figure 4 compares the communication over-head during TLS authentication comparing the amount ofbytes exchanged by classic and existing post-quantum sig-

natures with that exchanged by the authentication in ourHIMMO-based solution Since this consists of only HIMMOhelper data as compared to full-fledged digital signatures inthe former case our solution has a strong advantage regard-ing communication overhead or signature sizes

Figure 4 also shows that even achieving higher securitythrough the use of multiple roots of trust (ie TTPs) comesat virtually no added cost since the size of the HIMMOhelper data exchanged between parties for key reconcilia-tion only grows logarithmically with the increase in numberof TTPs (ie roots of trust) and not linearly When a n-TTP implementation is used the final key is derived as acombination of n intermediate HIMMO keys each derivedfrom one key material instance (obtained from one root oftrust) with HIMMO parameters t and m However if theHIMMO parameter t is same for all intermediate key mate-rials then the final HIMMO key corresponds to a symbolicHIMMO key material with parameters t and nm The sizeu of the helper data for this HIMMO key would then beu = dlog2(4nmt + 1)e (see Appendix B) which essentiallygrows logarithmically with n For more details about the ex-act nature of HIMMO helper data that leads to this desirablebehavior see Appendix B

In comparison for traditional digital signatures such asXMSS and NTRUMLS (albeit quantum-resistant) to achievethe same increase in security usage of certifications frommultiple CAs is necessary This involves a linear growth ofcomputation overhead (key-pair generation signature gen-eration signature verification) as well as communicationoverhead (exchange of multiple signatures) with the numberof CAs involved Thus the main advantage of our approachrelates to the implicit verification of public keys thatinvolves minimal overhead even with stronger security con-ditions such as multiple roots of trust (see Section 62)

7 CONCLUSIONSWe presented a hybrid security architecture combining

public-key cryptography and key pre-distribution schemesWe chose HIMMO as the KPS instantiation since it is theonly known scheme that is both efficient and collusion- andquantum-resistant The hybrid architecture combines desir-able features of both worlds it is scalable supports secureenrollment and efficient support for multiple roots of trustDue to its non-interactive key agreement the scheme is idealfor use cases with strict timing constraints limited band-width or a tight energy budget as often encountered in theIoT The hybrid scheme also finds a broader application inthe Internet since it allows for efficient verification of pub-lic keys with minimal overhead while providing advancedfeatures such as forward-secrecy

The architecture can already be deployed to improve per-formance of Internet communications in todayrsquos pre-quantumworld while providing a path towards a quantum-resistantyet highly efficient Internet Our TLS proof-of-concept imple-mentation proves this by showing how existing non-quantumresistant communications based on ECC or quantum-safepublic keys such as NTRU public keys can be verified withan increased communication overhead of less than 1 andvery low computational overhead Due to the identity-basednature of the HIMMO scheme the exchanged amount ofdata and time required for key generation remain practicallyconstant even if the HIMMO security parameters are madeextremely large

8 REFERENCES[1] C Adams Impersonation Attack pages 596ndash596

Springer US Boston MA 2011

[2] E Alkim L Ducas T Poeppelmann and P SchwabePost-Quantum Key Exchange ndash A New Hope 2015Cryptology ePrint Archive Report 2015-1092

[3] M Bellare and P Rogaway Entity Authentication andKey Distribution pages 232ndash249 Springer BerlinHeidelberg Berlin Heidelberg 1994

[4] J Bos C Costello L Ducas I Mironov M NaehrigV Nikolaenko A Raghunathan and D Stebila FrodoTake off the ring practical quantum-secure keyexchange from lwe Cryptology ePrint Archive Report2016659 2016 httpeprintiacrorg2016659

[5] J Bos C Costello M Naehrig and D StebilaPost-quantum key exchange for the TLS protocol fromthe ring learning with errors problem 2014httpeprintiacrorg2014599

[6] J Buchmann E Dahmen and A Hulsing XMSS APractical Forward Secure Signature Scheme based onMinimal Security Assumptions 2011httpeprintiacrorg20151003

[7] D Butin S-L Gazdag and J Buchmann Real-worldpost-quantum digital signatures In Cyber Security andPrivacy pages 41ndash52 Springer 2015

[8] S Checkoway R Niederhagen A EverspaughM Green T Lange T Ristenpart D J BernsteinJ Maskiewicz H Shacham and M Fredrikson On thePractical Exploitability of Dual EC in TLSImplementations In 23rd USENIX Security Symposium(USENIX Security 14) pages 319ndash335 San Diego CAAug 2014 USENIX Association

[9] L Chen S Jordan Y-K Liu D Moody R PeraltaR Perlner and D Smith-Tone Report onPost-Quantum Cryptography NISTIR8105 2016httpcsrcnistgovpublicationsdraftsnistir-8105nistir 8105 draftpdf

[10] Y Chen Q Huang and Z ZhangSakai-ohgishi-kasahara identity-based non-interactivekey exchange revisited and more Cryptology ePrintArchive Report 2014310 2014httpeprintiacrorg2014310

[11] J Ding and D Schmidt Rainbow a new multivariablepolynomial signature scheme In Applied Cryptographyand Network Security pages 164ndash175 Springer 2005

[12] D Eastlake Transport Layer Security (TLS)Extensions Extension Definitions 2011 RFC6066

[13] P Eronen and H Tschofenig Pre-Shared KeyCiphersuites for Transport Layer Security (TLS) RFC4279 (Proposed Standard) Dec 2005

[14] ETSI TS 101 331 - V131 - Lawful Interception (LI)Requirements of Law Enforcement Agencies October2009httpsarchiveorgdetailsetsi ts 101 331 v010301

[15] ETSI GRQSC-001 - V111 - Quantum-SafeCryptography (QSC) Quantum-safe algorithmicframework July 2016httpwwwetsiorgdeliveretsi grQSC001 099001010101 60gr QSC001v010101ppdf

[16] S Fluhrer D McGrew and P Kampanakis AnExtension for Postquantum Security using PresharedKeys for IKEv2 2015

Client Server

1 ClientHello = Ciphersuitesc + TTPListc1+ 2 ClientHellominusminusminusminusminusminusminusminusminusrarr

3 ServerHello = Ciphersuitess + TTPLists + 4 ServerHellolarrminusminusminusminusminusminusminusminusminusminus

5 kHIMMOcs HelperData = s1c(QshPks) +

s2c(QshPks) +

6 ClientKeyExchange =EClassicPks (ClassicS)|EQshPks

(CliS)

|HelperData27 ClientKeyExchangeminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarr

8 Decrypt ClassicS CliS

9 kHIMMOcs = s1s(QshPkc) + s2s(QshPkc) + +

HelperData

10 PMS3= Classic|CliS|kHIMMOcs 10 PMS = Classic|CliS|kHIMMO

cs 11 MasterSecret = PRF (PMS) 11 MasterSecret = PRF (PMS)

12Finishedaminusminusminusminusminusminusminusminusminusrarr13 Verify Finisheda

14Finishedblarrminusminusminusminusminusminusminusminusminus15 Verify Finishedb

16 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using MasterSecret 16 Application Data

1 List of supported HIMMO TTP IDs as per RFC 6066 [12]2 ClassicS CliS are the classic secret and client QSH (assuming [32]) secret respectively3 Pre-master Secret used to generate the TLS Master Secret by means of the TLS pseudo-random function PRF

Figure 3 TLS Handshake including the design proposed in this paper including negotiation of a common setof trusted TTPs and establishment of a confidential authenticated channel protected by a combination of aclassic secret a quantum-safe secret CliS and a quantum-safe HIMMO key The HIMMO key is created usinga combination of key materials obtained from multiple negotiated TTPs and the peerrsquos long-term public-keyideally quantum-resistant

Figure 3 shows the complete TLS handshake between aclient Client and a server Server extended with our designin Section 4 The required additions to support our exten-sions are not many and the main one refers to the capabilityof agreeing on a common set of roots of trust TTPs andagreeing on this type of their use For this we considerRFC 6066 [12] since it defines extensions to the ClientHelloand ServerHello messages in which supported certificationauthorities are exchanged We reuse this extension for ourpurposes as follows

If a client and server have registered with some HIMMOTTPs and obtained HIMMO key material as described in Sec-tion 4 then they exchange the identities of their supportedTTPs Thus in Step (1) of the handshake Client creates aClientHello message including its supported roots of trustie HIMMO TTPs as described in RFC 6066 [12] that isthen sent to Server in Step (2) In step (3) Server searchesfor a common set of HIMMO TTPs that it then includes inthe ServerHello message and sends back to Client in Step (4)If they agree on the usage of HIMMO TTPs they then ex-change certificates or public keys whose hashes are HIMMOidentifiers for which they already possess HIMMO key mate-rial If only classical ciphersuites are considered then suchcertificates correspond to classical primitives eg ECDSAthat are exchanged normally via the ClientCertificate and

ServerCertificate messages If post-quantum keys are sup-ported then an extension header in the ClientHello messageis used (as specified in the hybrid TLS handshake InternetDraft [32]) to exchange additional post-quantum public keysThe exchanged certificates or public keys and correspondingkey material associated to common TTPs allow Client andServer to independently generate pairwise HIMMO keys inSteps (5) and (9) (one key for each common TTP agreedupon) which they then use to independently derive the finalHIMMO key kHIMMO

cs by means of a pseudo-random functionof all previously generated HIMMO keys In the specificexample we describe in Figure 3 Client and Server use eachotherrsquos quantum-resistant public-key to generate kHIMMO

cs insteps (5) and (9) This offers stronger quantum-securityHowever classic public-keys may also be used for this purposeto ease widespread adoption Note that HIMMO requiresa key reconciliation step in which HelperData is exchangedfrom the client and server that we exchange via the Clien-tKeyExchange This is the only protocol field that wouldrequire standardization

To utilize the combined security of HIMMO the classicandor post-quantum key-establishment schemes the TLSMaster Secret used for protecting the TLS record layer iscomputed from a Pre-master secret PMS that is a combi-nation of the classical key Classic the post-quantum key

CliS and the HIMMO key kHIMMOcs This is similar to [32]

and [16] Since the HIMMO key kHIMMOcs is one of the in-

puts to the Master Secret in Steps (10) and (11) via thePre-master Secret PMS it ensures the confidentiality andauthentication of the messages exchanged in the record layerMost importantly it also implicitly verifies the certificatesand public keys of Client and Server since the Master Secretis used in the computation of a Message Authentication Codein the Finished message that both parties must indepen-dently compute exchange and verify (in steps (13) and (15))This MAC is thus bound to the kHIMMO

cs that both partiesindependently computed using the certificates of the otherparty and their own HIMMO key material and can there-fore be considered equal to the MACba exchanged as anauthentication token during the Secure Operation phase (seeFigure 2) The MACrsquos verification by Server and Client willfail unless they computed the right kHIMMO

cs using an authen-tic certificatepublic-key of the other party and proper keymaterial and its success automatically authenticates bothServer and Client to each other

Finally note that the above authentication using HIMMOcan be done using multiple TTPs while also being capableof forward-secrecy and non-repudiation (through the addedincorporation of standard digital signatures) Lawful in-terception use-cases would require the client and server toexclude the exchange of public keys during operation andthus rely only on HIMMO and multiple TTPs to provide aproper privacy trade-off

6 EVALUATIONIn this section we begin with an analysis of the security

provided by our hybrid architecture in Section 61 followedby a quantitative evaluation of its performance in Section 62Section 63 presents a qualitative discussion of the architec-turersquos contributions and quantitatively compares it with thestate of the art

61 Security AnalysisIn this subsection we look at our hybrid architecture and

analyze its security A core contribution of this architectureis imparting quantum-safe authentication and confidentialityto communication channels in a scalable and efficient man-ner The private information possessed by a party ie thesecret HIMMO key material plays a key part in this andmust therefore be securely allocated to the party beforehandSuch confidential distribution of HIMMO key material isachieved by the Enrollment phase as it allows parties toget their public keys certified by (multiple) root(s) of trustand securely receive key materials from them in a manneranalogous to traditional Public-Key Infrastructure Whileallocating a HIMMO key material to an enrolling party aroot of trust encrypts it using the recipient partyrsquos public-keybefore transmitting the key material to it thereby ensuringconfidentiality of the private key material Furthermore thetransmission of a cryptographically-secure hash of the keymaterial along with the actual key material itself allows itsintegrity to be checked by the recipient party Freshnessof the key material received by a party is also ensured andmessage-replay attacks are prevented by the transmission(and verification) of freshly-generated nonces A preventivemeasure against impersonators trying to enroll with the rootof trust is achieved by the use of encrypted nonces at thestart of Enrollment Finally we emphasize once again that

quantum-safe asymmetric cryptography should ideally beused during Enrollment to make sure that the key materialof enrolled parties remains confidential and to prevent re-covery of an enrolling partyrsquos secret HIMMO key materialby a quantum-capable attacker (leading to identity imper-sonation [1]) Using classic public-key cryptography sufficesonly for the short-term to ease widespread adoption

Next we discuss the security of the Secure Operation hand-shake between two parties Authentication of the two partiesrsquolong-term public keys is implicitly and mutually achievedby a successful agreement of the HIMMO key between theparties since it is derived from both the public keys of thecommunicating parties and their private HIMMO keying ma-terials Therefore a successful key agreement automaticallyverifies both partiesrsquo public keys to each other since thisagreement never works unless both parties perform this stepusing authentic certified public keys and proper HIMMOkey materials that have been cryptographically bound totheir certified public keys The same idea also preventsconventional attacks such as a Man-in-the-Middle (MITM)attack on the handshake between Alice and Bob since theauthentication involves both of their private key materialsand certified public keys (exchanged via verifiable certifi-cates) thus making it impossible for the attacker to eitherimpersonate Alice or Bob to the other party

The final key and therefore the actual communication be-tween the parties receives combined protection from bothHIMMO and public-key cryptography In [32] it is argued us-ing the Leftover Hash Lemma [26] that if a secret is composedof two other independent secrets an attacker cannot recoverthe combined secret as long as one of the constituent secretsis unknown to him As a result even if the attacker possessesquantum computing capabilities and is able to recover khe fails to learn the key kHIMMO

ba thus preventing him fromlearning the session key kba In [21] it has been shownthat all attacks on HIMMO found so far lead to lattice-basedcryptanalysis thereby HIMMO provides quantum-security toany scheme that uses keys derived using it Furthermore [20]explicitly contains an analysis of quantum-capable attacks onthe HIMMO scheme Thus the overall communication ben-efits from both classic- and quantum-secure confidentialityand authentication

The architecture is also flexible enough to incorporate addi-tional strong security properties such as forward-secrecy withminimal changes ndash such as using an ephemeral publicprivatekey-pair to transport the random key k between the com-municating parties during the Secure Operation phase (seeFigure 7 in Appendix C for an instantiation)

Finally we note that due to HIMMOrsquos use of multipleTTPs and consequently our architecturersquos use of multipleroots of trust the level of security can be increased n-fold(when using HIMMO key material obtained from n roots oftrust during the Enrollment phase) with almost no corre-sponding increase in computation or communication cost dueto the nature of HIMMOrsquos operation when using multipleTTPs Anything short of a total compromise of all roots oftrust would affect neither confidentiality nor authenticationas the final private HIMMO key material of the enrolledparties and therefore HIMMO symmetric keys generated bythem remain secret in turn ensuring that the final session orMaster secret and therefore the final communication channelalso remains secure

CiphersuiteHandshake time

(ms)Handshake size

(Bytes)

ECDHE ECDSA WITH AES 256 CBC SHA (nistp256) 491 3277

NTRU RSA WITH AES 256 CBC SHA (EES439EP1) 293 5381

ECDHE ECDSA WITH AES 256 CBC SHA HIMMO256 505 3330

NTRU RSA WITH AES 256 CBC SHA HIMMO256 316 5448

NTRU RSA WITH AES 256 CBC SHA HIMMO256 3 TTP 349 5640

Table 1 TLS performance for different ciphersuites including existing classical and hybrid post-quantumciphersuites extended with HIMMO key generation using key material bound with certified public keys asper our design (256-bit HIMMO key with a large security parameter t = 4000) Extensions using both single-TTP and multi-TTP HIMMO implementations are shown The Elliptic Curve key-exchange and signatureimplementations use the NIST P-256 curve providing 128-bits of security NTRUEncrypt key-exchange usethe NTRU parameter set EES439EP1 with a 608 byte public key at 128-bit security

62 Performance Evaluation amp BenchmarksTo validate our research we implement the protocol de-

scribed in Section 5 by extending the CyaSSL library andusing TLSv2 The TLS protocol is executed between twomachines within the same Local Area Network Each ma-chinePC uses Windows 7 Enterprise (64 bit) with an IntelCore i5-5300U 230 GHz Software was compiled for thex86_64 architecture with full optimization (Ox) using theMicrosoft Visual C compiler

Table 1 compares the performance of different TLS hand-shakes using pre- and post-quantum ciphersuites Pre-quantum ciphersuites use ECDHE ECDSA while post-quantumciphersuites rely on NTRU RSA (NTRU is used to encrypta secret that is exchanged the NTRU public-key is signedwith RSA) We compare them after adding HIMMO nextto them using a single TTP The HIMMO parameter b ischosen to be 32 Several HIMMO systems are used in parallelto obtain a 256 bit key The additional time or bandwidthconsumption is minimal while enabling the verification ofpublic keys and generation of a symmetric-secret Further-more the increase in running times of the TLS handshakefor the classic ECDHE ECDSA and the post-quantum ci-phersuite NTRU RSA when extended with HIMMO wherethe HIMMO key is computed from key material assigned bythree TTPs (as per the protocol in Section 5) is minimalEach TTP is managed by a different organization or has in-dependent locations thus preventing a single point of failureExtending the classical ECDHE ECDSA with a single-TTPHIMMO implementation results in a TLS handshake thatis slower by only 28 for the HIMMO security parametert = 4000 (505 ms for the extended ciphersuite as comparedto 491 ms for classic ECDHE+ECDSA) Note that this valueof t is quite conservative [21] the drop in speed of the TLShandshake is minimal by comparison For the post-quantumciphersuite NTRU RSA the increase in computation over-head is 78 for a single-TTP implementation (316 ms forthe single-TTP extended ciphersuite as compared to 293 msfor the original NTRU+RSA one) and 191 for a three-TTPimplementation (349 ms) both cases for t = 4000 A furtheroptimization is possible for the multiple-TTP implementa-tion instead of sequentially creating and combining threeHIMMO sub-keys it is possible to generate a single HIMMOkey after adding the coefficientscomponents of the key ma-terials obtained from different TTPs Once this optimizationis done we expect a timing similar to the usage of a single

of TTP irrespective of the number of TTPs used[21 17] present insights into the efficient lightweight per-

formance of HIMMO It is demonstrated that an increaseof the HIMMO security parameter t to a very high valuethat directly determines the dimension of the lattice thatneeds to be reduced in order to find a closeshort vector [21]still does not have a huge impact in the CPU needs whilebandwidth consumption remains practically constant andequal to a few bytes Memory increases but for applicationareas such as the Internet a storage requirement of a coupleof megabytes is affordable IoT applications have differentperformance criteria communication bandwidth energy con-sumption timing and memory For all of these HIMMO isoptimal By construction HIMMO has low communicationand energy needs since it is identity-based and since wirelesscommunication consumes most of the energy budget Timingis also optimal although key material size is on the high sideEven without optimizations memory is the least relevantcriteria IoT devices are getting bigger memories computersand phones have sufficient memory capabilities

63 Discussion amp ComparisonThe solution proposed in this paper exhibits advantageous

properties compared with other architectures as shown inTable 2 Firstly the usage of HIMMO to create the finalsession key that protects a secure channel between any pair ofdevices makes the operational communication link betweenthem quantum-resistant Secondly the use of an indepen-dent public-key cryptosystem ensures secure distributionof key material during the initial enrollment and preventseavesdropping by rogue TTPs during Secure Operation Thearchitecture supports multiple roots of trust (based onHIMMO TTPs) with low overhead ensuring that the systemremains secure even if individual roots of trust are compro-mised Operationally if a secure channel between partiesis established based on HIMMO only this results in a non-interactive method for key agreement and authenticationideal for IoT scenarios Together with the incorporationof multiple TTPs this configuration of our architecture (iebased on only HIMMO) provides a solid solution for use casesin which lawful interception of communication is requiredAt the same time this does not infringe upon the right toprivacy of legitimate communications since it would requirea unanimous cooperation among all TTPs involved in thecommunication preventing possible abuses of power

Supported Features Traditional PKI Kerberos KPS QSH-TLS [32] DTLS-HIMMO [19] This paper

Quantum-safe confidentiality Depends on PK Yes Yes Yes Yes Yes

Quantum-safe authentication Depends on PK Yes Yes No Yes Yes

Enrollment Secure in-band Out-of-band Out-of-band Secure in-band Out-of-band Secure in-band

Multiple roots of trust Yes (high overhead) No Yes Yes (high overhead) Yes Yes (low overhead)

Non-interactive operation No No Yes No Yes Yes

Forward-secrecy Yes No No Yes No Yes

Authentication overhead High (explicit High (online Low High (explicit Low Low

signature) interaction) (symmetric) signature) (symmetric) (symmetric)

Scalability High Medium Medium Medium High Higher

Table 2 Comparison of the hybrid infrastructure presented in this paper with existing security architecturesfor a number of security and operational features

Figure 4 Comparison of communication overhead in TLS authentication phase when using (a) HIMMO keygeneration-based authentication with one TTP (b) with two TTPs (c) with three TTPs (all using 256-bitHIMMO key with a large security parameter t = 4000) (d) XMSS with 82 bit security (e) NTRUMLS withparameter set 401 [23] and 112 bit security (f) classic ECDSA with the curve nistp256 Data exchanged forauthentication purposes when using our HIMMO-based solution amounts to only HIMMO helper data forkey reconciliation

Considering authentication a HIMMO key material as-signed to a node is bound to its public-key so that theHIMMO key material acts as the nodersquos implicit digital cer-tificate allowing a node to verify public parameters of otherdevices with very low overhead while supporting multipleroots of trust Upgrading to any public-key cryptosystem issimple through the use of the corresponding digital certifi-cate or public-key as the HIMMO identity

Thus the proposed architecture is highly scalable evenif an out-of-band channel is not available as is the case in theInternet and is applicable to a wide range of use cases In con-trast the hybrid TLS handshake in [32] focuses on traditionalInternet applications only and does not support authentica-tion by multiple roots of trust The DTLS-HIMMO work [19]addresses IoT use cases but lacks a solution for in-band en-rollment or the capability of providing forward-secrecy

Considering post-quantum authentication we quantify thegains of our solution by comparing it with two signature

schemes considered quantum-resistant namely XMSS [6]and NTRUMLS [23] XMSS with an h value equal to 8 (iethe height of the XMSS hash tree) allows creating at most 256signatures each approximately 2436 Bytes long and havinga signature verification time of 195 ms [15] NTRUMLSfor parameters 401 and 743 involve signatures of around853 and 1765 Bytes with verification times of 033 and 079ms respectively [15] We note that computationally theactual post-quantum authentication step in our solution iethe generation of the HIMMO symmetric key is 65 fasterthan that of XMSS (067 ms compared to XMSSrsquos 195 ms)and 15 faster than that of NTRUMLS (067 ms comparedto NTRUMLSrsquos 079 ms) considering the relatively secureNTRUMLS parameter set 743 and a high HIMMO securityparameter value of t = 4000

Furthermore Figure 4 compares the communication over-head during TLS authentication comparing the amount ofbytes exchanged by classic and existing post-quantum sig-

natures with that exchanged by the authentication in ourHIMMO-based solution Since this consists of only HIMMOhelper data as compared to full-fledged digital signatures inthe former case our solution has a strong advantage regard-ing communication overhead or signature sizes

Figure 4 also shows that even achieving higher securitythrough the use of multiple roots of trust (ie TTPs) comesat virtually no added cost since the size of the HIMMOhelper data exchanged between parties for key reconcilia-tion only grows logarithmically with the increase in numberof TTPs (ie roots of trust) and not linearly When a n-TTP implementation is used the final key is derived as acombination of n intermediate HIMMO keys each derivedfrom one key material instance (obtained from one root oftrust) with HIMMO parameters t and m However if theHIMMO parameter t is same for all intermediate key mate-rials then the final HIMMO key corresponds to a symbolicHIMMO key material with parameters t and nm The sizeu of the helper data for this HIMMO key would then beu = dlog2(4nmt + 1)e (see Appendix B) which essentiallygrows logarithmically with n For more details about the ex-act nature of HIMMO helper data that leads to this desirablebehavior see Appendix B

In comparison for traditional digital signatures such asXMSS and NTRUMLS (albeit quantum-resistant) to achievethe same increase in security usage of certifications frommultiple CAs is necessary This involves a linear growth ofcomputation overhead (key-pair generation signature gen-eration signature verification) as well as communicationoverhead (exchange of multiple signatures) with the numberof CAs involved Thus the main advantage of our approachrelates to the implicit verification of public keys thatinvolves minimal overhead even with stronger security con-ditions such as multiple roots of trust (see Section 62)

7 CONCLUSIONSWe presented a hybrid security architecture combining

public-key cryptography and key pre-distribution schemesWe chose HIMMO as the KPS instantiation since it is theonly known scheme that is both efficient and collusion- andquantum-resistant The hybrid architecture combines desir-able features of both worlds it is scalable supports secureenrollment and efficient support for multiple roots of trustDue to its non-interactive key agreement the scheme is idealfor use cases with strict timing constraints limited band-width or a tight energy budget as often encountered in theIoT The hybrid scheme also finds a broader application inthe Internet since it allows for efficient verification of pub-lic keys with minimal overhead while providing advancedfeatures such as forward-secrecy

The architecture can already be deployed to improve per-formance of Internet communications in todayrsquos pre-quantumworld while providing a path towards a quantum-resistantyet highly efficient Internet Our TLS proof-of-concept imple-mentation proves this by showing how existing non-quantumresistant communications based on ECC or quantum-safepublic keys such as NTRU public keys can be verified withan increased communication overhead of less than 1 andvery low computational overhead Due to the identity-basednature of the HIMMO scheme the exchanged amount ofdata and time required for key generation remain practicallyconstant even if the HIMMO security parameters are madeextremely large

8 REFERENCES[1] C Adams Impersonation Attack pages 596ndash596

Springer US Boston MA 2011

[2] E Alkim L Ducas T Poeppelmann and P SchwabePost-Quantum Key Exchange ndash A New Hope 2015Cryptology ePrint Archive Report 2015-1092

[3] M Bellare and P Rogaway Entity Authentication andKey Distribution pages 232ndash249 Springer BerlinHeidelberg Berlin Heidelberg 1994

[4] J Bos C Costello L Ducas I Mironov M NaehrigV Nikolaenko A Raghunathan and D Stebila FrodoTake off the ring practical quantum-secure keyexchange from lwe Cryptology ePrint Archive Report2016659 2016 httpeprintiacrorg2016659

[5] J Bos C Costello M Naehrig and D StebilaPost-quantum key exchange for the TLS protocol fromthe ring learning with errors problem 2014httpeprintiacrorg2014599

[6] J Buchmann E Dahmen and A Hulsing XMSS APractical Forward Secure Signature Scheme based onMinimal Security Assumptions 2011httpeprintiacrorg20151003

[7] D Butin S-L Gazdag and J Buchmann Real-worldpost-quantum digital signatures In Cyber Security andPrivacy pages 41ndash52 Springer 2015

[8] S Checkoway R Niederhagen A EverspaughM Green T Lange T Ristenpart D J BernsteinJ Maskiewicz H Shacham and M Fredrikson On thePractical Exploitability of Dual EC in TLSImplementations In 23rd USENIX Security Symposium(USENIX Security 14) pages 319ndash335 San Diego CAAug 2014 USENIX Association

[9] L Chen S Jordan Y-K Liu D Moody R PeraltaR Perlner and D Smith-Tone Report onPost-Quantum Cryptography NISTIR8105 2016httpcsrcnistgovpublicationsdraftsnistir-8105nistir 8105 draftpdf

[10] Y Chen Q Huang and Z ZhangSakai-ohgishi-kasahara identity-based non-interactivekey exchange revisited and more Cryptology ePrintArchive Report 2014310 2014httpeprintiacrorg2014310

[11] J Ding and D Schmidt Rainbow a new multivariablepolynomial signature scheme In Applied Cryptographyand Network Security pages 164ndash175 Springer 2005

[12] D Eastlake Transport Layer Security (TLS)Extensions Extension Definitions 2011 RFC6066

[13] P Eronen and H Tschofenig Pre-Shared KeyCiphersuites for Transport Layer Security (TLS) RFC4279 (Proposed Standard) Dec 2005

[14] ETSI TS 101 331 - V131 - Lawful Interception (LI)Requirements of Law Enforcement Agencies October2009httpsarchiveorgdetailsetsi ts 101 331 v010301

[15] ETSI GRQSC-001 - V111 - Quantum-SafeCryptography (QSC) Quantum-safe algorithmicframework July 2016httpwwwetsiorgdeliveretsi grQSC001 099001010101 60gr QSC001v010101ppdf

[16] S Fluhrer D McGrew and P Kampanakis AnExtension for Postquantum Security using PresharedKeys for IKEv2 2015

CliS and the HIMMO key kHIMMOcs This is similar to [32]

and [16] Since the HIMMO key kHIMMOcs is one of the in-

puts to the Master Secret in Steps (10) and (11) via thePre-master Secret PMS it ensures the confidentiality andauthentication of the messages exchanged in the record layerMost importantly it also implicitly verifies the certificatesand public keys of Client and Server since the Master Secretis used in the computation of a Message Authentication Codein the Finished message that both parties must indepen-dently compute exchange and verify (in steps (13) and (15))This MAC is thus bound to the kHIMMO

cs that both partiesindependently computed using the certificates of the otherparty and their own HIMMO key material and can there-fore be considered equal to the MACba exchanged as anauthentication token during the Secure Operation phase (seeFigure 2) The MACrsquos verification by Server and Client willfail unless they computed the right kHIMMO

cs using an authen-tic certificatepublic-key of the other party and proper keymaterial and its success automatically authenticates bothServer and Client to each other

Finally note that the above authentication using HIMMOcan be done using multiple TTPs while also being capableof forward-secrecy and non-repudiation (through the addedincorporation of standard digital signatures) Lawful in-terception use-cases would require the client and server toexclude the exchange of public keys during operation andthus rely only on HIMMO and multiple TTPs to provide aproper privacy trade-off

6 EVALUATIONIn this section we begin with an analysis of the security

provided by our hybrid architecture in Section 61 followedby a quantitative evaluation of its performance in Section 62Section 63 presents a qualitative discussion of the architec-turersquos contributions and quantitatively compares it with thestate of the art

61 Security AnalysisIn this subsection we look at our hybrid architecture and

analyze its security A core contribution of this architectureis imparting quantum-safe authentication and confidentialityto communication channels in a scalable and efficient man-ner The private information possessed by a party ie thesecret HIMMO key material plays a key part in this andmust therefore be securely allocated to the party beforehandSuch confidential distribution of HIMMO key material isachieved by the Enrollment phase as it allows parties toget their public keys certified by (multiple) root(s) of trustand securely receive key materials from them in a manneranalogous to traditional Public-Key Infrastructure Whileallocating a HIMMO key material to an enrolling party aroot of trust encrypts it using the recipient partyrsquos public-keybefore transmitting the key material to it thereby ensuringconfidentiality of the private key material Furthermore thetransmission of a cryptographically-secure hash of the keymaterial along with the actual key material itself allows itsintegrity to be checked by the recipient party Freshnessof the key material received by a party is also ensured andmessage-replay attacks are prevented by the transmission(and verification) of freshly-generated nonces A preventivemeasure against impersonators trying to enroll with the rootof trust is achieved by the use of encrypted nonces at thestart of Enrollment Finally we emphasize once again that

quantum-safe asymmetric cryptography should ideally beused during Enrollment to make sure that the key materialof enrolled parties remains confidential and to prevent re-covery of an enrolling partyrsquos secret HIMMO key materialby a quantum-capable attacker (leading to identity imper-sonation [1]) Using classic public-key cryptography sufficesonly for the short-term to ease widespread adoption

Next we discuss the security of the Secure Operation hand-shake between two parties Authentication of the two partiesrsquolong-term public keys is implicitly and mutually achievedby a successful agreement of the HIMMO key between theparties since it is derived from both the public keys of thecommunicating parties and their private HIMMO keying ma-terials Therefore a successful key agreement automaticallyverifies both partiesrsquo public keys to each other since thisagreement never works unless both parties perform this stepusing authentic certified public keys and proper HIMMOkey materials that have been cryptographically bound totheir certified public keys The same idea also preventsconventional attacks such as a Man-in-the-Middle (MITM)attack on the handshake between Alice and Bob since theauthentication involves both of their private key materialsand certified public keys (exchanged via verifiable certifi-cates) thus making it impossible for the attacker to eitherimpersonate Alice or Bob to the other party

The final key and therefore the actual communication be-tween the parties receives combined protection from bothHIMMO and public-key cryptography In [32] it is argued us-ing the Leftover Hash Lemma [26] that if a secret is composedof two other independent secrets an attacker cannot recoverthe combined secret as long as one of the constituent secretsis unknown to him As a result even if the attacker possessesquantum computing capabilities and is able to recover khe fails to learn the key kHIMMO

ba thus preventing him fromlearning the session key kba In [21] it has been shownthat all attacks on HIMMO found so far lead to lattice-basedcryptanalysis thereby HIMMO provides quantum-security toany scheme that uses keys derived using it Furthermore [20]explicitly contains an analysis of quantum-capable attacks onthe HIMMO scheme Thus the overall communication ben-efits from both classic- and quantum-secure confidentialityand authentication

The architecture is also flexible enough to incorporate addi-tional strong security properties such as forward-secrecy withminimal changes ndash such as using an ephemeral publicprivatekey-pair to transport the random key k between the com-municating parties during the Secure Operation phase (seeFigure 7 in Appendix C for an instantiation)

Finally we note that due to HIMMOrsquos use of multipleTTPs and consequently our architecturersquos use of multipleroots of trust the level of security can be increased n-fold(when using HIMMO key material obtained from n roots oftrust during the Enrollment phase) with almost no corre-sponding increase in computation or communication cost dueto the nature of HIMMOrsquos operation when using multipleTTPs Anything short of a total compromise of all roots oftrust would affect neither confidentiality nor authenticationas the final private HIMMO key material of the enrolledparties and therefore HIMMO symmetric keys generated bythem remain secret in turn ensuring that the final session orMaster secret and therefore the final communication channelalso remains secure

CiphersuiteHandshake time

(ms)Handshake size

(Bytes)

ECDHE ECDSA WITH AES 256 CBC SHA (nistp256) 491 3277

NTRU RSA WITH AES 256 CBC SHA (EES439EP1) 293 5381

ECDHE ECDSA WITH AES 256 CBC SHA HIMMO256 505 3330

NTRU RSA WITH AES 256 CBC SHA HIMMO256 316 5448

NTRU RSA WITH AES 256 CBC SHA HIMMO256 3 TTP 349 5640

Table 1 TLS performance for different ciphersuites including existing classical and hybrid post-quantumciphersuites extended with HIMMO key generation using key material bound with certified public keys asper our design (256-bit HIMMO key with a large security parameter t = 4000) Extensions using both single-TTP and multi-TTP HIMMO implementations are shown The Elliptic Curve key-exchange and signatureimplementations use the NIST P-256 curve providing 128-bits of security NTRUEncrypt key-exchange usethe NTRU parameter set EES439EP1 with a 608 byte public key at 128-bit security

62 Performance Evaluation amp BenchmarksTo validate our research we implement the protocol de-

scribed in Section 5 by extending the CyaSSL library andusing TLSv2 The TLS protocol is executed between twomachines within the same Local Area Network Each ma-chinePC uses Windows 7 Enterprise (64 bit) with an IntelCore i5-5300U 230 GHz Software was compiled for thex86_64 architecture with full optimization (Ox) using theMicrosoft Visual C compiler

Table 1 compares the performance of different TLS hand-shakes using pre- and post-quantum ciphersuites Pre-quantum ciphersuites use ECDHE ECDSA while post-quantumciphersuites rely on NTRU RSA (NTRU is used to encrypta secret that is exchanged the NTRU public-key is signedwith RSA) We compare them after adding HIMMO nextto them using a single TTP The HIMMO parameter b ischosen to be 32 Several HIMMO systems are used in parallelto obtain a 256 bit key The additional time or bandwidthconsumption is minimal while enabling the verification ofpublic keys and generation of a symmetric-secret Further-more the increase in running times of the TLS handshakefor the classic ECDHE ECDSA and the post-quantum ci-phersuite NTRU RSA when extended with HIMMO wherethe HIMMO key is computed from key material assigned bythree TTPs (as per the protocol in Section 5) is minimalEach TTP is managed by a different organization or has in-dependent locations thus preventing a single point of failureExtending the classical ECDHE ECDSA with a single-TTPHIMMO implementation results in a TLS handshake thatis slower by only 28 for the HIMMO security parametert = 4000 (505 ms for the extended ciphersuite as comparedto 491 ms for classic ECDHE+ECDSA) Note that this valueof t is quite conservative [21] the drop in speed of the TLShandshake is minimal by comparison For the post-quantumciphersuite NTRU RSA the increase in computation over-head is 78 for a single-TTP implementation (316 ms forthe single-TTP extended ciphersuite as compared to 293 msfor the original NTRU+RSA one) and 191 for a three-TTPimplementation (349 ms) both cases for t = 4000 A furtheroptimization is possible for the multiple-TTP implementa-tion instead of sequentially creating and combining threeHIMMO sub-keys it is possible to generate a single HIMMOkey after adding the coefficientscomponents of the key ma-terials obtained from different TTPs Once this optimizationis done we expect a timing similar to the usage of a single

of TTP irrespective of the number of TTPs used[21 17] present insights into the efficient lightweight per-

formance of HIMMO It is demonstrated that an increaseof the HIMMO security parameter t to a very high valuethat directly determines the dimension of the lattice thatneeds to be reduced in order to find a closeshort vector [21]still does not have a huge impact in the CPU needs whilebandwidth consumption remains practically constant andequal to a few bytes Memory increases but for applicationareas such as the Internet a storage requirement of a coupleof megabytes is affordable IoT applications have differentperformance criteria communication bandwidth energy con-sumption timing and memory For all of these HIMMO isoptimal By construction HIMMO has low communicationand energy needs since it is identity-based and since wirelesscommunication consumes most of the energy budget Timingis also optimal although key material size is on the high sideEven without optimizations memory is the least relevantcriteria IoT devices are getting bigger memories computersand phones have sufficient memory capabilities

63 Discussion amp ComparisonThe solution proposed in this paper exhibits advantageous

properties compared with other architectures as shown inTable 2 Firstly the usage of HIMMO to create the finalsession key that protects a secure channel between any pair ofdevices makes the operational communication link betweenthem quantum-resistant Secondly the use of an indepen-dent public-key cryptosystem ensures secure distributionof key material during the initial enrollment and preventseavesdropping by rogue TTPs during Secure Operation Thearchitecture supports multiple roots of trust (based onHIMMO TTPs) with low overhead ensuring that the systemremains secure even if individual roots of trust are compro-mised Operationally if a secure channel between partiesis established based on HIMMO only this results in a non-interactive method for key agreement and authenticationideal for IoT scenarios Together with the incorporationof multiple TTPs this configuration of our architecture (iebased on only HIMMO) provides a solid solution for use casesin which lawful interception of communication is requiredAt the same time this does not infringe upon the right toprivacy of legitimate communications since it would requirea unanimous cooperation among all TTPs involved in thecommunication preventing possible abuses of power

Supported Features Traditional PKI Kerberos KPS QSH-TLS [32] DTLS-HIMMO [19] This paper

Quantum-safe confidentiality Depends on PK Yes Yes Yes Yes Yes

Quantum-safe authentication Depends on PK Yes Yes No Yes Yes

Enrollment Secure in-band Out-of-band Out-of-band Secure in-band Out-of-band Secure in-band

Multiple roots of trust Yes (high overhead) No Yes Yes (high overhead) Yes Yes (low overhead)

Non-interactive operation No No Yes No Yes Yes

Forward-secrecy Yes No No Yes No Yes

Authentication overhead High (explicit High (online Low High (explicit Low Low

signature) interaction) (symmetric) signature) (symmetric) (symmetric)

Scalability High Medium Medium Medium High Higher

Table 2 Comparison of the hybrid infrastructure presented in this paper with existing security architecturesfor a number of security and operational features

Figure 4 Comparison of communication overhead in TLS authentication phase when using (a) HIMMO keygeneration-based authentication with one TTP (b) with two TTPs (c) with three TTPs (all using 256-bitHIMMO key with a large security parameter t = 4000) (d) XMSS with 82 bit security (e) NTRUMLS withparameter set 401 [23] and 112 bit security (f) classic ECDSA with the curve nistp256 Data exchanged forauthentication purposes when using our HIMMO-based solution amounts to only HIMMO helper data forkey reconciliation

Considering authentication a HIMMO key material as-signed to a node is bound to its public-key so that theHIMMO key material acts as the nodersquos implicit digital cer-tificate allowing a node to verify public parameters of otherdevices with very low overhead while supporting multipleroots of trust Upgrading to any public-key cryptosystem issimple through the use of the corresponding digital certifi-cate or public-key as the HIMMO identity

Thus the proposed architecture is highly scalable evenif an out-of-band channel is not available as is the case in theInternet and is applicable to a wide range of use cases In con-trast the hybrid TLS handshake in [32] focuses on traditionalInternet applications only and does not support authentica-tion by multiple roots of trust The DTLS-HIMMO work [19]addresses IoT use cases but lacks a solution for in-band en-rollment or the capability of providing forward-secrecy

Considering post-quantum authentication we quantify thegains of our solution by comparing it with two signature

schemes considered quantum-resistant namely XMSS [6]and NTRUMLS [23] XMSS with an h value equal to 8 (iethe height of the XMSS hash tree) allows creating at most 256signatures each approximately 2436 Bytes long and havinga signature verification time of 195 ms [15] NTRUMLSfor parameters 401 and 743 involve signatures of around853 and 1765 Bytes with verification times of 033 and 079ms respectively [15] We note that computationally theactual post-quantum authentication step in our solution iethe generation of the HIMMO symmetric key is 65 fasterthan that of XMSS (067 ms compared to XMSSrsquos 195 ms)and 15 faster than that of NTRUMLS (067 ms comparedto NTRUMLSrsquos 079 ms) considering the relatively secureNTRUMLS parameter set 743 and a high HIMMO securityparameter value of t = 4000

Furthermore Figure 4 compares the communication over-head during TLS authentication comparing the amount ofbytes exchanged by classic and existing post-quantum sig-

natures with that exchanged by the authentication in ourHIMMO-based solution Since this consists of only HIMMOhelper data as compared to full-fledged digital signatures inthe former case our solution has a strong advantage regard-ing communication overhead or signature sizes

Figure 4 also shows that even achieving higher securitythrough the use of multiple roots of trust (ie TTPs) comesat virtually no added cost since the size of the HIMMOhelper data exchanged between parties for key reconcilia-tion only grows logarithmically with the increase in numberof TTPs (ie roots of trust) and not linearly When a n-TTP implementation is used the final key is derived as acombination of n intermediate HIMMO keys each derivedfrom one key material instance (obtained from one root oftrust) with HIMMO parameters t and m However if theHIMMO parameter t is same for all intermediate key mate-rials then the final HIMMO key corresponds to a symbolicHIMMO key material with parameters t and nm The sizeu of the helper data for this HIMMO key would then beu = dlog2(4nmt + 1)e (see Appendix B) which essentiallygrows logarithmically with n For more details about the ex-act nature of HIMMO helper data that leads to this desirablebehavior see Appendix B

In comparison for traditional digital signatures such asXMSS and NTRUMLS (albeit quantum-resistant) to achievethe same increase in security usage of certifications frommultiple CAs is necessary This involves a linear growth ofcomputation overhead (key-pair generation signature gen-eration signature verification) as well as communicationoverhead (exchange of multiple signatures) with the numberof CAs involved Thus the main advantage of our approachrelates to the implicit verification of public keys thatinvolves minimal overhead even with stronger security con-ditions such as multiple roots of trust (see Section 62)

7 CONCLUSIONSWe presented a hybrid security architecture combining

public-key cryptography and key pre-distribution schemesWe chose HIMMO as the KPS instantiation since it is theonly known scheme that is both efficient and collusion- andquantum-resistant The hybrid architecture combines desir-able features of both worlds it is scalable supports secureenrollment and efficient support for multiple roots of trustDue to its non-interactive key agreement the scheme is idealfor use cases with strict timing constraints limited band-width or a tight energy budget as often encountered in theIoT The hybrid scheme also finds a broader application inthe Internet since it allows for efficient verification of pub-lic keys with minimal overhead while providing advancedfeatures such as forward-secrecy

The architecture can already be deployed to improve per-formance of Internet communications in todayrsquos pre-quantumworld while providing a path towards a quantum-resistantyet highly efficient Internet Our TLS proof-of-concept imple-mentation proves this by showing how existing non-quantumresistant communications based on ECC or quantum-safepublic keys such as NTRU public keys can be verified withan increased communication overhead of less than 1 andvery low computational overhead Due to the identity-basednature of the HIMMO scheme the exchanged amount ofdata and time required for key generation remain practicallyconstant even if the HIMMO security parameters are madeextremely large

8 REFERENCES[1] C Adams Impersonation Attack pages 596ndash596

Springer US Boston MA 2011

[2] E Alkim L Ducas T Poeppelmann and P SchwabePost-Quantum Key Exchange ndash A New Hope 2015Cryptology ePrint Archive Report 2015-1092

[3] M Bellare and P Rogaway Entity Authentication andKey Distribution pages 232ndash249 Springer BerlinHeidelberg Berlin Heidelberg 1994

[4] J Bos C Costello L Ducas I Mironov M NaehrigV Nikolaenko A Raghunathan and D Stebila FrodoTake off the ring practical quantum-secure keyexchange from lwe Cryptology ePrint Archive Report2016659 2016 httpeprintiacrorg2016659

[5] J Bos C Costello M Naehrig and D StebilaPost-quantum key exchange for the TLS protocol fromthe ring learning with errors problem 2014httpeprintiacrorg2014599

[6] J Buchmann E Dahmen and A Hulsing XMSS APractical Forward Secure Signature Scheme based onMinimal Security Assumptions 2011httpeprintiacrorg20151003

[7] D Butin S-L Gazdag and J Buchmann Real-worldpost-quantum digital signatures In Cyber Security andPrivacy pages 41ndash52 Springer 2015

[8] S Checkoway R Niederhagen A EverspaughM Green T Lange T Ristenpart D J BernsteinJ Maskiewicz H Shacham and M Fredrikson On thePractical Exploitability of Dual EC in TLSImplementations In 23rd USENIX Security Symposium(USENIX Security 14) pages 319ndash335 San Diego CAAug 2014 USENIX Association

[9] L Chen S Jordan Y-K Liu D Moody R PeraltaR Perlner and D Smith-Tone Report onPost-Quantum Cryptography NISTIR8105 2016httpcsrcnistgovpublicationsdraftsnistir-8105nistir 8105 draftpdf

[10] Y Chen Q Huang and Z ZhangSakai-ohgishi-kasahara identity-based non-interactivekey exchange revisited and more Cryptology ePrintArchive Report 2014310 2014httpeprintiacrorg2014310

[11] J Ding and D Schmidt Rainbow a new multivariablepolynomial signature scheme In Applied Cryptographyand Network Security pages 164ndash175 Springer 2005

[12] D Eastlake Transport Layer Security (TLS)Extensions Extension Definitions 2011 RFC6066

[13] P Eronen and H Tschofenig Pre-Shared KeyCiphersuites for Transport Layer Security (TLS) RFC4279 (Proposed Standard) Dec 2005

[14] ETSI TS 101 331 - V131 - Lawful Interception (LI)Requirements of Law Enforcement Agencies October2009httpsarchiveorgdetailsetsi ts 101 331 v010301

[15] ETSI GRQSC-001 - V111 - Quantum-SafeCryptography (QSC) Quantum-safe algorithmicframework July 2016httpwwwetsiorgdeliveretsi grQSC001 099001010101 60gr QSC001v010101ppdf

[16] S Fluhrer D McGrew and P Kampanakis AnExtension for Postquantum Security using PresharedKeys for IKEv2 2015

CiphersuiteHandshake time

(ms)Handshake size

(Bytes)

ECDHE ECDSA WITH AES 256 CBC SHA (nistp256) 491 3277

NTRU RSA WITH AES 256 CBC SHA (EES439EP1) 293 5381

ECDHE ECDSA WITH AES 256 CBC SHA HIMMO256 505 3330

NTRU RSA WITH AES 256 CBC SHA HIMMO256 316 5448

NTRU RSA WITH AES 256 CBC SHA HIMMO256 3 TTP 349 5640

Table 1 TLS performance for different ciphersuites including existing classical and hybrid post-quantumciphersuites extended with HIMMO key generation using key material bound with certified public keys asper our design (256-bit HIMMO key with a large security parameter t = 4000) Extensions using both single-TTP and multi-TTP HIMMO implementations are shown The Elliptic Curve key-exchange and signatureimplementations use the NIST P-256 curve providing 128-bits of security NTRUEncrypt key-exchange usethe NTRU parameter set EES439EP1 with a 608 byte public key at 128-bit security

62 Performance Evaluation amp BenchmarksTo validate our research we implement the protocol de-

scribed in Section 5 by extending the CyaSSL library andusing TLSv2 The TLS protocol is executed between twomachines within the same Local Area Network Each ma-chinePC uses Windows 7 Enterprise (64 bit) with an IntelCore i5-5300U 230 GHz Software was compiled for thex86_64 architecture with full optimization (Ox) using theMicrosoft Visual C compiler

Table 1 compares the performance of different TLS hand-shakes using pre- and post-quantum ciphersuites Pre-quantum ciphersuites use ECDHE ECDSA while post-quantumciphersuites rely on NTRU RSA (NTRU is used to encrypta secret that is exchanged the NTRU public-key is signedwith RSA) We compare them after adding HIMMO nextto them using a single TTP The HIMMO parameter b ischosen to be 32 Several HIMMO systems are used in parallelto obtain a 256 bit key The additional time or bandwidthconsumption is minimal while enabling the verification ofpublic keys and generation of a symmetric-secret Further-more the increase in running times of the TLS handshakefor the classic ECDHE ECDSA and the post-quantum ci-phersuite NTRU RSA when extended with HIMMO wherethe HIMMO key is computed from key material assigned bythree TTPs (as per the protocol in Section 5) is minimalEach TTP is managed by a different organization or has in-dependent locations thus preventing a single point of failureExtending the classical ECDHE ECDSA with a single-TTPHIMMO implementation results in a TLS handshake thatis slower by only 28 for the HIMMO security parametert = 4000 (505 ms for the extended ciphersuite as comparedto 491 ms for classic ECDHE+ECDSA) Note that this valueof t is quite conservative [21] the drop in speed of the TLShandshake is minimal by comparison For the post-quantumciphersuite NTRU RSA the increase in computation over-head is 78 for a single-TTP implementation (316 ms forthe single-TTP extended ciphersuite as compared to 293 msfor the original NTRU+RSA one) and 191 for a three-TTPimplementation (349 ms) both cases for t = 4000 A furtheroptimization is possible for the multiple-TTP implementa-tion instead of sequentially creating and combining threeHIMMO sub-keys it is possible to generate a single HIMMOkey after adding the coefficientscomponents of the key ma-terials obtained from different TTPs Once this optimizationis done we expect a timing similar to the usage of a single

of TTP irrespective of the number of TTPs used[21 17] present insights into the efficient lightweight per-

formance of HIMMO It is demonstrated that an increaseof the HIMMO security parameter t to a very high valuethat directly determines the dimension of the lattice thatneeds to be reduced in order to find a closeshort vector [21]still does not have a huge impact in the CPU needs whilebandwidth consumption remains practically constant andequal to a few bytes Memory increases but for applicationareas such as the Internet a storage requirement of a coupleof megabytes is affordable IoT applications have differentperformance criteria communication bandwidth energy con-sumption timing and memory For all of these HIMMO isoptimal By construction HIMMO has low communicationand energy needs since it is identity-based and since wirelesscommunication consumes most of the energy budget Timingis also optimal although key material size is on the high sideEven without optimizations memory is the least relevantcriteria IoT devices are getting bigger memories computersand phones have sufficient memory capabilities

63 Discussion amp ComparisonThe solution proposed in this paper exhibits advantageous

properties compared with other architectures as shown inTable 2 Firstly the usage of HIMMO to create the finalsession key that protects a secure channel between any pair ofdevices makes the operational communication link betweenthem quantum-resistant Secondly the use of an indepen-dent public-key cryptosystem ensures secure distributionof key material during the initial enrollment and preventseavesdropping by rogue TTPs during Secure Operation Thearchitecture supports multiple roots of trust (based onHIMMO TTPs) with low overhead ensuring that the systemremains secure even if individual roots of trust are compro-mised Operationally if a secure channel between partiesis established based on HIMMO only this results in a non-interactive method for key agreement and authenticationideal for IoT scenarios Together with the incorporationof multiple TTPs this configuration of our architecture (iebased on only HIMMO) provides a solid solution for use casesin which lawful interception of communication is requiredAt the same time this does not infringe upon the right toprivacy of legitimate communications since it would requirea unanimous cooperation among all TTPs involved in thecommunication preventing possible abuses of power

Supported Features Traditional PKI Kerberos KPS QSH-TLS [32] DTLS-HIMMO [19] This paper

Quantum-safe confidentiality Depends on PK Yes Yes Yes Yes Yes

Quantum-safe authentication Depends on PK Yes Yes No Yes Yes

Enrollment Secure in-band Out-of-band Out-of-band Secure in-band Out-of-band Secure in-band

Multiple roots of trust Yes (high overhead) No Yes Yes (high overhead) Yes Yes (low overhead)

Non-interactive operation No No Yes No Yes Yes

Forward-secrecy Yes No No Yes No Yes

Authentication overhead High (explicit High (online Low High (explicit Low Low

signature) interaction) (symmetric) signature) (symmetric) (symmetric)

Scalability High Medium Medium Medium High Higher

Table 2 Comparison of the hybrid infrastructure presented in this paper with existing security architecturesfor a number of security and operational features

Figure 4 Comparison of communication overhead in TLS authentication phase when using (a) HIMMO keygeneration-based authentication with one TTP (b) with two TTPs (c) with three TTPs (all using 256-bitHIMMO key with a large security parameter t = 4000) (d) XMSS with 82 bit security (e) NTRUMLS withparameter set 401 [23] and 112 bit security (f) classic ECDSA with the curve nistp256 Data exchanged forauthentication purposes when using our HIMMO-based solution amounts to only HIMMO helper data forkey reconciliation

Considering authentication a HIMMO key material as-signed to a node is bound to its public-key so that theHIMMO key material acts as the nodersquos implicit digital cer-tificate allowing a node to verify public parameters of otherdevices with very low overhead while supporting multipleroots of trust Upgrading to any public-key cryptosystem issimple through the use of the corresponding digital certifi-cate or public-key as the HIMMO identity

Thus the proposed architecture is highly scalable evenif an out-of-band channel is not available as is the case in theInternet and is applicable to a wide range of use cases In con-trast the hybrid TLS handshake in [32] focuses on traditionalInternet applications only and does not support authentica-tion by multiple roots of trust The DTLS-HIMMO work [19]addresses IoT use cases but lacks a solution for in-band en-rollment or the capability of providing forward-secrecy

Considering post-quantum authentication we quantify thegains of our solution by comparing it with two signature

schemes considered quantum-resistant namely XMSS [6]and NTRUMLS [23] XMSS with an h value equal to 8 (iethe height of the XMSS hash tree) allows creating at most 256signatures each approximately 2436 Bytes long and havinga signature verification time of 195 ms [15] NTRUMLSfor parameters 401 and 743 involve signatures of around853 and 1765 Bytes with verification times of 033 and 079ms respectively [15] We note that computationally theactual post-quantum authentication step in our solution iethe generation of the HIMMO symmetric key is 65 fasterthan that of XMSS (067 ms compared to XMSSrsquos 195 ms)and 15 faster than that of NTRUMLS (067 ms comparedto NTRUMLSrsquos 079 ms) considering the relatively secureNTRUMLS parameter set 743 and a high HIMMO securityparameter value of t = 4000

Furthermore Figure 4 compares the communication over-head during TLS authentication comparing the amount ofbytes exchanged by classic and existing post-quantum sig-

natures with that exchanged by the authentication in ourHIMMO-based solution Since this consists of only HIMMOhelper data as compared to full-fledged digital signatures inthe former case our solution has a strong advantage regard-ing communication overhead or signature sizes

Figure 4 also shows that even achieving higher securitythrough the use of multiple roots of trust (ie TTPs) comesat virtually no added cost since the size of the HIMMOhelper data exchanged between parties for key reconcilia-tion only grows logarithmically with the increase in numberof TTPs (ie roots of trust) and not linearly When a n-TTP implementation is used the final key is derived as acombination of n intermediate HIMMO keys each derivedfrom one key material instance (obtained from one root oftrust) with HIMMO parameters t and m However if theHIMMO parameter t is same for all intermediate key mate-rials then the final HIMMO key corresponds to a symbolicHIMMO key material with parameters t and nm The sizeu of the helper data for this HIMMO key would then beu = dlog2(4nmt + 1)e (see Appendix B) which essentiallygrows logarithmically with n For more details about the ex-act nature of HIMMO helper data that leads to this desirablebehavior see Appendix B

In comparison for traditional digital signatures such asXMSS and NTRUMLS (albeit quantum-resistant) to achievethe same increase in security usage of certifications frommultiple CAs is necessary This involves a linear growth ofcomputation overhead (key-pair generation signature gen-eration signature verification) as well as communicationoverhead (exchange of multiple signatures) with the numberof CAs involved Thus the main advantage of our approachrelates to the implicit verification of public keys thatinvolves minimal overhead even with stronger security con-ditions such as multiple roots of trust (see Section 62)

7 CONCLUSIONSWe presented a hybrid security architecture combining

public-key cryptography and key pre-distribution schemesWe chose HIMMO as the KPS instantiation since it is theonly known scheme that is both efficient and collusion- andquantum-resistant The hybrid architecture combines desir-able features of both worlds it is scalable supports secureenrollment and efficient support for multiple roots of trustDue to its non-interactive key agreement the scheme is idealfor use cases with strict timing constraints limited band-width or a tight energy budget as often encountered in theIoT The hybrid scheme also finds a broader application inthe Internet since it allows for efficient verification of pub-lic keys with minimal overhead while providing advancedfeatures such as forward-secrecy

The architecture can already be deployed to improve per-formance of Internet communications in todayrsquos pre-quantumworld while providing a path towards a quantum-resistantyet highly efficient Internet Our TLS proof-of-concept imple-mentation proves this by showing how existing non-quantumresistant communications based on ECC or quantum-safepublic keys such as NTRU public keys can be verified withan increased communication overhead of less than 1 andvery low computational overhead Due to the identity-basednature of the HIMMO scheme the exchanged amount ofdata and time required for key generation remain practicallyconstant even if the HIMMO security parameters are madeextremely large

8 REFERENCES[1] C Adams Impersonation Attack pages 596ndash596

Springer US Boston MA 2011

[2] E Alkim L Ducas T Poeppelmann and P SchwabePost-Quantum Key Exchange ndash A New Hope 2015Cryptology ePrint Archive Report 2015-1092

[3] M Bellare and P Rogaway Entity Authentication andKey Distribution pages 232ndash249 Springer BerlinHeidelberg Berlin Heidelberg 1994

[4] J Bos C Costello L Ducas I Mironov M NaehrigV Nikolaenko A Raghunathan and D Stebila FrodoTake off the ring practical quantum-secure keyexchange from lwe Cryptology ePrint Archive Report2016659 2016 httpeprintiacrorg2016659

[5] J Bos C Costello M Naehrig and D StebilaPost-quantum key exchange for the TLS protocol fromthe ring learning with errors problem 2014httpeprintiacrorg2014599

[6] J Buchmann E Dahmen and A Hulsing XMSS APractical Forward Secure Signature Scheme based onMinimal Security Assumptions 2011httpeprintiacrorg20151003

[7] D Butin S-L Gazdag and J Buchmann Real-worldpost-quantum digital signatures In Cyber Security andPrivacy pages 41ndash52 Springer 2015

[8] S Checkoway R Niederhagen A EverspaughM Green T Lange T Ristenpart D J BernsteinJ Maskiewicz H Shacham and M Fredrikson On thePractical Exploitability of Dual EC in TLSImplementations In 23rd USENIX Security Symposium(USENIX Security 14) pages 319ndash335 San Diego CAAug 2014 USENIX Association

[9] L Chen S Jordan Y-K Liu D Moody R PeraltaR Perlner and D Smith-Tone Report onPost-Quantum Cryptography NISTIR8105 2016httpcsrcnistgovpublicationsdraftsnistir-8105nistir 8105 draftpdf

[10] Y Chen Q Huang and Z ZhangSakai-ohgishi-kasahara identity-based non-interactivekey exchange revisited and more Cryptology ePrintArchive Report 2014310 2014httpeprintiacrorg2014310

[11] J Ding and D Schmidt Rainbow a new multivariablepolynomial signature scheme In Applied Cryptographyand Network Security pages 164ndash175 Springer 2005

[12] D Eastlake Transport Layer Security (TLS)Extensions Extension Definitions 2011 RFC6066

[13] P Eronen and H Tschofenig Pre-Shared KeyCiphersuites for Transport Layer Security (TLS) RFC4279 (Proposed Standard) Dec 2005

[14] ETSI TS 101 331 - V131 - Lawful Interception (LI)Requirements of Law Enforcement Agencies October2009httpsarchiveorgdetailsetsi ts 101 331 v010301

[15] ETSI GRQSC-001 - V111 - Quantum-SafeCryptography (QSC) Quantum-safe algorithmicframework July 2016httpwwwetsiorgdeliveretsi grQSC001 099001010101 60gr QSC001v010101ppdf

[16] S Fluhrer D McGrew and P Kampanakis AnExtension for Postquantum Security using PresharedKeys for IKEv2 2015

Supported Features Traditional PKI Kerberos KPS QSH-TLS [32] DTLS-HIMMO [19] This paper

Quantum-safe confidentiality Depends on PK Yes Yes Yes Yes Yes

Quantum-safe authentication Depends on PK Yes Yes No Yes Yes

Enrollment Secure in-band Out-of-band Out-of-band Secure in-band Out-of-band Secure in-band

Multiple roots of trust Yes (high overhead) No Yes Yes (high overhead) Yes Yes (low overhead)

Non-interactive operation No No Yes No Yes Yes

Forward-secrecy Yes No No Yes No Yes

Authentication overhead High (explicit High (online Low High (explicit Low Low

signature) interaction) (symmetric) signature) (symmetric) (symmetric)

Scalability High Medium Medium Medium High Higher

Table 2 Comparison of the hybrid infrastructure presented in this paper with existing security architecturesfor a number of security and operational features

Figure 4 Comparison of communication overhead in TLS authentication phase when using (a) HIMMO keygeneration-based authentication with one TTP (b) with two TTPs (c) with three TTPs (all using 256-bitHIMMO key with a large security parameter t = 4000) (d) XMSS with 82 bit security (e) NTRUMLS withparameter set 401 [23] and 112 bit security (f) classic ECDSA with the curve nistp256 Data exchanged forauthentication purposes when using our HIMMO-based solution amounts to only HIMMO helper data forkey reconciliation

Considering authentication a HIMMO key material as-signed to a node is bound to its public-key so that theHIMMO key material acts as the nodersquos implicit digital cer-tificate allowing a node to verify public parameters of otherdevices with very low overhead while supporting multipleroots of trust Upgrading to any public-key cryptosystem issimple through the use of the corresponding digital certifi-cate or public-key as the HIMMO identity

Thus the proposed architecture is highly scalable evenif an out-of-band channel is not available as is the case in theInternet and is applicable to a wide range of use cases In con-trast the hybrid TLS handshake in [32] focuses on traditionalInternet applications only and does not support authentica-tion by multiple roots of trust The DTLS-HIMMO work [19]addresses IoT use cases but lacks a solution for in-band en-rollment or the capability of providing forward-secrecy

Considering post-quantum authentication we quantify thegains of our solution by comparing it with two signature

schemes considered quantum-resistant namely XMSS [6]and NTRUMLS [23] XMSS with an h value equal to 8 (iethe height of the XMSS hash tree) allows creating at most 256signatures each approximately 2436 Bytes long and havinga signature verification time of 195 ms [15] NTRUMLSfor parameters 401 and 743 involve signatures of around853 and 1765 Bytes with verification times of 033 and 079ms respectively [15] We note that computationally theactual post-quantum authentication step in our solution iethe generation of the HIMMO symmetric key is 65 fasterthan that of XMSS (067 ms compared to XMSSrsquos 195 ms)and 15 faster than that of NTRUMLS (067 ms comparedto NTRUMLSrsquos 079 ms) considering the relatively secureNTRUMLS parameter set 743 and a high HIMMO securityparameter value of t = 4000

Furthermore Figure 4 compares the communication over-head during TLS authentication comparing the amount ofbytes exchanged by classic and existing post-quantum sig-

natures with that exchanged by the authentication in ourHIMMO-based solution Since this consists of only HIMMOhelper data as compared to full-fledged digital signatures inthe former case our solution has a strong advantage regard-ing communication overhead or signature sizes

Figure 4 also shows that even achieving higher securitythrough the use of multiple roots of trust (ie TTPs) comesat virtually no added cost since the size of the HIMMOhelper data exchanged between parties for key reconcilia-tion only grows logarithmically with the increase in numberof TTPs (ie roots of trust) and not linearly When a n-TTP implementation is used the final key is derived as acombination of n intermediate HIMMO keys each derivedfrom one key material instance (obtained from one root oftrust) with HIMMO parameters t and m However if theHIMMO parameter t is same for all intermediate key mate-rials then the final HIMMO key corresponds to a symbolicHIMMO key material with parameters t and nm The sizeu of the helper data for this HIMMO key would then beu = dlog2(4nmt + 1)e (see Appendix B) which essentiallygrows logarithmically with n For more details about the ex-act nature of HIMMO helper data that leads to this desirablebehavior see Appendix B

In comparison for traditional digital signatures such asXMSS and NTRUMLS (albeit quantum-resistant) to achievethe same increase in security usage of certifications frommultiple CAs is necessary This involves a linear growth ofcomputation overhead (key-pair generation signature gen-eration signature verification) as well as communicationoverhead (exchange of multiple signatures) with the numberof CAs involved Thus the main advantage of our approachrelates to the implicit verification of public keys thatinvolves minimal overhead even with stronger security con-ditions such as multiple roots of trust (see Section 62)

7 CONCLUSIONSWe presented a hybrid security architecture combining

public-key cryptography and key pre-distribution schemesWe chose HIMMO as the KPS instantiation since it is theonly known scheme that is both efficient and collusion- andquantum-resistant The hybrid architecture combines desir-able features of both worlds it is scalable supports secureenrollment and efficient support for multiple roots of trustDue to its non-interactive key agreement the scheme is idealfor use cases with strict timing constraints limited band-width or a tight energy budget as often encountered in theIoT The hybrid scheme also finds a broader application inthe Internet since it allows for efficient verification of pub-lic keys with minimal overhead while providing advancedfeatures such as forward-secrecy

The architecture can already be deployed to improve per-formance of Internet communications in todayrsquos pre-quantumworld while providing a path towards a quantum-resistantyet highly efficient Internet Our TLS proof-of-concept imple-mentation proves this by showing how existing non-quantumresistant communications based on ECC or quantum-safepublic keys such as NTRU public keys can be verified withan increased communication overhead of less than 1 andvery low computational overhead Due to the identity-basednature of the HIMMO scheme the exchanged amount ofdata and time required for key generation remain practicallyconstant even if the HIMMO security parameters are madeextremely large

8 REFERENCES[1] C Adams Impersonation Attack pages 596ndash596

Springer US Boston MA 2011

[2] E Alkim L Ducas T Poeppelmann and P SchwabePost-Quantum Key Exchange ndash A New Hope 2015Cryptology ePrint Archive Report 2015-1092

[3] M Bellare and P Rogaway Entity Authentication andKey Distribution pages 232ndash249 Springer BerlinHeidelberg Berlin Heidelberg 1994

[4] J Bos C Costello L Ducas I Mironov M NaehrigV Nikolaenko A Raghunathan and D Stebila FrodoTake off the ring practical quantum-secure keyexchange from lwe Cryptology ePrint Archive Report2016659 2016 httpeprintiacrorg2016659

[5] J Bos C Costello M Naehrig and D StebilaPost-quantum key exchange for the TLS protocol fromthe ring learning with errors problem 2014httpeprintiacrorg2014599

[6] J Buchmann E Dahmen and A Hulsing XMSS APractical Forward Secure Signature Scheme based onMinimal Security Assumptions 2011httpeprintiacrorg20151003

[7] D Butin S-L Gazdag and J Buchmann Real-worldpost-quantum digital signatures In Cyber Security andPrivacy pages 41ndash52 Springer 2015

[8] S Checkoway R Niederhagen A EverspaughM Green T Lange T Ristenpart D J BernsteinJ Maskiewicz H Shacham and M Fredrikson On thePractical Exploitability of Dual EC in TLSImplementations In 23rd USENIX Security Symposium(USENIX Security 14) pages 319ndash335 San Diego CAAug 2014 USENIX Association

[9] L Chen S Jordan Y-K Liu D Moody R PeraltaR Perlner and D Smith-Tone Report onPost-Quantum Cryptography NISTIR8105 2016httpcsrcnistgovpublicationsdraftsnistir-8105nistir 8105 draftpdf

[10] Y Chen Q Huang and Z ZhangSakai-ohgishi-kasahara identity-based non-interactivekey exchange revisited and more Cryptology ePrintArchive Report 2014310 2014httpeprintiacrorg2014310

[11] J Ding and D Schmidt Rainbow a new multivariablepolynomial signature scheme In Applied Cryptographyand Network Security pages 164ndash175 Springer 2005

[12] D Eastlake Transport Layer Security (TLS)Extensions Extension Definitions 2011 RFC6066

[13] P Eronen and H Tschofenig Pre-Shared KeyCiphersuites for Transport Layer Security (TLS) RFC4279 (Proposed Standard) Dec 2005

[14] ETSI TS 101 331 - V131 - Lawful Interception (LI)Requirements of Law Enforcement Agencies October2009httpsarchiveorgdetailsetsi ts 101 331 v010301

[15] ETSI GRQSC-001 - V111 - Quantum-SafeCryptography (QSC) Quantum-safe algorithmicframework July 2016httpwwwetsiorgdeliveretsi grQSC001 099001010101 60gr QSC001v010101ppdf

[16] S Fluhrer D McGrew and P Kampanakis AnExtension for Postquantum Security using PresharedKeys for IKEv2 2015

natures with that exchanged by the authentication in ourHIMMO-based solution Since this consists of only HIMMOhelper data as compared to full-fledged digital signatures inthe former case our solution has a strong advantage regard-ing communication overhead or signature sizes

Figure 4 also shows that even achieving higher securitythrough the use of multiple roots of trust (ie TTPs) comesat virtually no added cost since the size of the HIMMOhelper data exchanged between parties for key reconcilia-tion only grows logarithmically with the increase in numberof TTPs (ie roots of trust) and not linearly When a n-TTP implementation is used the final key is derived as acombination of n intermediate HIMMO keys each derivedfrom one key material instance (obtained from one root oftrust) with HIMMO parameters t and m However if theHIMMO parameter t is same for all intermediate key mate-rials then the final HIMMO key corresponds to a symbolicHIMMO key material with parameters t and nm The sizeu of the helper data for this HIMMO key would then beu = dlog2(4nmt + 1)e (see Appendix B) which essentiallygrows logarithmically with n For more details about the ex-act nature of HIMMO helper data that leads to this desirablebehavior see Appendix B

In comparison for traditional digital signatures such asXMSS and NTRUMLS (albeit quantum-resistant) to achievethe same increase in security usage of certifications frommultiple CAs is necessary This involves a linear growth ofcomputation overhead (key-pair generation signature gen-eration signature verification) as well as communicationoverhead (exchange of multiple signatures) with the numberof CAs involved Thus the main advantage of our approachrelates to the implicit verification of public keys thatinvolves minimal overhead even with stronger security con-ditions such as multiple roots of trust (see Section 62)

7 CONCLUSIONSWe presented a hybrid security architecture combining

public-key cryptography and key pre-distribution schemesWe chose HIMMO as the KPS instantiation since it is theonly known scheme that is both efficient and collusion- andquantum-resistant The hybrid architecture combines desir-able features of both worlds it is scalable supports secureenrollment and efficient support for multiple roots of trustDue to its non-interactive key agreement the scheme is idealfor use cases with strict timing constraints limited band-width or a tight energy budget as often encountered in theIoT The hybrid scheme also finds a broader application inthe Internet since it allows for efficient verification of pub-lic keys with minimal overhead while providing advancedfeatures such as forward-secrecy

The architecture can already be deployed to improve per-formance of Internet communications in todayrsquos pre-quantumworld while providing a path towards a quantum-resistantyet highly efficient Internet Our TLS proof-of-concept imple-mentation proves this by showing how existing non-quantumresistant communications based on ECC or quantum-safepublic keys such as NTRU public keys can be verified withan increased communication overhead of less than 1 andvery low computational overhead Due to the identity-basednature of the HIMMO scheme the exchanged amount ofdata and time required for key generation remain practicallyconstant even if the HIMMO security parameters are madeextremely large

8 REFERENCES[1] C Adams Impersonation Attack pages 596ndash596

Springer US Boston MA 2011

[2] E Alkim L Ducas T Poeppelmann and P SchwabePost-Quantum Key Exchange ndash A New Hope 2015Cryptology ePrint Archive Report 2015-1092

[3] M Bellare and P Rogaway Entity Authentication andKey Distribution pages 232ndash249 Springer BerlinHeidelberg Berlin Heidelberg 1994

[4] J Bos C Costello L Ducas I Mironov M NaehrigV Nikolaenko A Raghunathan and D Stebila FrodoTake off the ring practical quantum-secure keyexchange from lwe Cryptology ePrint Archive Report2016659 2016 httpeprintiacrorg2016659

[5] J Bos C Costello M Naehrig and D StebilaPost-quantum key exchange for the TLS protocol fromthe ring learning with errors problem 2014httpeprintiacrorg2014599

[6] J Buchmann E Dahmen and A Hulsing XMSS APractical Forward Secure Signature Scheme based onMinimal Security Assumptions 2011httpeprintiacrorg20151003

[7] D Butin S-L Gazdag and J Buchmann Real-worldpost-quantum digital signatures In Cyber Security andPrivacy pages 41ndash52 Springer 2015

[8] S Checkoway R Niederhagen A EverspaughM Green T Lange T Ristenpart D J BernsteinJ Maskiewicz H Shacham and M Fredrikson On thePractical Exploitability of Dual EC in TLSImplementations In 23rd USENIX Security Symposium(USENIX Security 14) pages 319ndash335 San Diego CAAug 2014 USENIX Association

[9] L Chen S Jordan Y-K Liu D Moody R PeraltaR Perlner and D Smith-Tone Report onPost-Quantum Cryptography NISTIR8105 2016httpcsrcnistgovpublicationsdraftsnistir-8105nistir 8105 draftpdf

[10] Y Chen Q Huang and Z ZhangSakai-ohgishi-kasahara identity-based non-interactivekey exchange revisited and more Cryptology ePrintArchive Report 2014310 2014httpeprintiacrorg2014310

[11] J Ding and D Schmidt Rainbow a new multivariablepolynomial signature scheme In Applied Cryptographyand Network Security pages 164ndash175 Springer 2005

[12] D Eastlake Transport Layer Security (TLS)Extensions Extension Definitions 2011 RFC6066

[13] P Eronen and H Tschofenig Pre-Shared KeyCiphersuites for Transport Layer Security (TLS) RFC4279 (Proposed Standard) Dec 2005

[14] ETSI TS 101 331 - V131 - Lawful Interception (LI)Requirements of Law Enforcement Agencies October2009httpsarchiveorgdetailsetsi ts 101 331 v010301

[15] ETSI GRQSC-001 - V111 - Quantum-SafeCryptography (QSC) Quantum-safe algorithmicframework July 2016httpwwwetsiorgdeliveretsi grQSC001 099001010101 60gr QSC001v010101ppdf

[16] S Fluhrer D McGrew and P Kampanakis AnExtension for Postquantum Security using PresharedKeys for IKEv2 2015

httpstoolsietforghtmldraft-fluhrer-qr-ikev2-00

[17] O Garcıa-Morchon D Gomez-Perez J GutierrezR Rietman B Schoenmakers and L TolhuizenHIMMO A Lightweight Collusion-Resistant KeyPredistribution Scheme 2015 Cryptology ePrintArchive Report 2014-698 Version of Aug 18 2015

[18] O Garcia-Morchon R Rietman S SharmaL Tolhuizen and J-L T Arce A comprehensive andlightweight security architecture to secure the IoTthroughout the lifecycle of a device based on HIMMO2015 NIST Ligthweight Cryptography Workshop July2021 2015httpcsrcnistgovgroupsSTlwc-workshop2015paperssession8-garcia-morchon-paperpdf

[19] O Garcia-Morchon R Rietman S SharmaL Tolhuizen and J-L T Arce DTLS-HIMMOAchieving DTLS Certificate Security with SymmetricKey Overhead In Computer Security ndash ESORICS 2015volume 9326 of Lecture Notes in Computer Sciencepages 224ndash242 2015

[20] O Garcia-Morchon R Rietman I Shparlinski andL Tolhuizen Results on polynomial interpolation withmixed modular operations and unknown moduliCryptology ePrint Archive Report 20151003 2015httpeprintiacrorg20151003

[21] O Garcıa-Morchon R Rietman L TolhuizenJ Torre-Arce M Lee D Gomez-Perez J Gutierrezand B Schoenmakers Attacks and parameter choicesin HIMMO 2016 Cryptology ePrint Archive Report2016-152

[22] Gemalto Gemalto presents the findings of itsinvestigations 2015httpwwwgemaltocompressPagesGemalto presents

the findings of its investigations into the alleged

hacking of SIM card encryption keysaspx

[23] J Hoffstein J Pipher J Schanck J Silverman andW Whyte Transcript Secure Signatures Based onModular Lattices In M Mosca editor Post-QuantumCryptography volume 8772 of Lecture Notes inComputer Science pages 142ndash159 SpringerInternational Publishing 2014

[24] J Hoffstein J Pipher and J Silverman NTRU Aring-based public key cryptosystem In J Buhlereditor Algorithmic Number Theory volume 1423 ofLecture Notes in Computer Science pages 267ndash288Springer Berlin Heidelberg 1998

[25] IBM IBM AIX An executive guide to IBMrsquos strategyand roadmap for the AIX Operating System on PowerSystems An IBM White Paper Technical report IBMDecember 2015

[26] R Impagliazzo L A Levin and M LubyPseudo-random generation from one-way functions InProceedings of the Twenty-first Annual ACMSymposium on Theory of Computing STOC rsquo89 pages12ndash24 New York NY USA 1989 ACM

[27] J Kohl and C Neuman The Kerberos NetworkAuthentication Service (V5) 1993 RFC1510

[28] T Matsumoto and H Imai On the key predistributionsystem a practical solution to the key distributionproblem In C Pomerance editor Advances inCryptology ndash CRYPTOrsquo87 LNCS 293 pages 185ndash193Springer 1988

[29] R J McEliece A public-key cryptosystem based onalgebraic coding theory DSN progress report42(44)114ndash116 1978

[30] J Prins Diginotar certificate authority breachOperation Black Tulip September 2011 wwwenisaeuropaeumedianews-itemsoperation-black-tulip

[31] R Sakai K Ohgishi and M Kasahara Cryptosystemsbased on pairing In The 2000 Symposium onCryptography and Information Security OkinawaJapan pages 135ndash148 2000

[32] J Schanck W Whyte and Z Zhang Quantum-SafeHybrid (QSH) Ciphersuite for Transport Layer Security(TLS) version 13 IETF 2015httpstoolsietforghtmldraft-whyte-qsh-tls13-01

[33] M Scott Migrating SOK to a type-3 Pairing Technicalreport Miracl Labs October 2016

[34] P W Shor Polynomial-Time Algorithms for PrimeFactorization and Discrete Logarithms on a QuantumComputer SIAM J Comput 26(5)1484ndash1509October 1997

[35] C R Taylor C A Shue and N R Paul A deployablescada authentication technique for modern power gridsIn Energy Conference (ENERGYCON) 2014 IEEEInternational pages 696ndash702 May 2014

[36] R Thurlow RPC Remote Procedure Call ProtocolSpecification Version 2 RFC 5531 RFC Editor May2009 httpwwwrfc-editororgrfcrfc5531txt

APPENDIXA LIST OF ABBREVIATIONSPKI Public-Key InfrastructureKPS Key Pre-distributionECC Elliptic Curve CryptographyTLS Transport Layer SecurityECDH Elliptic Curve Diffie HellmanECDSA Elliptic Curve Digital Signature AlgorithmNIST National Institute of Standards and TechnologyETSI European Telecommunications Standards InstituteCA Certification AuthorityIoT Internet of ThingsTTP Trusted Third PartyKPS Key Pre-distributionMAC Message Authentication CodeKDC Key Distribution CenterIKEv2 Internet Key ExchangeHIMMO Hiding Information and Mixing Modular OperationsMITM Man-in-the-Middle

B HIMMOAlthough the body of this paper uses a simplified description

of HIMMO as introduced the Background section this appendixdetails HIMMO as described in [21] for the sake of completeness

For all integers x and all positive integers N we denote with〈x〉N the integer in the interval [0 N minus 1] that is equivalent to xmodulo N ie that differs an integer multiple of N A matrixA is denoted by a capital bold letter A vector v is denoted bya small bold letter HIMMO has several system parameters thatdetermine the security and performance of HIMMO viz b thekey length N an odd reduction integer (of bit length 3b) andintegers t and m We remark that t plays a key role both in thesecurity and performance of the system

As in any key pre-distribution scheme HIMMO relies on atleast a trusted third party (TTP) and several phases can bedistinguished during its operation

In the set-up phase the TTP given the system parameterssecretly and randomly generates the following root key material

bull For 1 le i le m a secret random integer qi st 〈qi〉2b =

〈N〉2b and N minus 22b le qi lt N

bull For 1 le i le m a secret random symmetric ttimes t matrix Ri

over Zqi

In the key material extraction phase the TTP provides

node x isin [0 2b)t

with a secret vector sx = 〈summi=1 〈xRi〉qi 〉N

A later phase comprises a key establishment protocol inwhich if node x wishes to communicate with node y it computesthe key sxy = 〈〈sxyT 〉N 〉2b and determines kxy =

lfloor sxy

2u

rfloorand

h = 〈sxy〉2u where u = dlog2(4mt+ 1)e Then node x sends hto node y Finally node y computes kxy from kyx and h aslfloor 〈kyx+λN〉

2b

2u

rfloorwhere λ = Nminus1(hminus kyx 2u

See [21] [17] for more detailsImplicit certification and verification of credentials is further

enabled on top of the HIMMO scheme since HIMMO is basedon identities A node that wants to register with the systemprovides the TTP with information to be certified eg devicetype manufacturing date etc We will call this the node certificateThe TTP which can also add further information to the nodersquoscertificate such as a unique node identifier or the issue date of thekey material and its expiration date can obtain a nodersquos shortidentity as xshort = H(certificate) where H is a public hashfunction The components in x can be obtained from the shortidentity as x[k] = H(xshort|k) where | indicates concatenationIn this way HIMMO does not only allow for the direct secureexchange of a message M but also for implicit certification andverification of xrsquos credentials because the key material assigned toa node is linked to its certificate by means of H If the output sizeof H is long enough eg 256 bits the input (ie the certificate)contains a unique node identifier and if H is a secure one-way

hash function then it is infeasible for an attacker to find any otherset of information leading to the same identity x

Using multiple TTPs was introduced by Matsumoto and Imai [28]for KPS and can also be elegantly supported by HIMMO [21] [17]In this set-up a number of TTPs provides a node with key materiallinked to the nodersquos identifier during the key material extractionphase Upon reception the device combines the different keymaterial by adding the coefficients of the key generating functionsmodulo N Without increasing the resource requirements at thenodes this scheme enjoys two interesting properties First privacyis enhanced since a single TTP cannot eavesdrop the communi-cation links In fact all TTPs should collude to monitor thecommunication links Secondly compromising a sub-set of TTPsdoes not break the overall system

C SECURE OPERATION INSTANTIATIONSFollowing the description of the Secure Operation step in Sec-

tion 43 we describe here three embodiments to demonstrate theflexibility of its design Figure 5 depicts a generic form with anysuitable public-key key-establishment and key pre-distributionscheme Figure 6 depicts one with NTRU and HIMMO and Fig-ure 7 depicts an instantiation with ephemeral ECDH and HIMMOIn the final embodiment a combination of ephemeral ECDH andHIMMO achieves key-establishment (achieving forward secrecyand quantum-safe confidentiality) while HIMMO key materialbound to static long-term ECDSA public keys achieves quantum-safe authentication

Alice Bob

Possesses asymmetric key-pair Pka Ska forscheme PKE and secret KPS key materialsa(x) bound to Pka

Possesses asymmetric key-pair Pkb Skb forscheme PKE and secret KPS key materialsb(x) bound to Pkb

1 Pka Naminusminusminusminusminusminusminusrarr2 kKPS

ba ReconciliationData = sb(Pka)

Create key k randomly

kba = KDF (kKPSba k)

MACba = MACkba(k|Nb|Na)3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminus

EPka (k) ReconciliationData

4 Decrypt k

kKPSba = sa(Pkb) + ReconciliationData

kba = KDF (kKPSba k)

Verify MACba using kba

MACab = MACkba(k|Na|Nb)5 MACabminusminusminusminusminusminusminusrarr

6 Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 5 Secure Operation for establishing a confidential authenticated channel between two parties Aliceand Bob Authentication is achieved by using key material (corresponding to any suitable quantum-safe keypre-distribution scheme KPS) bound to long-term certified public keys (corresponding to any suitable public-key key establishment scheme PKE) Confidentiality is achieved using a combination of a key establishedusing KPS and another established using PKE

Alice Bob

Possesses NTRU key-pair Pka Ska and secretHIMMO key material sa(x) bound to Pka

Possesses NTRU key-pair Pkb Skb and secretHIMMO key material sb(x) bound to Pkb

1 Pka Naminusminusminusminusminusminusminusrarr2 kHIMMO

ba HelperData = sb(Pka)

Create key k randomly

kba = KDF (kHIMMOba k)

MACba = MACkba(k|Nb|Na)3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusEPka (k) HelperData

4 Decrypt k

kHIMMOba = sa(Pkb) + HelperData

kba = KDF (kHIMMOba k)

Verify MACba using kba

MACab = MACkba(k|Na|Nb)5 MACabminusminusminusminusminusminusminusrarr

6 Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 6 Secure Operation for establishing a confidential authenticated channel between two parties Aliceand Bob Authentication is achieved by using HIMMO key material bound to long-term certified NTRU [24]public keys Confidentiality is achieved using a combination of keys established using HIMMO and NTRU

Alice Bob

Possesses ECDH public parameters g p andsecret HIMMO key material sa(x) (bound tolong-term ECDSA public-key Pka)

Possesses ECDH public parameters g p andsecret HIMMO key material sb(x) (bound tolong-term ECDSA public-key Pkb)

1 Pka Naminusminusminusminusminusminusminusrarr2 kHIMMO

ba HelperData = sb(Pka)

Choose ephemeral random secret b

B = (gb) mod p3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminus

EkHIMMOba

(B) HelperData

4 kHIMMOba = sa(Pkb) + HelperData

Decrypt B

Choose ephemeral random secret a

A = (ga) mod p

kDH = (Ba) mod p

kab = KDF (kHIMMOba kDH)

MACab = MACkba(A|B|Na|Nb)5 E

kHIMMOba

(A) MACab

minusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarr6 Decrypt A

kDH = (Ab) mod p

kab = KDF (kHIMMOba kDH)

Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 7 Secure Operation for establishing a forward-secret confidential authenticated channel betweentwo parties Alice and Bob Authentication is achieved by using HIMMO key material bound to long-termstatic certified ECDSA public keys Confidentiality is achieved using a combination of keys established usingHIMMO and ephemeral ECDH thus providing forward-secrecy

• Introduction
• Background
• Goals amp Problem Statement
• • Attack Model
  • Design Goals
  • Problem Statement
  • • Design
    • • Roots of Trust in a PQ World
      • Enrollment amp Certification
      • Secure Operation
      • • Proof-of-Concept with TLS TLS-HIMMO
        • Evaluation
        • • Security Analysis
          • Performance Evaluation amp Benchmarks
          • Discussion amp Comparison
          • • Conclusions
            • References
            • List of Abbreviations
            • HIMMO
            • Secure Operation Instantiations

Alice Bob

Possesses asymmetric key-pair Pka Ska forscheme PKE and secret KPS key materialsa(x) bound to Pka

Possesses asymmetric key-pair Pkb Skb forscheme PKE and secret KPS key materialsb(x) bound to Pkb

1 Pka Naminusminusminusminusminusminusminusrarr2 kKPS

ba ReconciliationData = sb(Pka)

Create key k randomly

kba = KDF (kKPSba k)

MACba = MACkba(k|Nb|Na)3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminus

EPka (k) ReconciliationData

4 Decrypt k

kKPSba = sa(Pkb) + ReconciliationData

kba = KDF (kKPSba k)

Verify MACba using kba

MACab = MACkba(k|Na|Nb)5 MACabminusminusminusminusminusminusminusrarr

6 Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 5 Secure Operation for establishing a confidential authenticated channel between two parties Aliceand Bob Authentication is achieved by using key material (corresponding to any suitable quantum-safe keypre-distribution scheme KPS) bound to long-term certified public keys (corresponding to any suitable public-key key establishment scheme PKE) Confidentiality is achieved using a combination of a key establishedusing KPS and another established using PKE

Alice Bob

Possesses NTRU key-pair Pka Ska and secretHIMMO key material sa(x) bound to Pka

Possesses NTRU key-pair Pkb Skb and secretHIMMO key material sb(x) bound to Pkb

1 Pka Naminusminusminusminusminusminusminusrarr2 kHIMMO

ba HelperData = sb(Pka)

Create key k randomly

kba = KDF (kHIMMOba k)

MACba = MACkba(k|Nb|Na)3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusEPka (k) HelperData

4 Decrypt k

kHIMMOba = sa(Pkb) + HelperData

kba = KDF (kHIMMOba k)

Verify MACba using kba

MACab = MACkba(k|Na|Nb)5 MACabminusminusminusminusminusminusminusrarr

6 Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 6 Secure Operation for establishing a confidential authenticated channel between two parties Aliceand Bob Authentication is achieved by using HIMMO key material bound to long-term certified NTRU [24]public keys Confidentiality is achieved using a combination of keys established using HIMMO and NTRU

Alice Bob

Possesses ECDH public parameters g p andsecret HIMMO key material sa(x) (bound tolong-term ECDSA public-key Pka)

Possesses ECDH public parameters g p andsecret HIMMO key material sb(x) (bound tolong-term ECDSA public-key Pkb)

1 Pka Naminusminusminusminusminusminusminusrarr2 kHIMMO

ba HelperData = sb(Pka)

Choose ephemeral random secret b

B = (gb) mod p3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminus

EkHIMMOba

(B) HelperData

4 kHIMMOba = sa(Pkb) + HelperData

Decrypt B

Choose ephemeral random secret a

A = (ga) mod p

kDH = (Ba) mod p

kab = KDF (kHIMMOba kDH)

MACab = MACkba(A|B|Na|Nb)5 E

kHIMMOba

(A) MACab

minusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarr6 Decrypt A

kDH = (Ab) mod p

kab = KDF (kHIMMOba kDH)

Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 7 Secure Operation for establishing a forward-secret confidential authenticated channel betweentwo parties Alice and Bob Authentication is achieved by using HIMMO key material bound to long-termstatic certified ECDSA public keys Confidentiality is achieved using a combination of keys established usingHIMMO and ephemeral ECDH thus providing forward-secrecy

• Introduction
• Background
• Goals amp Problem Statement
• • Attack Model
  • Design Goals
  • Problem Statement
  • • Design
    • • Roots of Trust in a PQ World
      • Enrollment amp Certification
      • Secure Operation
      • • Proof-of-Concept with TLS TLS-HIMMO
        • Evaluation
        • • Security Analysis
          • Performance Evaluation amp Benchmarks
          • Discussion amp Comparison
          • • Conclusions
            • References
            • List of Abbreviations
            • HIMMO
            • Secure Operation Instantiations

Alice Bob

Possesses ECDH public parameters g p andsecret HIMMO key material sa(x) (bound tolong-term ECDSA public-key Pka)

Possesses ECDH public parameters g p andsecret HIMMO key material sb(x) (bound tolong-term ECDSA public-key Pkb)

1 Pka Naminusminusminusminusminusminusminusrarr2 kHIMMO

ba HelperData = sb(Pka)

Choose ephemeral random secret b

B = (gb) mod p3 Pkb Nb MACbalarrminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminus

EkHIMMOba

(B) HelperData

4 kHIMMOba = sa(Pkb) + HelperData

Decrypt B

Choose ephemeral random secret a

A = (ga) mod p

kDH = (Ba) mod p

kab = KDF (kHIMMOba kDH)

MACab = MACkba(A|B|Na|Nb)5 E

kHIMMOba

(A) MACab

minusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusminusrarr6 Decrypt A

kDH = (Ab) mod p

kab = KDF (kHIMMOba kDH)

Verify MACab

7 Application DatalarrminusminusminusminusminusminusminusminusminusminusminusminusrarrSecured using kba 7 Application Data

Figure 7 Secure Operation for establishing a forward-secret confidential authenticated channel betweentwo parties Alice and Bob Authentication is achieved by using HIMMO key material bound to long-termstatic certified ECDSA public keys Confidentiality is achieved using a combination of keys established usingHIMMO and ephemeral ECDH thus providing forward-secrecy

• Introduction
• Background
• Goals amp Problem Statement
• • Attack Model
  • Design Goals
  • Problem Statement
  • • Design
    • • Roots of Trust in a PQ World
      • Enrollment amp Certification
      • Secure Operation
      • • Proof-of-Concept with TLS TLS-HIMMO
        • Evaluation
        • • Security Analysis
          • Performance Evaluation amp Benchmarks
          • Discussion amp Comparison
          • • Conclusions
            • References
            • List of Abbreviations
            • HIMMO
            • Secure Operation Instantiations