Deniable Internet Key Exchange [chapter]

Andrew C. Yao, Yunlei Zhao
<span title="">2010</span> <i title="Springer Berlin Heidelberg"> <a target="_blank" rel="noopener" href="https://fatcat.wiki/container/2w3awgokqne6te4nvlofavy5a4" style="color: black;">Lecture Notes in Computer Science</a> </i> &nbsp;
In this work, we develop a family of protocols for deniable Internet Key-Exchange (IKE) with the following properties: • Highly practical efficiency, and conceptual simplicity and clarity. • Forward and concurrent (non-malleable) deniability against adversaries with arbitrary auxiliary inputs, and better privacy protection of players' roles. • Provable security in the Canetti-Krawczyk post-specified-peer model, and maintenance of essential security properties not captured by the
more &raquo; ... security model. • Compatibility with the widely deployed and standardized SIGMA (i.e., the basis of IKEv2) and (H)MQV protocols, when parties possess DL public-keys. Our protocols could potentially serve, in part, as either the underlying basis or a useful alternative for the next generation of IKE (i.e., IKEv3) of IPsec (in particular, when deniability is desired). In view of the wide deployment and use of IKE and increasing awareness of privacy protection (especially for E-commerce over Internet), this work is naturally of practical interest. Introduction Key-exchange (KE) is a traditional area of cryptography. But, key-exchange is also a quite special area of cryptography, in view of its seemingly simple yet error prone nature. Specifically, most key-exchange protocols seem to be very simple and even intuitive, and thus appearing to be easily designable, but the literature has been witnessing that the design of correct and secure KE turns out to be extremely error prone and could be notoriously subtle and difficult (the literature is filled with protocols that have been found to contain certain security flaws). The Internet Key-Exchange (IKE) protocols [16, 18], pioneered by Photuris [17], SKEME [20], Oakley [26] and SIGMA [21] , are the core cryptographic protocols to ensure Internet security, which specifies key exchange mechanisms used to establish shared keys for use in the Internet Protocol Security (IPsec) standards [19] . The IPsec and IKE are intended to protect messages communicated in the IP layer, i.e., "layer 3" of ISO-OSI, that processes the transmission of messages using the network addresses possibly without knowing end-user peers' identities. IKE and IPsec can in turn be used to offer confidentiality, authentication and privacy for communication protocols in the higher layers of ISO-OSI (note that many communication protocols including many authentication protocols which are invoked by end-users with explicit peer's identity information work at "layer 7" of ISO-OSI, i.e., the application layer) [24] . The standard of IKE has gone through two generations (versions). The first generation IKEv1 [16] uses public-key encryption as the authentication mechanism (with SKEME serving as the basis in part), 1 and IKEv2 [18] uses public-key signature as the authentication mechanism (with SIGMA serving as the basis in part). Several salient features of SIGMA helped make it adopted as the basis of IKEv2: (1) it works in the post-specified-peer ID model; (2) it provides identity concealment and plausible deniability; etc. Desirability for IKE with post-specified-peer ID [8] . Note that IPsec and IKE are intended to protect communication protocols in the IP layer that processes the transmission of messages using network addresses (rather than end-uses' IDs). This brings forth an issue: the peer's identity may be not available at the onset of the IKE, and may be learned by the party only after the protocol run evolves (even learning from the last message in a run of the protocol ). More specifically, in IKE a party may be activated to exchange a key with an "address" of a peer without knowing the identity of the peer. This is quite common in practical applications, in particular for IKE. For example, a key-exchange session may take place with any one of a set of servers sitting behind a (url/ip) address specified in the session activation. Furthermore, even for protocols running in the higher layers (e.g, the application layer), a party may respond to a key-exchange request coming from a peer who, for the sake of preserving its privacy, is not willing to reveal its identity over the network and, sometimes, not even to the responder before the latter has authenticated itself (e.g., a roaming mobile user connecting from a temporary address, or a smart-card that authenticates the legitimacy of the card-reader before disclosing its own identity). Such a general setting for IKE is referred to as "post-specified peer" model [8] . Desirability for deniable IKE [12, 24] . Deniable communication is an essential privacy property, and has always been a central concern in personal and business communications, with off-the-record communication serving as an essential social and political tool. Given that many of these interactions now happen over digital media (email, instant messaging, web transactions, virtual private networks), it is of critical importance to provide these communications with "off-the-record" or deniability capability: the sender of a message should be able to deny, e.g., in court, that he or she has sent that message. In general, we can just run a deniable authentication protocol for each message to be sent when deniability of the message is desired. However, the beauty of using deniable key-exchange is that if the key-exchange protocol is deniable, then all transactions using the session-key produced by the key-exchange protocol will be automatically deniable. In addition, offering deniability at the IP layer is desirable because it enables various privacy services to be offered at the higher layers with uncompromised quality. Note that a privacy problem at the IP layer can cause irreparable privacy damage at the application layer. For example, an identity connected to an IP address, if not deniable, certainly nullifies an anonymous property offered by a fancy cryptographic protocol running at the application level. A variant of the SIGMA protocol of [21] (i.e., the underlying basis of public-key IKEv2) has been proved to satisfy some plausible partial deniability assuming key-aware derivation (typically, with random oracle assumption of hash functions) [12] . On the desirability of forward and concurrent deniability. In the traditional definition of deniable authentication, sender Alice wants, in protecting her privacy, to prevent (possibly malicious) receiver Bob from proving to a third party that he has received a message from Alice by requiring that the protocol is actually a (computational) zero-knowledge (ZK) protocol in the sense that Bob's view can be simulated. Furthermore, we hope the ZK property holds against malicious Bob interacting with Alice concurrently in many sessions, i.e., the concurrent ZK (CZK) property [14] .
<span class="external-identifiers"> <a target="_blank" rel="external noopener noreferrer" href="https://doi.org/10.1007/978-3-642-13708-2_20">doi:10.1007/978-3-642-13708-2_20</a> <a target="_blank" rel="external noopener" href="https://fatcat.wiki/release/hqbabyc5f5avzkz75hd4j3utjy">fatcat:hqbabyc5f5avzkz75hd4j3utjy</a> </span>
<a target="_blank" rel="noopener" href="https://web.archive.org/web/20160908213800/http://eprint.iacr.org/2007/191.pdf" title="fulltext PDF download" data-goatcounter-click="serp-fulltext" data-goatcounter-title="serp-fulltext"> <button class="ui simple right pointing dropdown compact black labeled icon button serp-button"> <i class="icon ia-icon"></i> Web Archive [PDF] <div class="menu fulltext-thumbnail"> <img src="https://blobs.fatcat.wiki/thumbnail/pdf/a5/16/a516f0e1191ae12c31d9aa47758f363c5ee78f81.180px.jpg" alt="fulltext thumbnail" loading="lazy"> </div> </button> </a> <a target="_blank" rel="external noopener noreferrer" href="https://doi.org/10.1007/978-3-642-13708-2_20"> <button class="ui left aligned compact blue labeled icon button serp-button"> <i class="external alternate icon"></i> springer.com </button> </a>