Deploying OSK on Low-Resource Mobile Devices

Abstract

It is a popular challenge to design authentication protocols that are both privacy-friendly and scalable. A large body of literature in RFID is dedicated to that goal, and many inventive mechanisms have been suggested to achieve it. However, to the best of our knowledge, none of these protocols have been tested so far in practical scenarios. In this paper, we present an implementation of the OSK protocol, a scalable and privacy-friendly authentication protocol, using a variant by Avoine and Oechslin that accommodates it to time-memory trade-offs. We show that the OSK protocol is suited to certain real-life scenarios, in particular when the authentication is performed by low-resource mobile devices. The implementation, done on an NFC-compliant cellphone and a ZC7.5 contactless tag, demonstrates the practicability and efficiency of the OSK protocol and illustrates that privacy-by-design is achievable in constrained environments.

1 Introduction

A major research topic in RFID is the development of authentication protocols that respect the privacy of the users, while still being efficient enough to be applicable in large-scale systems. When the time needed by the authentication process is not negligible, the user must hold the card steady in front of the reader until reception of an audio or visual signal. Long authentication processes are not practical in access control systems where delaying the customer flow is not acceptable for example in mass transportation or cultural events. It is generally agreed upon that approximately 200 ms can be dedicated to grant or deny the access to a customer in a flow [10].

Classical challenge-response protocols such as ISO/IEC 9798-2.2 [14] can be privacy-friendly if the tag (prover) does not send its identifier in the clear to the reader (verifier). In such a case, the reader must find the tag identifier by performing an exhaustive search in its database. For example, in a system managing $2^{20}$ tags and a reader capable of performing $2^{20}$ cryptographic operations per second, the authentication of a tag takes half a second on average, which is beyond the time threshold that can be allocated to the security operations.

Several protocols have been designed to provide privacy in the authentication. An additional property, named forward privacy, ensures that if a tag is compromised at one point, an adversary is not able to trace it in the past (given past communication traces). An example of such a protocol is the OSK protocol, proposed by Ohkubo, Suzuki and Kinoshita in [20]. It may be regarded as one of the most privacy-friendly protocol among the ones that allow for an efficient authentication procedure based on symmetric-key cryptography [1].

An implementation of this protocol was previously done in [6]. It uses rainbow tables accommodated for OSK, as proposed by Avoine and Oechslin in [5]. However, we show in this paper that in the setting of [6], a faster and simpler approach is viable, namely the full storage. Instead, we focus on systems with low-resource mobile readers, such as PDA’s or NFC-compliant cellphones, and adapt this implementation to that context. We show that such a protocol with very good privacy properties is efficient enough to be used in practice, even in such constrained environments.

The structure of the paper is as follows. We present the OSK protocol in Sect. 2 and the adapted time-memory trade-off in Sect. 3. The method of Avoine and Oechslin for accommodating OSK for time-memory trade-offs is described in Sect. 4. We describe our implementation and discuss our results in Sect. 5. We finally conclude in Sect. 6.

2 Ohkubo, Suzuki, and Kinoshita’s Protocol

2.1 Description

The OSK protocol is proposed by Ohkubo, Suzuki, and Kinoshita in [20]. It is one of the most well-known RFID-devoted authentication protocols and is the earliest one that achieves forward privacy.¹ In the RFID context, forward privacy is the property that guarantees the security of past interactions of a tag even if it is compromised at a later stage. Namely, the secret information of a tag $\mathcal {T}_i (1\le i\le n)$ is corrupted by an adversary at time $t$, the adversary can not associate any transaction with $\mathcal {T}_i$ at any time $t' < t$.

In the OSK protocol, each tag $\mathcal {T}_i$ has an initial secret $S_i^0$ that is updated after each authentication query. The update consists in hashing the current secret with the one-way function $\mathcal H$. Upon reception of the authentication query, the tag answers by hashing the current secret with a different² hash function, $\mathcal G$. Figure 1 shows the OSK protocol.

Fig. 1.

OSK protocol

