Maker Pro
Maker Pro

Smartcard Chip Hack - Samsung’s S3CC9xx


Aug 24, 2012
Aug 24, 2012
With the deployment of chip-based smart card related technology strongly growing of the past years the relevance of all parties involved in the supply chain to recognize the need for technological sounds solutions is of extreme importance. Of course, with technology advancing also the skills and tool sets of hackers will advance. This typically means that any chip technology at some point will become vulnerable to attacks. When the chip design is of high standards one can expect this to happen only many years after first deployment…with poor chip designs this could happen quite soon. As operational deployments are typically upgrading their chip technology after some 8-10 years they can reasonably expect to stay clean of “hack” situations when using a sound technical chip solution. For those who are not using such sound solutions one can only fear the worst.
A very good example of such “easy to reproduce hack” is the attack that has been done on 2 chips from Samsung’s S3CC9xx family. The chips in question are the S3CC9P9, a product that actually got a hardware certification in France against CC-EAL4+ in 2004 and was also awarded VISA certification later on, and the S3CC9TC, a hardware that was created in 2006, on which reputable manufacturers of smart card operating systems still have many solutions they are actively selling to their customer base today.
The attacks in question concern the hardware DES-coprocessor that is part of the chip hardware. This DES-coprocessor is an integral and critical part of all Samsung products from its S3Cxxxx family and as such one can conclude that the entire S3Cxxxx family is vulnerable to the DES attack.

The hack on Infineon’s SLE66 as well as on some Atmel devices are widely documented on the internet, especially by the FlyLogic blog community (http://www.flylogic .net/blog). The above mentioned “hack” on the Samsung devices is less known and hence some explanation is given below.

The below picture shows an analysis of the Samsung S3CCxxx DES-coprocessor by taking 50k traces of a medium sampling frequency to get an overview of the power profile of its DES calculation. Firstly one can look for correlations with the –known- input and output bytes. This helps to localize the signal of the DES-coprocessor (in circle) in the signal. The second measurement then concentrates on that DES-signal area and takes 400k traces of a higher sampling frequency (which in the end turned out to be completely unnecessary, and ordinary simple portable digital oscilloscope with 200MS/s that can be attached to a PC would have been quite enough). In the second measurement one should increase the voltage scale, as the most relevant information about the DES operation is in the gap with relatively low amplitude. It should be noted that this gap can be seen in a single trace, so software randomization efforts will not be effective as they can be undone with signal processing.


The most important step is to align the traces to the back of the gap, as then the DES-signal is neatly aligned at the end of the gap. The structure in below picture shows that the DES reveals itself already in just a single trace !!!


Even if countermeasures in software had been applied to strengthen the DES-operation they would not really have helped, as signal processing would have undone most of any randomization that could be added here.
Show below is the 32-bit correlation with internal data generated during the DES calculation, when the secret key is known. So this is not an attack as such, but a study of the leakage characteristics The green curve shows the analysis of the last round of the DES, and the brown one is the same for the first round. In each we see 3 peaks, which at first is strange, but when taken together it become clear that you actually see a triple DES calculation, with the scheme encryption-decryption-encryption, all with the same key. The red arrows mark where the leakage is strongest.


The various select functions of the oscilloscope will all reveal a different picture. These will make clear that Samsung did try to introduce countermeasures mainly via a strong timing jitter but that these are very little efficient, as is very clearly visible in the “Hamming Weight Distance” select function, directly after the XOR.
Interestingly, the standard “Kocher” select function does not reveal any signal, so obviously some countermeasures have been built for it.
The picture below is crated using the select function “direct” and the picture after that is showing the select function “Kocher” … simple conclusion is that one needs to look at all select functions, not just one of them !


Shown in below-left picture is the distribution of the subkey ranking for the DES encryption. For a good DES, this distribution has to be centered around the statistical average of 32,5 but this is clearly not the case. It is centered around 22 – and this for as little as 10,000 traces taken ! The more the distribution moves to the left, the weaker the DES is.
For 6 S-boxes out of the 8 the correct subkey is already found within the 10 first subkeys, as shown in the below-right picture. Only S-boxes 3 and 5 are not quite there yet.


In the above-left picture the DES is broken – many tools have found the correct subkeys on the first place in the ranking (i.e. all the way at the left of this diagram). This is for 70k traces, which is close to nothing. Please note that most S-boxes even have their average ranking value already close to 1 now. The picture above-right is just for fun … now almost all tools point at the correct key.
The overall effort for breaking the hardware DES-coprocessor of these certified Samsung chips is relatively low despite the chips having some DPA countermeasures in their design :

The phase of identifying the structure of the DES-coprocessor operation was done with only 50k traces and resulted in a full overview & first analysis … for enough “experienced” attackers this is an effort of < 1 day

Then another 2*10 = 20k traces have been used to attack the DES-coprocessor and analyze/exploit the available data. The entire data analysis took only a few days.

All together it took < 1 week to break the DES-coprocessor …