A Non-interactive Dual-channel Authentication Protocol for Assuring Pseudo-confidentiality.

We introduce a non-interactive dual channel authentication protocol and apply it to long distance communication for assuring pseudo-confidentiality, a criteria that prevents a malicious agent from exfiltrating information to unauthorized destinations. Unlike previously proposed protocols that assume a manual (human-aided) or equivalent authenticated channel, our protocol utilizes a non-manual authenticated channel. We analyze the security properties for a possible realization of this protocol and develop a prototype. Through a Raspberry-Pi implementation, we show how the incorporation of the proposed scheme into the future design of keyboard interfaces may impact authentication practices. 1. Non-interactive dual channel authentication protocols Non-interactive dual channel authentication protocols employ two channels and authenticate information r1 received through one presumably insecure channel using a piece of brief information r2 (computed from r1) received through the other presumably authenticated channel. To remain lightweight these protocols employ one way communication from a message sender, Alice, to a message recipient, Bob. It can be shown that in these protocols, imposters cannot authenticate themselves if, (i) only one of the channels is compromised or (ii) both channels are compromised but attacks on them are not coordinated. Existing literature describes a family of non-interactive message authentication protocols (e.g., [1, 2, 4, 3, 5]), known as NIMAPs, that use a manual (human-aided) authenticated channel. In these protocols, a hash value for each message being sent is generated. Alice then transmits This work is supported by AFOSR Grants FA9550-09-1-0479 and FA 9550-09-1-0165. the message and hash over the insecure and authenticated channels respectively to Bob. In some protocols, a key is applied to the hash function when generating the hash value and this key is sent with the message over the insecure channel [3, 5] or with the hash value over the authenticated channel [2]. NIMAPs assume that the authenticated channel is human-aided hence adversarial influence on this channel is significantly limited. This assumption is sufficient for short distance communications requiring infrequent authentication of messages. However, this limits their application in long distance communications (e.g, over the internet) where frequent authentication is required and a human-aided authenticated channel is unrealistic and/or infeasible. 2. Proposed protocol Replacement of the human-aided authenticated channel in NIMAPs erodes the security benefit assured by such a channel. This exposes them (NIMAPs) to channel spoof attacks where an adversary, Eve, could spoof the identity of the authenticated channel when sending her authentication messages to Bob. Because of the non-interactive nature of Figure 1. Proposed protocol (Generic) the protocol, Bob has no way to know whether these authentications are sent by Alice hence, he will accept a message if its authentication is valid (i.e., it authenticates the message sent through the insecure channel). We address this issue by introducing the following: (i) we assign the task of Alice to a small hardware attachment that we assume not to be affected by a channel compromise, and (ii) we assume that it is difficult for the adversary, Eve to compute r2 given r1. Figure 1 presents the proposed generic protocol. In this protocol, Alice is a hardware attachment to the keyboard with the following properties: (i) She has processing capabilities to parse typed keystrokes and apply a method generate to identify r1 and to compute r2 from r1; (ii) She only receives input from the keyboard; (iii) She sends output to Bob using two different channels (one is insecure that runs through the host and the other is authenticated that bypasses the host). Bob is a verifier program located in a remote computer. In Figure 1 (and in subsequent protocol figures), the “′” added to information received by Bob indicates that the sent and received values might be different and the insecure and authenticated channels are represented by “→” and “⇒” respectively. The protocol is designed based on the following assumptions: (i) an r2 can verify the associated r1; (ii) an adversary can generate an r1 or snoop the r1 generated by Alice but it is difficult for her to compute the associated r2 from a given r1; (iii) Bob can compute r2 from r1; (iv) r′ 1 is accepted only if (r′ 1, r′ 2) is consistent i.e., r2b (the expected r′ 2 computed by Bob for the r′ 1 he received) is the same as r′ 2. Alice generates r1 and r2 from the keystrokes typed by a user and sends r1 through the possibly compromised host using the insecure channel and r2 directly to Bob using the authenticated channel. When Bob receives r1 and r2 from Alice, he accepts r′ 1 only if (r′ 1, r′ 2) is consistent. To defeat this protocol, Eve either; (i) waits for Alice to transmit an r1 and replaces r1 with r1eve and expects that it will be verified by the associated r2 (generated and transmitted by Alice), or; (ii) estimates an r2eve for her r1eve and transmits both of them to Bob pretending that the r2eve is transmitted over the authenticated channel (by spoofing the authenticated channel’s identity). Existing NIMAPs do not make assumption (ii), perhaps because of the challenge involved with its realization. Instead, they assume that Eve cannot successfully use (or masquerade to be using) the manual authenticated channel. These protocols can be defeated if the manual channel is replaced by a non-manual physical channel since Eve then can compute the right r2eve for her r1eve and masquerade as Alice. 3. A hash based realization for assuring pseudo-confidentiality The exfiltration of information by a malicious agent from a compromised host to an external adversary can be restricted by blocking all access from the host to unauthorized destinations. We refer to an authorized destination as a domain name/IP that: (i) has been typed at least once by a human user (establishing consent/approval), or (ii) has been returned in a response packet from an authorized destination. We define pseudo-confidentiality as the security property satisfied when an adversary cannot exfiltrate information to unauthorized destinations. Figure 2. Hash based realization A hash based realization of the proposed protocol assuring pseudo-confidentiality is shown in Figure 2. In this realization, the generate function used by Alice produces components rv and h. rv is the destination (IP/domain name) of a request being made and h = HK(rv) is the hashed value of the requested destination. This realization works in two phases as described below: (i) Initialization phase This is a one step setup process required prior to the establishment of the rest of the protocol. During this phase, a human operator (i) informs Bob of the functions H and Ĥ used by Alice and (ii) initializes a K for Alice and Bob. During the protocol phase, function H uses K as a parameter to produce h and function Ĥ is used to update K by both Alice and Bob. Due to some failure or interruption in communication, if Alice and Bob do not have the same updated K, all destination requests will be rejected and the value of K will have to be re-initialized. (ii) Protocol phase In this phase, components rv and h are transmitted from Alice to Bob via the insecure and authenticated channels respectively. When Bob receives both r′ v and h′, he computes his own h using his K i.e., h = HK(r v) and considers (r′ v, h ′) to be consistent if the received h′ = h. The value of K is updated by both Alice and Bob using another function Ĥ . Alice updates her K after sending h to Bob and Bob updates his K every time he receives an h′ #= ∅ from Alice and accepts r′ v . Ĥ(K) transforms the value of K based on the current value of K to produce a new K. During experimentation, we relax the definition of consistent by accepting requests to destinations that are (i) nontyped but had been authorized before and (ii) received in response to requests to authorized destinations, to improve the usability of the solution. Security Analysis Bob accepts r′ v if (r′ v, h) is consistent for the current K (that Bob has knowledge of). Bob can be made to accept a request from Eve in the following cases: Case 1: Channel spoof attack A malicious agent, Eve, residing in the host, can no longer launch a channel spoof attack simply by sending her own rv and h to Bob if the K she uses for computing h (at a certain instance) is not what Bob is expecting Alice to use. Since our assumption is that Eve has no knowledge of K, Alice can only expect that the K she is using matches with the K Bob is expecting. For an n-bit K, the probability of such a match is 2−n. Case 2: Second preimage Attack Eve can replace the destination rv generated by Alice with her own destination reve and expect that there exists a K ′′ such that H(rv,K) = H(reve,K ′′). A second preimage resistant hash function is relevant in our case because for a second preimage resistant hash function, given an input rv , it should be difficult for an adversary to find another input reve #= rv such that H(reve) = H(rv). If H is !s second preimage resistant (i.e., !s is the probability of H(reve) = H(rv) occurring), then the probability of a successful attack is !s.