As we can see, the aforementioned attacks essentially turn MIFARE Classic into a dumb memory card without any cryptographic protection. The wide deployment of MIFARE Classic makes it financially prohibitive to replace the broken hardware with secure alter-natives. In this chapter, we propose a defense mechanism that can prevent most attacks without requiring any hardware changes. Such a mechanism can be used as an interim so-lution before the deployment of next-generation, secure RFID ticketing systems to replace MIFARE Classic.
The basic idea of our proposed mechanism is to cryptographically provide integrity protection for the data on a MIFARE Classic PICC. The computation is done on PCD;
hence in most cases we only require software upgrades on PCD. For this, we can either use symmetric- or public-key cryptography. As such a system is often deployed over a wide area across many administrative domains, the key management will be a very challenging task if we use symmetric-key cryptography. However, traditional public-key cryptography like RSA can also be prohibitively expensive on devices like MIFARE Clas-sic PCD, which typically only have very limited computational power. For this reason, we suggest the new multivariate public-key cryptosystems (PKCs), which enjoy two ad-vantages over traditional counterparts like RSA: they run much faster and can survive the attack of the emergent thousand-qubit quantum computers [20].
5.1 Multivariate PKCs: TTS
In multivariate public-key cryptosystems [20], the public key is a set of m polynomials P = (p1, . . . , pm) in variables w = (w1, . . . , wn) where variables and coefficients are in K = GF(q), built via invertible affine maps S and T :
P : w ∈ Kn S7→ x = MSw + cS 7→ yQ 7→ z = MT Ty + cT ∈ Km.
The central map Q, which can be inverted efficiently, decides the properties of the cryp-tosystem and S and T make P appear random.
In a type of Q called Unbalanced Oil and Vinegar [21], some variables (“oil”) never appear in the quadratic terms. We set remaining variables (“vinegar”) randomly and solve for oil variables in a linear system to get a digital signature.
For efficiency, we can stack together m1+ m2 equations in a “2-layer Rainbow:” m1
equations in a UOV with v vinegar and m1 oil variables, and the remaining m2 a UOV with the v + m1 earlier variables as vinegar and the final m2as oil.
Making polynomials sparse such that each equation has as many crossterms as vine-gar variables, we get “2-stage TTS” with parameters (q, v, m1, m2). Here m = m1+ m2, n = m + v. TTS/Rainbow security and implementation has been studied for most of a decade [22]. TTS is very fast both on today’s commodity PCs and low-end microcon-trollers, as shown by the rough speed of a recommended instance TTS(256,18,12,12) in Table 5.1 for four hardware platforms.
• C2+ Intel Core 2 Quad Q9550;
• K10+ AMD Phenom II X4 905e;
• i52 Intel 8052, a 8051 with 256-byte fast RAM, T = 12;
• W58 Winbond W77E58, i52 clone with dual pointers and T = 4, T is number of clocks per instruction cycle.
In some delay-insensitive cases, both signature and verification can even be performed on a PCD equipped with 8051-grade microcontroller as they take a fraction of a second each.
Table 5.1: Speed of TTS on Various Platforms Platform Signature Verification
cycles time cycles time C2+ 2.83 GHz 36K 12.7 µs 121K 42.7 µs K10+ 2.50 GHz 46K 18.4 µs 155K 54.5 µs i52 3.57 MHz 101K 341 ms 339K 1139 ms W58 3.57 MHz 135K 152 ms 452K 506 ms
Furthermore, we can run TTS on FPGA if the PCD has an FPGA, which is a common practice nowadays in many niche-market embedded systems, as FPGAs provide greater cost-effectiveness and flexibility. We can optimizing for minimal area and current like Yang et al. [23] or for time-area product a la Bogdanov et al [24]. These designs are scalable, hence we may extrapolate from the earlier enTTS(20,28) and conservatively expect 38,000 gate-equivalents (GEs) for the former, and 89,000 GEs for the latter (in only a few hundred cycles at a few tens of MHz, compared to 10,000 for the former).
So even the newer (and larger and slower) TTS should still run efficiently on even the smallest FPGA in most PCDs.
5.2 System Design
Figure 5.1 shows the memory layout of a protected PICC. We combine two sectors into a super sector, which can be used to store three data blocks along with the cryptographic checksum that protects their integrity. The checksum is computed over the entire three data blocks using a strong cryptographic hash function. The hash value is then digitally signed by the PCD using its private key, whose ID is also recorded along with the signa-ture. We note that there is a 32-bit counter stored along with Key ID in the same block that is not shown in Figure 5.1. This counter value is used to prevent replay attacks, which we will discuss in more details below, and hence should be included in checksum computation as well.
Each PCD is equipped with a database of all PCDs’ digital certificates. Therefore, each PCD is able to verify whether the data stored on a PICC has been tempered by
Key ID
Figure 5.1: Proposed Defense Mechanism on PICC
an adversary when necessary. This prevents the attacker from altering the content of a PICC as long as he can not forge a valid signature. However, this does not prevent replay attacks, in which the attacker simply replace the content of a PICC with a previously valid value, resulting in what is called “double spending” in the literature of electronic payment systems.
Replay attacks can be prevented using a blacklisting mechanism on PCD, with which each PCD can check against whether a PICC has been compromised before conducting any transaction with it. Figure 5.2 shows the software modification needed on PCD in order to support data integrity check and blacklisting. The basic idea is to keep track of how many times a PICC has been accessed across the entire system. Conceptually, this per-PICC state is kept in the backend system, so breaking MIFARE Classic PICC does not give the adversary any benefits. However, to reduce communication overhead, we store this value on the sector 0 of each PICC so that each PCD can get this number locally when communicating with a PICC. To tie this count value with a transaction, we require that PCD include this value in cryptographic checksum calculation, as mentioned previously.
Each PCD keeps a transaction log for all the transactions it has done and synchronizes