Don’t Push It: Breaking iButton Security

Abstract

Maxims iButtons are small portable (steel) tokens that can be attached to objects (e.g., keys, fobs) and are deployed in various applications from access control to devices and buildings to asset management and electronic cash. So far, the security and privacy aspects of iButtons have been widely unexplored. The so-called Secure iButtons are advocated for security critical applications for e.g., micropayment, authentication or feature activation.

In this paper we present for the first time a detailed security analysis of the Secure iButtons DS1963S. Although no technical details are publicly available, Secure iButtons have a variety of physical and cryptographic built-in measures to protect against physical tampering as well as unauthorized access to cryptographic material. We developed methods to bypass all these protection mechanisms of the manufacturer. We present a differential fault attack and implementation attack on the SHA-1-enabled iButton (DS1963S chip). Beside the emulation and impersonation, our attacks succeed in extracting the secret keys stored in the iButton. Our methods allow an infinite rollback to the initial state, which is crucial when targeting micropayment systems based on iButtons. We also demonstrate our attacks on Maxims reference platform of a micropayment system. Our best attack requires a minimal financial invest and take less than ten minutes, including target preparation, while the pure attack on all eight 64-bit keys is completed in a few seconds.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

While there is a large body of literature on the security of smartcards and/or contactless tokens such as RFID [20, 22, 23, 27], car and garage transponders [21, 25, 28] and other embedded security chips such as [24], iButtons have been mostly unexplored by the research community. iButtons are micro-chips produced as a small stainless steel can, commonly embedded on special key-fobs (see Fig. 2a). They are used in a wide range of technical services and products. For security critical applications the so-called Secure iButton [7–9] are advocated as a real alternative to Magnet Stripe Cards, Smart Cards, and Proximity or Contactless Cards. Typical application scenarios are physical access control (e.g., door lock systems [1, 3, 4, 14]), anti-theft and intrusion protection mechanism (e.g., for protection of train ticket machines [2]), feature activation (e.g., Supermicro’ raid controller [15], [16]), electronic cash and tickets (e.g., Akbil micropayment system of the Istanbul metropolitan transportation [19, 29]), cashier systems ([11, 17]), and voting machines ([12]) (Fig. 1).

Fig. 1.

Application Scenarios and SCUs: [2, 11, 12, 14, 19] (left-to-right)

We point out that these few examples are only the tip of an iceberg and indicate a much wider range of security sensitive applications in the field (including also non-crypto iButtons used for security issues). Most of these systems would be seriously affected when the security of iButtons fails.

1.1 Secure iButton Device Family

There are different device models of Secure iButtons. The DS1963S token is the most advanced iButton product on the market for security applications, and hence the subject of our investigation. It is an high-end model, embedded in a stainless steel container with 704 bytes memory equipped with an internal lithium cell power source. The other two devices DS1961S [7] use EEPROMs instead of volatile memory and allow deployment without a lithium cell. The DS2432 [10] is essentially similar to DS1961S devices, but enclosed in a chip-scale small outline package.

Fig. 2.

iButton hardware architecture

Secure iButtons have sophisticated physical tamper protection and a cryptographic engine for authentication purpose. In the following, we use the term Secure iButton to refer to the DS1963S iButton model. Secure iButtons have a proprietary onboard 512-bit SHA-1 MAC engine with overall eight 64-bit secret keys using a challenge response procedure for authentication. Those tokens have several integrated physical tamper-protection and access control mechanisms and countermeasures to prevent the secret key extraction and/or the misuse of these devices, although relevant data sheets as well as all other important implementation details are not publicly available.

1.2 Our Contribution

We performed a detailed analysis of Secure iButtons with the focus on the SHA-1-enabled DS1963S device model. We have developed a set of fault- and implementation attacks that overcome various sophisticated physical tamper protection and logical countermeasures allowing a full exposure of these tokens. More concretely, we succeeded in (i) circumventing the physical tamper-protection and self-destruction mechanisms attached to the electrical circuits, (ii) overwriting the protected memory with fault-injected data, (iii) extracting the secret keys, and finally (iv) impersonating and emulating the token in application scenarios such as micro-payments.

As we will elaborate in details, for our analysis, we had to tackle several technical challenging problems to be able to fully reverse engineer this small security token. We stress that our methods are not limited to iButtons and can also be applied to other similar embedded devices. Our most efficient attack requires a small one-time monetary cost of approx. US$350. The complete attack takes less than ten minutes, including target preparation, while the pure attack on all (eight) 64-bit secret keys is completed in a few seconds.

