Covert Channels in One-Time Passwords Based on Hash Chains

We present a covert channel between two network devices where one authenticates itself with Lamport's one-time passwords based on a cryptographic hash function. Our channel enables plausible deniability. We also present countermeasures to detect the presence of such a covert channel, which are non-trivial because hash values are randomly looking binary strings, so that deviations are not likely to be detected.


INTRODUCTION
Covert channels (CCs) are unforeseen communication channels in a system design. While first CCs for local computers were described in the 1970's (cf. [7]), research of recent decades discovered a plethora of new and sophisticated CCs that aid the secret exchange of information between hosts, databases, network hosts, and IoT devices. Due to their stealthy and policy-breaking nature, CCs enable several actions related to cybercrime, such as the secret extraction of confidential information, barely detectable botnet command & control channels, and unobservable communication for cybercriminals. While legitimate use cases are imaginable as well, e.g. journalists using CCs for secure exchange of dissident-related information, criminal use seems foremost, so that presentation of new CCs also serves presentation of countermeasures.
We present the first CC that exploits cryptographic hash chains, which have become popular because some form (block chain) is Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). EICC 2020, November 18, 2020, Rennes, France © 2020 Copyright held by the owner/author(s). ACM ISBN 978-1-4503-7599-3/20/11. . . $15.00 https://doi.org/10.1145/3424954.3424966 used in crypto currencies. Such CCs can be considered an example of plausible deniability: Alice communicates with Bob over the CC. Both can state that that every possible hash value is equally likely to occur. By modifying (alternating) bits of hash values, Alice and Bob can thus plausibly deny the existence of the CC. We also sketch possible countermeasures, which are non-trivial because hash values are randomly looking bit strings.

BACKGROUND
A hash function is a function ℎ : → that maps a possibly infinite universe, e.g. = {0, 1} ★ , onto a finite set of hash values, e.g. = {0, 1} [8]. A cryptographic hash function should have preimage resistance, i.e. from a hash value ∈ it is not possible (with reasonable effort) to compute a string ∈ such that ℎ( ) = , 2nd pre-image resistance, i.e. from a given with ℎ( ) = it is not possible to compute ′ ∈ , ′ ≠ such that ℎ( ′ ) = , and collision resistance, i.e. it is not possible to compute two strings , ′ ∈ , ′ ≠ such that ℎ( ) = ℎ( ′ ). As ⊂ , a hash function can be applied repeatedly, i.e. for a seed 0 = , we can compute +1 = ℎ( ) for = 0, 1, 2, . . . , − 1. This sequence is called a hash chain. While it is easy to compute a hash chain in forward direction, it cannot be computed in backward direction, starting from , because of the pre-image resistance property.
A one-time password (OTP) is a password only used once to authenticate an entity. As such, it is secure as long as it is secret and cannot be guessed prior to its use. Lamport [6] presented a scheme to generate OTPs from a hash function with pre-image resistance. Entity uses a random and secret seed to compute a hash chain 0 , . . . , , and transfers to entity via a secure channel. To authenticate, sends = −1 over an insecure channel to . checks if ℎ( ) = . If yes, the authentication is approved, and replaces by = −1 . If no, authentication has failed. For the next authentication, sends = −2 , and so on. Each password is only used once, and by the pre-image resistance, the next password cannot be guessed from the previous password. Also need not keep secret, as nothing can be inferred from this value. Haller's S/Key [5] and the TESLA protocol [9] use similar ideas.
A CC defines a parasitic communication channel nested inside a computing environment that allows at least two different legitimate processes (or nodes) to access a shared resource. The CC exploits the legitimate processes in a way that it allows the signaling of hidden information via the shared resource. The sender and receiver of a CC are called covert sender (CS) and covert receiver (CR), respectively. CS and CR are not necessarily identical with the overt sender and overt receiver (OS and OR) as CS and CR might act in an indirect manner or as man-in-the-middle. CCs inside computer networks follow a set of known hiding patterns [10] to transfer information, e.g. by placing secret data inside unused or reserved header bits of network packets, by modifying header fields with random values, or by modulating the timings between succeeding network packets.
Related Work: Plausible deniability for steganography was proposed by several authors, especially for filesystems (e.g. [2]). PRNGoutput was also applied for this purpose, e.g. in the context of video streams [4]. Abad [1] presents a CC in the check sum of IP packets, which however does not use a cryptographic hash function. Calhoun et al. [3] describe a CC in which OTPs are used as an element for generating random-data for a CC that exploits rate switching in 802.11b WiFi networks. In comparison, our approach allows an Internet-wide application that is not limited to wireless environments. Moreover does our approach represent an indirect CC based on hash chain exploitation. To the best of our knowledge, no other CC was published that exploits cryptographic hash chains.