System Setup. Each tag $\mathcal {T}_i$ of the system is initialized with a randomly chosen secret $S_i^0$. The $n$ initial secrets are stored in a database, sometimes called back-end system. In some settings the back-end system and the reader are two different devices, connected in a way that is considered secure. In some other settings the back-end system is embedded in the readers.

Interrogation. When the tag is queried by a reader it answers with a response using the current secret such that $\sigma = \mathcal G(S_i^j)$ and also updates the secret immediately using a different hash function: $S^{j+1}_i = \mathcal H(S^j_i)$.

Search and Identification. When receiving an answer the database searches for an initial secret $S_i^0$ that leads to $\sigma$. In other words, it checks whether there exists $i$ and $j$ such that $\mathcal G(\mathcal H^j(S^0_i)) = \sigma$. To do that, from each of the $n$ initial secrets $S_i^0$, the reader computes the hash chains as shown in Fig. 2 until it finds a value matching $\sigma$, or until it reaches a given maximum limit $L$ (the “lifetime” of a tag) on the chain length.

Fig. 2.

OSK table: chains of hashes in the OSK protocol.

The value $\sigma = \mathcal G(S_i^j)$ does not leak any information to an attacker on the secret of $\mathcal {T}_i$ when ${\mathcal G}$ and ${\mathcal H}$ behave as pseudo-random functions. However, given that the authentication process is bounded by $L$, the OSK protocol is prone to desynchronization when an adversary queries the tag more than $L$ times. In such a case, the tag can no longer be authenticated and a privacy issue arises for a certain type of adversary, capable of detecting the success status of an authentication (see [15] for a discussion). Fortunately, the synchronization can be retrieved by the back-end without exchanging the tag; for example, the holder of a desynchronized tag can ask the system operator to recompute the chain of his tag.

Beside this desynchronization issue – and although the protocol is very efficient when all the tags are synchronized [20] – the worst-case complexity of the search procedure makes the protocol unsuitable for most practical applications.

2.2 Real-Life Applications

We now discuss the possibility of implementing OSK in real-life applications. Throughout this article, we chose a system of $n = 2^{20}$ tags with a lifetime of $L = 2^7$, which are reasonable parameters and in accordance with [3].

Online Search. A naïve approach for the server is to only keep the initial secrets and recompute the $n\times L$ possibilities each time it receives a given $\sigma$. With a server capable of $2^{20}$ cryptographic hash operations per second, this takes $2^6$ s $\approx 1$ min on average for these parameters. This is far beyond our limit of 200 ms for a reasonable identification time.

Full Storage. The other extreme solution consists in storing all the chains in a table and letting the server perform a simple look-up whenever it receives $\sigma$. This solution has the advantage of requiring no cryptographic operation during the authentication, which makes the authentication very fast. Unfortunately, this approach has two major drawbacks.

First of all, a large memory is needed to store the table: given our parameters ($n = 2^{20}$ tags with a lifetime of $L = 2^7$, and a hash size of 128 bits), the full storage approach requires $2^{34}\,\mathrm{{bits}} = 2\,\mathrm{{GB}}$.³ In a system where readers are permanently connected to the back-end server, requiring such a memory (RAM) for the server is not a major problem. However, in systems consisting of mobile readers sporadically connected to the database, the authentication material should be replicated in each of these low-resource devices. In such a scenario, this amount of memory is very large for small devices such as PDA’s or handheld RFID readers, which typically have a memory of 128 MB. It might, however, be reasonable for more elaborate devices such as NFC-enabled smartphones, which have several gigabytes of flash memory.

A second issue is that, every now and then, the table needs to be either computed in a central server and uploaded on the smartphones, or computed by the smartphones themselves after reception of the first column of the table. This might take a significant time for both cases, and might be an issue in certain situations.

In the context of [6] for instance, where a central server is used, the full storage technique makes sense, and is more simple and efficient.

Time-Memory Trade-off. An intermediate solution is the time-memory trade-off (TMTO). The idea is to use memory to reduce the authentication time, making both memory and time suitable to our application. Note that the goal of the TMTO is here to reach an authentication time that is below the acceptable threshold of 200 ms. Once this requirement is fulfilled, still decreasing the time does not make sense because (i) this implies a memory cost (ii) the authentication time would become a negligible factor in the whole communication time.