2 Background

Similar to complementary technologies, like NFC/RFID tags, magnet stripes, and smart cards, the Maxim iButtons, also known as Dallas Keys, exist in different flavours with special functionality, e.g., real-time clocks (DS1904) [5], autonomous temperature and humidity loggers with password protection (e.g., DS1923) [6], password-protected memories (DS1977) [9], and the so-called Secure iButtons for security-critical applications with high security requirements.¹

A Secure iButton system consists of a Service Control Unit (SCU), as service provider, and an iButton as client token. Communicating with an iButton requires a simple touch of the iButton to a SCU. Both parties communicate by the 1-Wire protocol standard [13]. In the following, we will give a brief introduction to the corresponding components and the underlying technology as far as it is required to understand our attack methods. Figure 2b illustrates a typical system architecture.

1-Wire Device Communication. The 1-wire communication is similar to a $I2C$ serial communication². An iButton system requires only one electrical signal and an additional ground. Hence it allows a data transfer over a single wire. The protocol layers are detailed in the technical specification of the manufacturer [26]. The power is supplied over the signal line with 3 or 5 Volts. The low-level signal is at 0V. In order to guarantee a sufficient power supply of the internal circuit, an iButton is always on the high level when idle. The bus master initiates and controls all 1-Wire communications.

For our attack, we only need a set of low level functions on the Transport Layer. These commands allow to perform memory operations, and initiate procedures where the cryptographic SHA-1 engine is involved. See Appendix A for a list of important functions.

Security Architecture and Protection Mechanisms. As mentioned in the previous section, Secure iButtons are high-end tokens for security sensitive services and authentication purposes. In order to prevent modifications of sensitive data records, iButtons have a set of protection mechanisms. The tokens have physical tamper-protection, rugged, and able to perform the cryptographic hash operation within given time constraints.

Physical Tamper Protection and Zeroization. The manufacturer has employed a set of sophisticated barriers for an attacker. In order to prevent modifications of sensitive data records, an internal lithium cell powers the volatile memory inside the iButton. Opening the steel container forces a disconnection from the power source. If an adversary attempts to penetrate the steel container, the chip will clear its memory data. Specific intrusions that typically result in zeroization of the volatile-memory are: (1) opening the steel container with disconnection from the internal power source, and (2) micro-probing of the chip.

Cryptographic Engine. Secure iButtons have an integrated cryptographic engine with the ability to perform cryptographic hash-based message authentication, where the hash input message is combined with a secret key. Therefore, Secure iButtons have a slightly modified 512-bit hardware implementation³ of the Secure Hash Algorithm (SHA-1) for (H)MAC generation and a read-protected memory area for eight 64-bit secret keys.

Internals of iButton Memory Archtiecture. Secure iButtons have 512 bytes of volatile SRAM memory. The memory comprises of 22 memory pages each having a size of 32 bytes. Figure 3 shows the memory and special registers.

Fig. 3.

Secure iButton memory layout

The memory is segmented as follows: Pages 0 to 15 is the user data memory. The user memory of an iButton is neither read nor write protected. The memory pages 16 and 17, which store the secrets, are read protected and memory page 19 to page 21 are write protected.

In particular, this memory serves as storage for the Service Data Record (SDR), which consists of the Service Data ${ SDATA }$ (e.g., the e-Cash balance), the Service Data Signature ${ SIG }$ and the transaction identifier ${ TID }$.

All iButton devices contain a 64-bit unique number ROM-ID for identification. This number is enrolled and fixed permanently within the manufacturing process (factory laser-burned)⁴. It cannot be easily re-programmed or altered without physical reversing and reconstruction of burned bit lanes of the memory (e.g., with physical attacks).

Eight read-only 32-bit Page Write Cycle Counters (P-WCC) and eight 32-bit Secret Write Cycle Counter (S-WCC) are used for integrity protection. These counter are incremented with each write access to the service data (Page 8-15), and the secret keys, respectively. The counters cannot be changed from outside. It is used for detection of write processes and integrity violations of the service data.

