Project topics and materials
Get Complete Project Material File(s) Now! »
Public Phone Cards, the First Mass Market
From 1978 to 1983, the French Direction Générale des Télécommunications1 (Directorate-General for Telecommunications) developed the principle of chip cards as payment cards for public phones in order to cope with phone box vandalism. The German Federal Post Office started a similar project in Germany in 1984-85, although the used technology was different from the French cards. Soon, many other countries followed these initiatives.
The technology inside these chip cards was yet quite basic. For instance on French cards, the chip was indeed only aimed at manipulating a counter stored in its non-volatile memory. The memory bits were incrementally set with the consumption of a given unit of time. Consequently, when the user has consumed all the bought time units, all the memory bits were set and the card was not functional anymore. It is worth noticing that the first bits of the memory were set at manufacturing time in order to prevent the success of an attack aiming at resetting the whole content of the memory. These cards did meet a great success and as much as several hundred million cards were deployed worldwide in the middle of the 90s.
Modern Utilizations: Mobile Phone, Banking, Identity
With the evolution of microelectronic technologies, the microprocessor, or integrated circuit (IC), cards emerged and new utilizations of these so-called smart cards were developed. The tamper resistance of the IC allows to store secrets in the card as if it were a tiny digital safe. The possibility to use this property to store cryptographic keys and even to operate the cryptographic computations inside the card opened a wide range of applications in various fields. This section describes the most popular of these fields of application: banking, mobile communication and identity-related applications. Furthermore, the evolution of contactless communication also brought new possibilities.
Cryptographic Key Recovering and Reverse Engineering
In order to expose the information contained in the side channel leakage, the use of several statistical tools on the measured observations have been considered. The various attacks published [Koc96, KJJ98, BCO04, DPRS11] mainly vary in assumptions on thedata leakage and in the distinguisher used as part of the statistical processing of the side channel leakage sample (usually power consumption and electromagnetic radiation curves). However, the general idea is always to highlight a dependency between the observed side channel and (a part of) the secret that is being manipulated. Figure 2.3, for instance, depicts the result of a Correlation Power Analysis (CPA) intending to exhibit a correlation between the power consumption of the card and a temporary byte which value depends on a secret key byte of the executed AES (Advanced Encryption Standard) [Fed01]. The left graph of Figure 2.3 shows the correlation between the power consumption of the card and hypotheses on the temporary byte depending on the key. One can observe that the correct hypothesis (depicted in black in the figure) presents a strong correlation with the power consumption of the card at a given time. This correlation peak therefore reveals the correct key hypothesis. The right graph of Figure 2.3 shows the number of acquired power consumption curves necessary to have one particular key hypothesis standing out. This correlation convergence curve shows here that 3,000 acquisitions were required to exhibit the correct hypothesis and thus to retrieve the secret key byte. To thwart such attacks, the most used countermeasure consists in breaking the dependency between the manipulated data and the secret key. Such a masking is usually operated by combining the manipulated data with random data, typically with a XOR operation [GP99, AG01]. The notion of High Order SCA (HOSCA) [SP06, CPR07] subsequently appeared, allowing to attack implementations using the masking countermeasure. However, these attacks are more difficult to mount, and the notion of high order masking has been developed against these HOSCA.
Table of contents :
Forewords
I Context and State of the Art
Introduction to Part I
1 Smart Cards in a Nutshell
1.1 A Disputed Invention
1.2 From a Public Phone Card to a Digital Safe
1.3 The Architecture of a Smart Card
2 Hardware-Related Attacks
2.1 Side Channel Analysis
2.2 Fault Attacks on Embedded Systems
3 The Java Card Technology and its Ecosystem
3.1 Java-enabled Smart Cards
3.2 The Security of Java Card Platforms
3.3 The Ecosystem of Java Cards
4 State of the Art of Attacks against Java Cards
4.1 The Open Platform Assumption
4.2 Malicious Application based Attacks
4.3 Ill-formed Application based Attacks
4.4 The Development of Combined Attacks and Mutant Applications
Conclusion to Part I
II Analysis of the Security of Java Cards against Combined Attacks
Introduction to Part II
5 Security Analysis of the Type Safety Property
5.1 Disruption of the checkcast Instruction
5.2 Disruption of the Operand Stack
5.3 Exploitations of the Type Confusions
6 Security Analysis of the Execution Flow Integrity
6.1 Disruption of the Operand Stack on Conditional Branching Instruction
6.2 Multithreaded Corruption of the Execution Context
6.3 Disruption of Exception-Related Mechanisms
7 Security Analysis of the Application Isolation Mechanism
7.1 Questioning the Code Isolation by Abusing Class Loaders
7.2 Circumventing the Application Firewall with Application Replay
7.3 Abuse of Global Arrays
Conclusion to Part II
III Contributions to Enhance the Security of Java Cards
Introduction to Part III
8 Offensive, Defensive and Defending Virtual Machines
8.1 The Offensive and Defensive Virtual Machines
8.2 The Defending Virtual Machine
8.3 Sealing the Exposed Weaknesses in a Defending Virtual Machine
9 Ensuring Type Safety in the Presence of Faults
9.1 Protection of the Operand Stack
9.2 Towards Type-Confusion-Immune and Type-Safe Platforms
10 Securing the Execution Flow
10.1 Enhancing the Security of Conditional Branching Instructions
10.2 Preventing the Interpretation of Injected Code
Conclusion to Part III
Conclusions & Perspectives
Appendices
A Practical Validation of the Fault Model
A.1 The test application.
A.2 Experimental results.
A.3 Conclusions.
B Implementation of the Multithreaded Attack on Java Card 3 Connected Edition
B.1 Array Forgery
B.2 Request Flooding Validation Thread
Publications
Bibliography