3 Background on Time-Memory Trade-offs

In this section, we briefly recall the required background on the Time-Memory Trade-off (TMTO) method. We describe the TMTO technique but make no attempt at providing a complete survey of it. For an advanced introduction about this topic we recommend to read [4].

3.1 Introduction

A common search problem in cryptanalysis is finding the preimage of a given output of a one-way function. The first naïve method is applying the function to all possible inputs until finding the expected value. Such an exhaustive search requires $N$ operations in the worst case to find a preimage, where $N$ is the total size of the problem. This becomes impractical when $N$ is large.

The other extreme is to first construct a look-up table including all the preimage values. Afterwards, finding a preimage is done via a table look-up operation which requires a negligible amount of time. The precomputation process requires an effort equal to an exhaustive search, but is to be performed only once. Although this method is quite fast during the online search phase, it may require extreme amounts of memory for large problems.

The comparison of exhaustive search and exhaustive storage methods is depicted in Table 1.

Table 1. Comparison of exhaustive search and table look-up methods (Average case).

3.2 Description

The basic idea of the time-memory trade-off (TMTO) method is to find a compromise that has a lower online computation complexity than the exhaustive key search, and a lower memory complexity than the exhaustive storage. Hellman introduced one such trade-off in 1980 [13]. Given a search space of size $N$, and given $M$ words of memory used for the trade-off, the average number of cryptographic operations $T$ obeys the law $N^2 \propto T \times M^2$ [13]. The principle is the following. During an initial phase, a point is chosen arbitrarily in the search space, hashed (or ciphered, depending on the target function), and then reduced to another point in the search space. This reduction is the output of a reduction function, which is typically a modulo. This process is iterated a given number of times, forming a chain of hashes. This whole operation is itself repeated many times and only the starting points and endpoints of the chains are kept and stored in a table. Once this table is computed, it is used in the online phase to accelerate the search. The method is probabilistic given that it is very unlikely to fully cover the search space, but several tables can be used to obtain a success probability very close to 1.

A major improvement over Hellman’s original TMTO method [13] was given by Oechslin in [8]. The precomputed table called rainbow table for this method is structurally different than Hellman’s TMTO in that it uses a different reduction function in each column. By doing so, although it might seem to slow the search process, chain fusions (events in the table construction and the search process that degrade the efficiency) in the table are much less frequent and can be detected very easily during their construction. Tables without fusion are said perfect [9] and will be used in this paper.

We now give the most relevant results in the analysis of rainbow tables.

Theorem 1

The probability of success of a set of $\ell$ rainbow tables of $m$ rows of $t$ columns each, for a problem of size $N$ is:

$$\begin{aligned} P = 1 - \left( 1 - \frac{m_t}{N}\right) ^{\ell t}. \end{aligned}$$

Proof

See [4].

Theorem 2

The maximum number of chains in a rainbow table of $t$ columns, for a problem of size $N$ is:

$$\begin{aligned} m_t^{max} = \frac{2N}{t+1}. \end{aligned}$$

Proof

See [4].

Theorem 3

The optimal parameters for a rainbow table, for a problem of size $N$, given a memory of $M$ and a desired probability of success $P^*$ are:

$$\begin{aligned} \ell&= \left\lceil \frac{-\log (1-P^*)}{2}\right\rceil ,\\ m_t&= \frac{M}{\ell },\\ t&= \frac{\log (1-P^*)}{\ell \log \left( 1-\frac{m_t}{N}\right) } \approx - \frac{N}{M} \log (1-P^*). \end{aligned}$$

Proof

See [4].

In the following, optimal parameters are implicitly used.

4 OSK/AO

4.1 Description

Avoine and Oechslin propose in [5] to apply the time-memory trade-offs to the search procedure of OSK, leading so to a variant known as OSK/AO. The complexity of the search procedure varies from $O(1)$ to $O(N)$, depending on the amount of memory we are willing to devote to the time-memory trade-off. For example, they mention that a complexity of $O(N^{2/3})$ can be reached with a memory of size $O(N^{2/3})$.