Protected Memory and Secret Keys. The Secret Keys $S0$ to $S7$ resides in the protected memory area of an iButton device. Each protected memory area is able to store a 64-bit secret key. Concerning their intended use, these secrets are classified in three logical types: the Master Authentication Secret ${ MAS }$, the Master Signing Secret ${ MSS }$, and the Unique Authentication Secret ${ UAS }$. These keys are MACs, generated by a host system of the service provider by $\text{ UAS } = \text{ SHA-1 }( \text{ MAS } || \text{ ROM-ID } )$, cf. [8].

Note, that the MAS and MSS only reside on all service control units, while UAS is exclusively stored in the protected memory area of the unique client token. However, the SCU is able to derive the unique authentication secret from the Master Authentication Secret and the unique identifier ROM-ID of the iButton client. Secret 0 is reserved for MSS and should only be used by a master signing secret.

Memory Copying Process. iButtons allow a transfer data, e.g., secret keys $S0$ to $S7$ from the I/O buffer to the internal memory area. How exactly the copying process internally works is neither documented nor known in public. However, it is noted that at least eight bits of an alternating pattern need to be read. The reason is that the chip needs a subsequent 1-Wire Reset command to respond correctly. It is likely that this property is also directly related to the copying process. In general, to start a memory copy process, a combination of the WriteScratchpad, the ReadScratchpad, and the CopyScratchpad functions are used [26].

The WriteScratchpad command writes an authorization data, which consists of two bytes address register and the payload data (TA1, TA2, Data). The ReadScratchpad command reads an authorization data, which consists of three bytes of the address registers (TA1, TA2, E/S), respectively. Afterward a CopyScratchpad command is performed. When this process has been done correctly with no transmission errors, the authorization accepted flag is set and the copy process starts. During the copying process, the master reads continuously binary values $1_2$ (base-2 binary notation), after completion of copying an alternating $10_2$ pattern. According to the datasheet the copying process does not take longer than 30 $\mu$s.

Atomicity of Protected Memory Access. The cryptographic engine and the SRAM memory are powered by an internal lithium cell. This construction has the advantage, that functions are still working correctly, even if the token is removed from the contact point or the external power supply collapses.

With the internal battery, the atomicity is guaranteed and security critical functions, like memory transactions are processed safely. This has two reasons. First, once executed, a memory copying process from the scratchpad the protected memory areas are carried out completely in a single step. If the CopyScratchpad function is used to overwrite an existing secret key with a new secret from the I/O memory buffer, the target memory page will be overwritten at once. Secondly, specifying a target memory address that only contains a part of the 64-bit secrets, will lead to a full copying process of the complete secret. These two properties should guarantee that it is not possible to overwrite only a smaller part of protected memory.

3 Adversary Model and Attack Goal

The main attack objective is to exploit the iButton security architecture in order to get full access to the secret keys $S0$ to $S7$. In particular, the attack is able to extract a Unique Authentication Secret (UAS) on a user token, as well as a Master Authentication Secret (MAS) or Master Signing Secret (MSS) stored in a SCU coprocessor token. Having access to these secrets, the integrity of arbitrary service data and authentication are compromised.

We emphasize, that the attack does not target the cryptographic SHA-1 engine, and the cryptographic algorithm itself is not affected. Our method targets to attack the memory copying process from the scratchpad to the protected memory area where the secret keys are stored. It aims on interrupting the atomic copy process when writing new secret keys to that protected area. More precisely, we inject faults at certain time instances of the memory copying process that destruct the atomicity of the copying process. As a result, we achieve that copying is aborted, and thus the secret keys are not completely overwritten. Finally, with the gathered results from a small set of faulty MAC operations, we are able to reconstruct the complete original secrets.

Since, additional security properties, like the Write Cycle Counter or the physical ROM-ID, are hard to tamper a subordinate goal is to build an iButton emulator using the extracted secret keys, which allows impersonation and cloning.

4 Security Analysis of Secure iButtons

We break the cryptographic implementation by a differential fault attack where an adversary tamper security sensitive operations. For this, we firstly need unconditional access to the internal circuit without any information loss of the internal volatile memory. Hence, the attack must circumvent the tamper protection mechanisms. Secondly, we need to perform a differential fault attack on the authentication process to produce partially overwritten secrets. The following section gives a detailed description of the attack phases.

4.1 Tamper Protection Mechanisms

One major security feature of iButtons is its tamper protection. Opening the iButton typically results in a complete loss of all data of the whole SRAM memory, including the secret keys.