COVERT CHANNELS IN HASH CHAINS
We present two variants of a CC that can be used in OTPs based on hash chains. We assume that each hash value is transmitted as part of network packets between and , so that a modification of the hash value can be hidden by re-computing the packet's check sum. In our scenario, CS is located close to (or on OS) and CR close to , i.e. both have at least indirect access to the communication between and .
Variant 1: The message that CS wants to send is broken into pieces of log 2 bits each (we assume to be a power of 2), i.e. represented as symbols over alphabet {0, 1, . . . , − 1}. To send a symbol , CS flips bit of the password that is going to be transmitted. CR, who knows the previous password +1 , intercepts the modified password ′ upon arrival and tests ′ with bit flipped, for = 0, 1, . . ., until a hash results in +1 . Then CR stores symbol and forwards the corrected password to . This is repeated until the complete message is transmitted (assuming that the number of pieces is less than , the length of the chain).
Variant 2: Here, CS only sends one bit with each transmitted password . To send a 1, bit 0 of the password is flipped. CR intercepts the possibly modified password ′ and checks if ℎ( ′ ) = +1 . If yes, then CR stores a 0, and forwards the password to . If no, then CR stores a 1, corrects the password by flipping bit 0, and forwards the corrected password to . This is repeated until the complete message is transmitted. Obviously, one is not restricted to always use bit 0. The bit that is possibly flipped can be decided depending on , synchronized timing events or other methods.
Both variants perform a manipulation of (pseudo-)random packet fields as described by the random value pattern [10]. Random value techniques have been implemented by several authors, rendering our proposed CC variants applicable in realistic environments.
Note that in both variants, CR needs no knowledge of stored by . In the first transmitted password −1 , no symbol is transmitted. Then CR knows −1 when intercepting and forwarding that password, and can refer to it later on, duplicating 's work.
Variant 1 can be detected more easily than variant 2 on the receiver side, as variant 1 on average encompasses /2 evaluations of ℎ, which is a notable amount of computation. This gives rise to intermediate forms where only ′ < bits can be used, i.e. the message is represented in symbols over alphabet {0, . . . , ′ − 1}. Parameter ′ will be chosen as large as possible, and as small as necessary to avoid detectability. In contrast, variant 1 provides higher steganographic bandwidth than variant 2.
On the sender side, both variants have very low effort and are thus hardly detectable. During transmission, an isolated packet will look innocent, as the one-time passwords look like random bitstrings, so that a possible bit flip is not likely to leave any trace or signature. Hence, detection during transmission seems non-trivial.

COUNTERMEASURES
Possible countermeasures against variant 1 on the receiver side have been described in the previous section. Countermeasures during transmission require that a warden has knowledge of two successive packets with passwords ′ and ′ −1 . In this case, the warden can check if ℎ( ′ −1 ) = ′ . If either password has been modified by CS, this equality will not hold because of the hash function's properties.
Another possible countermeasure would be that and modify the passwords themselves, in a way that is not foreseeable by CS or CR. When is about to send , it already has knowledge about the following password −1 . Let us assume that both and have knowledge of a hash function : {0, 1} → {0, 1}. If ( −1 ) = 0, then sends . If ( −1 ) = 1, then sends , i.e. with all bits inverted. If is a good hash function, then the second possibility will occur half of the time. If receives a password ′ , then it checks if either ℎ( ′ ) or ℎ( ′ ) equals +1 . In the latter case, stores ′ .
As only two instead of one password value will be accepted, this scheme is still secure. But life is now more complicated for CR. In variant 2, it cannot simply compare hash values, but must use all possible combinations of inverted and non-inverted passwords. More complicated schemes are possible. Even if they are not preventing this CC, they can restrict bandwidth and/or can increase detectability by forcing CR to perform more computation.

CONCLUSIONS
We have presented the first CC in hash chains, detailed different variants, and sketched non-trivial countermeasures against them. Instead of using network packets, the CCs could also use a local system to break a security policy if authenticates against over a shared medium that both, CS and CR, have access to under some timing constraints. Future work will comprise implementation and validation of the CC and the countermeasures.