Avoine, Dysli, and Oechslin also suggest in [3] a variant of the OSK protocol that ensures strong authentication, as OSK is originally designed to ensure identification only, without consequently considering replay attacks. To do so, [3] suggests using nonces as follows: the reader sends a nonce $r$ in the authentication request message and the tag answers $\mathcal G(S^j_i \oplus r)$ along with $\mathcal G(S^j_i)$. The latter value is used by the reader to identify the tag, and the former to authenticate it.

Another advantage of OSK/AO is that the search done in the identification is intrinsically randomized, which makes timing attacks irrelevant [2].

Now we briefly describe the specific time-memory trade-off technique introduced in [3, 5].

In this technique there are two main functions namely a response generating function $\mathcal F$ and a reduction function $\mathcal R$. $\mathcal F$ takes two indices as an input (i.e., tag index and life time index) and outputs a tag response such that

$$\begin{aligned} \mathcal F : (i, j) \mapsto \mathcal G (\mathcal H^j (S_i^0)) = r^j_i \end{aligned}$$

The reduction function $\mathcal R$ is such that

$$\begin{aligned} \mathcal R : r^j_i \mapsto (i', j') \end{aligned}$$

where $1 \le i, i' \le n$, and $0 \le j, j' \le L$.

The main specificity is that $\mathcal F$ requires $j+1$ cryptographic operations to be computed, which would drastically lower the efficiency of the search if it were used directly. What is suggested instead is to use a second kind of-time-memory trade-off, called the rapid-hash table, to compute $\mathcal F$ efficiently. This trade-off table is rather straightforward: the secrets $S_i^j$ of the tags are computed from life-time values 0 to $L$, but only $\frac{L}{\kappa }$ columns are stored. This is illustrated in Fig. 3. As explained in Sect. 4.3, this means that an average of $\frac{\kappa + 1}{2}$ cryptographic operations are required per evaluation of $\mathcal F$.

Fig. 3.

The rapid-hash table.

4.2 Analysis

As explained in Sect. 4.1, there are two things that need to be stored in memory: the rainbow tables and the rapid-hash table. We discuss below the proportion of memory that should be dedicated to each.

Let $\rho$ denote the proportion of memory dedicated to the rainbow tables. The trade-off efficiency follows the rule $T = N^2\gamma /M_{RT}^2$ (see [4, 13]), with $\gamma$ being a small factor depending on the probability of success of the trade-off, and $M_{RT}$ the memory dedicated to the rainbow tables (that is $\rho M$). As for the rapid-hash table, we have:

$$\begin{aligned} \kappa = \left\lceil \frac{N |hash|}{M_{RH}}\right\rceil , \end{aligned}$$

with $|hash|$ the size of a hash, and $M_{RH}$ the memory for the rapid-hash table (that is $(1-\rho )M$). Each operation in the rainbow tables requires an average of $\frac{\kappa +1}{2}$ cryptographic operations in the rapid-hash table. Therefore:

$$\begin{aligned} T = \frac{N^2\gamma }{M_{RT}^2} \frac{\kappa +1}{2} \approx \frac{N^2\gamma }{\rho ^2 M^2} \frac{N |hash|}{2(1-\rho )M}. \end{aligned}$$

The optimal value of $\rho$ can be found easily by deriving:

$$\begin{aligned} \frac{\partial T}{\partial \rho } = 0 \quad \Leftrightarrow \quad \frac{\partial }{\partial \rho } \left[ \frac{1}{\rho ^2(1-\rho )}\right] = \frac{3\rho - 2}{(\rho -1)^2\rho ^3} = 0, \end{aligned}$$

which yields $\rho _{opt} = \frac{2}{3}$. In the following, we will thus take the memory for the rainbow tables to be two thirds of the total memory.⁴

4.3 Algorithms

We now describe the algorithms used in OSK/AO, namely (i) the algorithm to compute the rapid-hash table (Algorithm 1), (ii) the algorithm to build the TMTO tables (Algorithm 2), and (iii) the algorithm to identify the tag (Algorithm 3). The material in this section mostly comes from [6]. The notations used in the algorithms are given in Table 2.

Table 2. Notations used throughout the paper.