We have anatomized multiple iButtons. For this purpose, we have opened the devices with different approaches, in order to completely extract all components of a token. Figure 4 shows an exploded view of the individual pieces.

Fig. 4.

iButton hardware architecture

The iButton have an outer shell (Fig. 4a-C) and an inner cup (Fig. 4a-A) dividing the internal components of an iButton token on two major groups of parts. The first group consists of the leaf springs or microswitches (Fig. 4a-E) and (Fig. 4a-G), the lithium cell (Fig. 4a-F) and a plastic bracket (Fig. 4a-B), which fixes the lithium cell. The second module is assembled on a printed circuit board with distinct contact surfaces (Fig. 4a-D).

Figure 4b shows the same structure from the top side. The contact points (Fig. 4b-A) and (Fig. 4b-B) are both spring tabs, sticking out of the holder and press the corresponding contact pads on the board. Thus, this produces a reliable electrical connection. Figure 4c shows the printed circuit board of the token. The tab of the spring connects the contact area to ground (GND) (Fig. 4a-B). While pressing the two lugs of the leaf spring on VBAT, the two lugs are connected by a conductor track pad (Fig. 4a-E). The board is placed loosely in the inner cup of the iButton can and is only fixed by the three spring tabs under contact pressure. On the board are two integrated circuits (Fig. 4c-A) and (Fig. 4c-D) connected via bonding wires with the surrounding conductors protected by an epoxy shield. The three pads (Fig. 4c-B) and (Fig. 4c-E) are fully exposed. The 1-wire data line is passed through a via (Fig. 4c-C) on the opposite side. A data loss is reasoned by a disconnection of the spring contacts that are ejected in an attempt to open the iButton.

4.2 Breaking the Tamper Protection

Now we show that it is possible to decapsulate the device and to circumvent the protection mechanisms. For this we have investigated several methods to bypass the tamper protection, like physical extraction with exploiting data remanence properties of low-temperature cooled iButtons, etc. Our preferred method aims the separation of the internal circuit board from the internal lithium cell and the connection to an external voltage source. As a result, we have complete control over the internal chip, which enables escalated implementation attacks. It is a five-step process, which has strictly to be done without any power loss of the internal chip and SRAM during this separation:

Fig. 5.

Secure iButton exposed

Step 1 - Removal of the Cover Plate. At the beginning of the extraction process, the cover plate has to be removed. Thus, the token is mounted on the placement apparatus, directed with the data area of contact to the top, cf. Fig. 11 in Appendix C. We use an end mill cutter to drill a small hole into the top (Fig. 5a). The cutter is lowered slowly. Thereunder, the circuit board becomes visible. The red arrow in Fig. 5a on the left points on this marker. Next, a part of the top cover is removed with a cone mill. The radius is selected in such a way, that an outer rim still remains, which covers the circuit board in the edge region. This ring is necessary in order to keep the board in place without a connection loss to the internal power supply. The copper-coated underside of the board becomes visible on the inner side (Fig. 5b).

Step 2 - Milling of the Circuit Board. The visible underside of the circuit board is part of the data signal line, which is directly contacted with the top cover to the iButton outer shell for 1-wire communication (Fig. 4a-A). In this step, we carefully remove the copper layer of the outer/visible side of the circuit board by grinding. Despite the thinness of the board, this process leads to only a negligible loss of stability. The removal of the copper layer has the result that the plate of the circuit board becomes transparent and the circuit board traces and semiconductors are visible (Fig. 5c).

Step 3 - Perforation of the Circuit Board. After this step, the positions of the traces are directly visible. Thus, it is possible to perform a targeted drilling to get access to the inner circuit. Because of a high risk of shortcuts and instability of the circuit board this drilling is not anywhere safely possible. We have chosen an approach that mills directly into the Vcc data pad and beside the GND pad area. The two arrows in Fig. 5c point to these drill holes.

Step 4 - Providing an External Backup Battery. Next, we attach an external backup power supply to the internal circuit. This process requires to solder two wires through the relatively small openings onto the inner Pads of the board. Figure 5d shows the connected wires. The voltage of the lithium cell can now be measured at the end of the wires. After attaching an external source for the internal power supply to the wires, we are able to extract the inner circuit board from the internal battery without any data loss.

Step 5 - Extraction of the Chip. In a final step, the inner circuit board is extracted from the iButton body. After the overlaying rim has been removed, the board is now completely separated without an interruption of the internal power supply.