First, the system randomly generates the initial secrets for all the tags such that $S_i^0 \in _R \{0,1\}^\lambda$ where $1\le i \le n$, and $\lambda$ is the length of the secrets. The system defines a $\kappa$ parameter then computes the interval secret values of all the tags. After that all the secrets are stored into a two dimensional array such that $state[i][k] := \mathcal H^{k \times \kappa } (S^0_i)$ where $k= 0, 1, 2, \ldots$ and $0 \le k \times \kappa \le L$.

Now, for a given secret of tag $i$, the $j$th rapid-hash computation of the secret is presented in Algorithm 1. The algorithm requires only at most $\kappa$ hashes by the help of the precomputed RH table. Whenever $\kappa$ decreases, the memory usage increases but the on-line computation decreases.

Algorithm 2 shows the procedure to construct a single rainbow TMTO table. For the construction, only two parameters are needed: the number of starting points used in the precomputation phase (generally named $m_1$ [4]) and the number of the table to be generated. The starting points of a TMTO table are fed into the $\mathcal F$ function sequentially. The output is actually a response of a tag in the system and is fed into the reduction function which outputs arbitrary indices. For a single chain this process is repeated consecutively up to a pre-defined chain size $t$, then the starting and endpoints are stored in the table. Finally, each generated ending point is compared in the table to detect fusions. When two chains generate a fusion, one of them is discarded. This procedure eventually leads to a perfect table.

Finally, Algorithm 3 shows the identification process of a tag by extracting the pre-image of a given response using TMTO tables. This part of the system runs during the authentication of a tag. First, $TagResp$ (the answer of the tag) is fed into the reduction function $R^v_t$ and searched among the ending points of the TMTO table. (i) If a match is found, the corresponding starting point is iterated as explained in Algorithm 2 up to the $(t-1)$th reduction function $R^v_t$ in order to get a candidate response. If the candidate response is equal to $TagResp$ then identification is completed. Otherwise (ii) $TagResp$ fed into the reduction function such that $R^v_{t-1} (TagResp)$, then the resulting indices fed into $\mathcal F$, and then the resulting response fed into $R^v_{t}(TagResp_{next})$ consecutively. As previously done, the output value search among the endpoints of the TMTO table and the similar process is carried as described above.

5 Experiments and Comparison

5.1 Environment

The precomputations are performed with a personal computer having Intel 2.8 GHz Core2 Duo processor, 4 GB RAM and Windows 7 - 64-bit operating system. As an NFC enabled mobile phone we use LG OPTIMUS 4X HD having 1.5 GHz processor and 1 GB RAM [17]. The cell phone has an open source Linux-based operating system, Android. This OS has a large community of contributors who develop applications primarily written in a customized version of the Java programming language [22]. The phone supports both ISO/IEC 14443 and ISO/IEC 15693 standards which are the common standards in order to read/write 13.56 MHz contactless smart cards.

For the tags, we work on professional version of ZeitControlers basic card $ZC7.5\,(ZC-Basic)$ which is a programmable processor card as hardware environment for protocol implementation [12]. It has a micro-controller with 32 kB user EEPROM that holds its own operating system $(OS)$ and it has 2.9 kB RAM for user tag’s data. It supports ISO/IEC 14443. The EEPROM contains the user’s Basic code, compiled into a virtual machine language known as P-Code (the Java programming language uses the same technology). The RAM contains run-time data and the P-Code stack. The overview of the system is depicted in Fig. 4.

Fig. 4.

Overview of the system

5.2 Parameters and Functions

The parameters for the experiments are $n = 2^{20}, L = 2^{7}$ and the one-way functions we selected are the following ones⁵:

• $\mathcal H(S^j_{i}) : AES_K(S^j_{i})\oplus S^j_{i}= S^{j+1}_i$,

• $\mathcal G (S^j_{i}) : AES_K(S^j_{i}+1)\oplus (S^j_{i}+1) = r^j_{i}$

where $K$ is a 128-bit constant key. This is known as the Matyas-Meyer-Oseas construction [19]. Its goal is to build a one-way function from a block cipher.