4.3 Differential Fault Attack

After preparation, we are at the point at which the actual fault attacks on the internal secret keys begin. The attack consists of two phases. In the first phase, a series of faults are injected for each SHA-1 MAC computation. During this phase, we obtain information, which are finally evaluated in the second phase. At the end of this evaluation, all secrets $S0-S7$ are known.

Fault Injection on SHA-1 MAC Computation. The differential fault attack targets the implementation of the cryptographic SHA-1 MAC operation. As a reminder, even if the memory of an iButton is read protected, it allows writing arbitrary data to that memory area and perform a regular MAC computation. Our goal is to perform a set of MAC operations with partially known secret keys. We generate these partially known secrets by interrupting the atomic copy of a new (known) secret from the scratchpad to the protected memory area, where the (unknown) secret value resides. Therefore, we inject faults by a power-glitching and controlled disturbance of the power voltage supply. In principle, from a technical point of view, the fault injection works as follows: we have three connections: GND, a 1-Wire data line and the internal connector of the lithium cell. The core of the glitching-attack is to switch the input source of the lithium cell from 3 V to 0 V level. We wait a certain time interval and then pull up the power level back to 3 V. Figure 6 illustrates this fault injection timing procedure.

Fig. 6.

Fault injection timing procedure

Since the copy process happens in a period of a few $\mu$s, and this process must be interrupted deliberately, a precise timing is necessary. In order to meet this requirement, a micro-controller with 16 MHz clock frequency is used. It acts as both, a bus master as well as a controller of the connected backup lithium cell that glitches the internal power supply of the iButton chip. The voltage of the entire system is selected to 3.3 V, so that it corresponds approximately to the voltage of the internal lithium cell.

Description of the Attack Procedure. Figure 7 illustrates the process of the basic attack procedure. In order to perform a partial write operation, a known first secret is written in the scratchpad. The procedure begins with the EraseScratchpad command. It is used to clear the Hide flag and set the scratchpad to be accessible from the outside (Step 1).

Manual Hide Flagging. An explicit command for setting the Hide flag does not exist. The only known regular method is to remove and reconnect the iButton from the interface. Since this method is neither comfortable, fast, nor error resistant, we prefer another solution. Namely, we also can stimulate the reconnect by a little trick. Since we have full control over the internal power supply, from Sect. 4.2, we are able to lower the internal power supply for about 5 ms to 0 V. This also led to manually setting the Hide flag. As a results, we gain access to the protected memory.

Fig. 7.

Fault attack procedure - method 1 (basic attack)

With the WriteScratchpad command, we set the known secret key (64-bit zero vector) and write that 64-bit value into the scratchpad buffer (Step 2). Optionally, the ReadScratchpad command could be used to verify that the data was written correctly to the scratchpad. Now, we have to set the Hide flag (Step 3) which restricts the write access to the scratchpad buffer.

Copy Scratchpad with Triggered Fault Attack. We pass the target address of the specific protect memory areas, holding the unknown secret key. In this step, finally, we perform the copy function and transmit the previously read three bytes TA1, TA2, E/S, but with one exception: the last bit of the byte E/S is not transmitted immediately. This is important, because the preparation is almost finished, however, the token remains in a trigger-able state. It is crucial that the last bit of the E/S address register value is not transferred. This bit is transmitted by a separate function. With the rising edge of this bit of the copy operation is initiated (Step 4). Therefore, we transfer the last bit manually. After a predetermined time, the internal power supply for a period of 1 ms is lowered to 0 V and the copy process is canceled. When the internal supply voltage is restored, a reset is performed. The device is then fully functional and is able to calculateoperations based on the (possibly partially modified) secret key bytes in the protected memory area. We compute a MAC by the ReadAuthenticatedPage command (Step 5). The command writes the results into the scratchpad memory (Step 6). Finally, we read out the MAC and store the value for further evaluation (Step 7).

Fault Injection Process and Fault Propagation. At the beginning of the fault propagation process on the secret keys, we initiate a copying process and immediately perform a power-glitch on the circuit directly after 0 ms delay. It is clear that no bytes have been overwritten. We compute a MAC, which is based on the completely unknown secret. In the second iteration, we wait a little longer until we inject a power-glitch and re-calculate a MAC again. Probably, after a few iterations, we overwrite the first byte of the secret key, cf. Figure 6.

It takes a few iterations to overwrite the second byte, and so on, until the last byte of the secret key byte is set. To gain meaningful information from such an attack, a MAC is calculated between each fault injection. Some of the iterations might compute the same MAC. Nevertheless, this attack design makes the procedure more robust. Using predetermined timings might result in a higher error rate, since temperature changes and manufacturing variations might alter the timing properties. Finally, the above procedure is applied for all eight secret keys $S0-S7$. The computation of the MAC operation is enforced, and all computed data resulting of these operations are stored. With the information obtained from the fault attack, we are now able to determine the unknown original secrets with minimal computational effort. After filtering, we obtain a list of secret entries with exactly nine different MACs (see Table 1).

Table 1. Fault propagation for a a secret key (example)

Table 1 gives an example for a successful fault propagation for all eight secret key bytes. This example shows the fault propagation, the register values in the protected memory area (partially overwritten secret key), and the corresponding MAC operation for all eight secret key bytes and a pristine computation using the original secret key (target).

Reconstruction for all eight Secret Keys. The original unknown secret key is calculated by reverse and stepwise-testing of all MAC candidates for each faulty entry. For each entry, we compute the corresponding MACs for all possible $2^8$ secret key bytes and compare the results with the stored MAC values gathered from the previous attack round. A matching pair indicates that a correct secret key byte is found. This process is repeated until the complete secret key is extracted. Appendix B shows an example for all extracted secrets $S0-S7$.

Optimized Attack with Automatically Generated Secrets. Due to an attack or other processing it might happen that one or few bits of the memory changes unintentionally. Now we present an alternative method which allows an attack even when such a bit flip or even a deletion of the memory has occurred. This procedure has the benefit, that it works with a defective iButton, which has been reinitialized after a complete power loss for a longer period. The method does not aim at the fault attack directly, but it optimizes the preparation phase of our attack. Moreover, the method does not need to set the Hide flag manually, which makes this method much more performant and robust. As detailed in Sect. 4.3, the basic method uses partially known secrets (64-bit zero vector). However, that basic method has some drawbacks due to manual hide flagging. The more the chip is cooled, the better the data remanence. But on the other hand, the difficulty increases to set the Hide flag. Moreover, a manual hide flagging costs most of the attack time.

Fig. 8.

iButton fault attack procedure - method 2 (optimized attack)

Our advanced method is based on automated generated secrets. The cryptographic engine calculates those secrets itself. The initialization values are based on seeds. Actually, this functionality is envisaged for usage for distributed key generation. The manufacturer calls this special type of cryptographic keys partial secrets. It is quite adjuvant for an attacker that this function also sets the Hide flag and optimize the attack performance drastically. The complete fault attack needs only one second per unknown secret, that is about eight seconds for all eight secret keys.

As a precondition, no computations based on the ROM-ID have to be performed on the iButton token. This, for example, excludes a call of the ReadAuthenticatedPage command. However, there is an alternative low level function, namely SignDataPage. This is the only function that calculates a readable MAC without using the ROM-ID. The SignDataPage  function computes the signature and sends the result to the scratchpad.

Because this feature is designed for signing purposes with the MSS, it works exclusively on secret $S0$. Therefore, only the first of the eight secret keys is extractable with this method. See Fig. 8a for the attack procedure. We use another trick to attack the other seven secret keys. After each attack cycle, we generate a new secret using the ComputeNextSecret command. This new secret key is based on the target secret. ComputeNextSecret also does not affect the memory. The key is written to the scratchpad, from where we are able to copy it to the memory region of any other secret.

Next we copy this secret key to the storage area of secret $S0$ (which already has been previously extracted successfully). Since it is now placed in the memory region of secret $S0$, we can perform a signing procedure with the method described above. However the operation is based on the target secrets $S1-S7$. Since it is a concatenation of several SHA-1 functions, we have generated a data path. The concept is based on the principle of a modified rainbow table attack. Figure 8b illustrates the required steps for an attack on secrets $S1-S7$. As a consequence, the secret key computation must also recalculate this path. The time required for the resolution of all secret keys is still negligible.

5 iButton Emulator for Security Evaluation

Since the ROM-ID is unique, and the Write Cycle Counter is not resettable by our attack, we can not use this token for mounting a replay attack anymore. Both, the ROM-ID and WCCs are relevant in all SHA-1 operations used by an authentication protocol. The counter is automatically incremented by the device, and therefore, is detectable by the authentication protocol.