We use the AES algorithm in the construction because it is commonly implemented on fewer gates than classical hash functions (see e.g. [11]), and, in particular, is also available in the ZC7.5. This construction requires only one key schedule during the initialization phase of the tags, which makes algorithm faster.

To construct rainbow tables each column of each table uses a different reduction function. The function takes three parameters that are the table index $(v \in [0,1,\ldots ,\ell -1])$, the column index $(w \in [1,2,\ldots ,t])$ and the response output as a byte array $(val[.])$. This function produces two output values; the first one is for tag index $(i = 0,\ldots ,n-1)$, the second one is for lifetime index $(j=0,\ldots ,L-1)$. The $i$ value is computed as $i= (Int32(val[v,v+3]) + w)\mod \ n$ where the function $Int32$ converts a given input 4-byte array into an unsigned 32-bit integer. The $j$ value is computed as $i= (Int32(val[v+1,v+4]) + w) \ \mod \ L$. The construction of our reduction functions are given in Algorithm 4.

5.3 Precomputation of the Tables

In order to use our implementation on low-resource devices (such as hand-held readers, PDAs and NFC compliant cellphones) we build tables that can fit to small RAMs.

For the total memory there are two parts: (i) the rapid hash table that stores some intermediate values of the OSK table and (ii) the TMTO tables.⁶ We use the optimal parameters, so we compute the $\kappa$ and $t$ such that the memory consumption is as described in Sect. 4.2.

Another significant choice for the TMTO construction is the probability of success. It should be high enough to avoid false negatives during the authentication process. In our scenario, using $\ell = 4$ rainbow tables of maximal size, the probability to identify a tag is greater than 0.999 according to Theorem 1. Note that trying to reach a higher success probability does not make sense given that the probability of failure due to noise on the channel is even higher.

Finally, regarding the number of starting points $m_1$, we use the same trick as in [4] to reduce the precomputation effort. In our case, we obtain about 98 % of the maximal number of ending points by starting with 50 times that number.

In total, the precomputation cost is $\ell \times m_1 \times t$ evaluations of $\mathcal F$, which is about $4\times 50\times m_t\times t = 400\,nL$ in our case (see Theorem 2). Since these are $\mathcal F$ evaluations, this number is also multiplied by $\frac{\kappa + 1}{2}$ hash operations. For instance, if $\kappa = 6$ and on a server capable of $2^{20}$ hash operations per second, the precomputation stage would take about 50 h. Some details about the precomputation of rainbow tables seem to have been overlooked in [3, 5], which would explain their optimistic result. However, we can do much better than that if we build a table containing the $nL$ secrets, and use it during the precomputation instead of the $rapidH$ table. This table needs $nL|hash|$ bits, that is 2 GB in our case, and takes about 2 min to build on the server. In this case, there are actually no hash operations during the building of the TMTO table, making this procedure faster. In our case the whole precomputation process takes about an hour.

5.4 Experiments

We tested the performance in two settings by running Algorithm 3 (i.e., identification process of OSK/AO with randomly chosen tags). Our mobile phone [17] is able to compute about 187,750 hashes per second. For both settings, the experiment is run 1,000,000 times. The experimental results are depicted in Table 3.

Table 3. Results of experiments on an NFC compliant cellphone

We also measure the time when we use our system with a real tag. There are three phases on the tag’s side: receiving a query, computing the response (two hash calculations), and sending the response. The total time is 70 ms on average, including 50 ms for the calculation of the two hash values and 20 ms for the communication.

It can be seen that the average identification time is below the 200 ms threshold (if we include the 70 ms for the tag computation and the communication) even for a memory below 128 MB. We thus show that one can achieve very fast authentication even with limited memory.

6 Conclusion

We have implemented the OSK/AO [3] protocol on an NFC-compliant cellphone and a ZC7.5 contactless tag. Our implementation is fully operational and is, to the best of our knowledge, the first implementation of a privacy-friendly authentication protocol based on symmetric-key cryptography. The implementation is suited to large-scale applications, e.g. a million of tags, as this can be the case in mass transportation systems, even on low-resource mobile devices such as hand held readers, PDAs or NFC compliant cellphones. We have run several experiments on the implemented RFID system and we show that the results obtained match the theory and are favorable to a practical deployment.