FPGA-based iButton Emulator. We decided to realize a dedicated FPGA-based iButton emulator. With this approach, we have all the freedom, e.g., to set ROM-ID arbitrarily and the Write Cycle Counter can be modified easily. The protocol sequence has some points that make a software emulation (using a micro-controller) extremely difficult. The whole process needs to happen very quickly, only the small temporal gaps between two-bit I/Os are available for software emulation. The problem drastically increases when the system uses the so-called ‘overdrive mode’. Here, the timings are at least 10-times faster.

It is based only on the data sheet and not on any evidence or data that have been obtained from the reverse engineering. The emulator is designed in a way, that has an optimal performance while not need a large and expensive FPGA.

Our implementation provides some additional features: We added special functionality of specific 1-Wire commands that are neither in the original design nor in another one-wire chip. The first feature is that the read memory command allows to read the protected memory areas and does not lead to 0xFF as expected for origin iButton. Second, we added two new functions to the iButton implementation, namely the Write Memory and Write ROM command. The Write Memory feature gives unrestricted and random byte-write access to the entire SRAM of the emulator, while the Write ROM command allows changing the ROM-ID.

Fig. 9.

Maxim DSECASH reference architecture and FPGA iButton emulator

DSECASH Micropayment Reference Architecture. The FPGA-based attack platform is shown in Fig. 9. It was tested on Maxims DSECASH eCash evaluation system [18]. The evaluation kit consists of an eCash evaluation board, a 1-Wire bus master for the PC, some iButtons and various accessories. The eCash Board is a fully functional payment system and proposed as a reference architecture for micropayment applications by the manufacturer. We emphasize, that the iButton emulator works perfectly with the original, absolutely unchanged DSECASH reference design. Assuming that micropayment systems, such as the Akbil metropolitan transportation system [19] or ticketing machines [2], have a similar architecture, our attack should be easily adaptable to the specific application settings.

6 Conclusion

The security analysis presented in this paper clearly show the vulnerability of the Secure iButton DS1963S model. We presented a differential fault attack on the SHA-1-enabled iButton, including the circumvention of the tamper protection mechanisms. We were able to break the most important requirement of iButtons, namely to guarantee integrity and confidentiality of the secrets UAS, MSS and MAS. Our methods allow a key extraction and an infinite rollback to the initial state. We demonstrated the feasibility of the attack on a micropayment reference system. The corresponding research is transferable to other real-world products and give essential feedback to the manufacturers and security researchers by pinpointing on critical security weaknesses and vulnerabilities. Our proposed methods are not restricted to iButtons and can also be applied to other similar embedded devices.

Appendices

Attack Related Commands

For our attack, we need a set of relevant 1-wire low-level commands. Those commands are Read Scratchpad, Write Scratpad, Copy Scratchpad, Erase Scratchpad, Read Authenticated Page, Compute First Secret and Compute Next Secret.

Furthermore, the cryptographic engine has seven SHA-1 command functions, namely the Compute First Secret, Compute Next Secret command for generation of new secrets, SignDataPage for signing and Validate Dat aPagefor HMAC verification. Furthermore, the engine offers a set of function to perform random generator operations and generation of challenges. Finally, the command Read Authenticated Page combines a read operation with a CRC and generation of the corresponding HMAC result. For a detailed description of the commands, we refer the interested reader to the iButton standard [8] and [26].

Resolved Secrets S0-S7 (Example)

The following table give an example for resolved secret $S0$ - $S7$ (Fig. 10).

Fig. 10.

Resolved secrets S0-S7 from an iButton DS1963S device

Tamper Protection Milling Aparatus with iButton

Fig. 11.

Milling apparatus with iButton

Akbil Micropayment System for Electronic Ticketing

The Akbil system [29] is an integrated micropayment for electronic tickets used for fare payment in public transport of Istanbul, Turkey. The system is currently being phased out, but still in use. Figure 12 shows a SCU access control gate to the metropolitan transportation system.

Fig. 12.

Akbil SCU access control gate (left) and Ticketing Machine (right)

ROM-ID Reverse Engineering

The figure shows the reverse engineered ROM-ID of a Secure iButton. The ROM-ID layout is reconstructed by the following drawing. Purple spots indicate a laser burned bit lane, representing a set bit value.