i am trying to perform an attack on smart card but traces are too much noise please help about it
One way to deal with noise is to collect more traces.
High-security smartcards are protected against power analysis; you’ll waste decades collecting the necessary traces. Of course, there are alternatives available that can accelerate the attack, but they cost a fortune. I’d aim for the RSA5065N-OCXO spectrum analyzer. Remember, this is just one of several high-security smartcard security features, and there are usually several to further complicate and hinder the attack. The RSA5065N-OCXO mentioned in this example can be used to eliminate noise before the signal from the card reaches the oscilloscope’s ADC or chipwhisperer 
i know very well about smart cards but its possible to get keys with power analysis and Glitch attack. Mark my words one day i will show u how get keys from smart cards
@Alex
The problems I mentioned concern cards that protect premium content. They are significantly more secure than Java cards used to protect door locks and the like. Such cards typically employ at least several advanced security measures and are not as easily faulted by glitches as today’s microcontrollers, such as the ESP32 or RP2040. The RP2350 is a step forward, but individual tests have shown that EMFI glitches still operate, but within a much narrower range, so the sensor controlling them isn’t as precise as those found in today’s high-security smartcards. I’ve tested various glitch modifications on today’s smartcards, but unfortunately, I haven’t found a working solution yet. I still have a few ideas I haven’t had time to test. I’m referring to cards from 2010 and 2020.
@Alex If you’re starting with Power Analysys smartcards, you should start by building a hardware clock recovery module. This is the first step. This will give you greater control over the smartcard. For this purpose, you should use an FPGA with a DAC, or ideally, a ready-made SDR. This mechanism shouldn’t rely on a narrow Chebyshev or Butherowrth filter, because smartcards have a highly desynchronized clock. An FPGA FIR filter should be used here. The FPGA with an SDR can then be used to build the rest of the clock recovery modules.
After a year of my experiments:
-
SLE88FX/CX (customized versions) - I managed to bypass the brown-out detector glitch, but the core was still able to detect glitches, suddenly freezing the card’s execution program. I’m 100% sure of this and can confirm it, so it’s a big step forward. The smart card’s production date is around 2010.
-
Some Atmel processors. I suspect it’s one of these processors: AT90SC 144 144T (customized versions) - unfortunately, I haven’t been able to find anything. The brown-out detector is unbeatable for me at this time. The smart card’s production date is around 2010.
Customized versions - these smart cards are custom. You can find Infineons with the same designation on the market, but they won’t be the same.
For my applications, I temporarily used the SmartLeia project, which had some bugs, and I had to fix the code. I had to add additional clock control and a few other peripherals for the trigger, and it worked. It generated glitches for testing on the ATR loop. This was enough for me to confirm whether the glitch was working or not. However, after some time, I decided that in the future I would need something more low-level, and with the added benefit of an FPGA, I chose the RP2040, or even better, the RP2350. My time is limited now, and if I return to this, I’ll do it slowly from time to time, of course, just for fun and learning.
I haven’t tested Power Analysys yet, but I’m convinced that these cards will require a clock recovery mechanism in conjunction with the SAD trigger.
SLE88FX/CX (customized versions) - I managed to bypass the brown-out detector glitch - glitch passed to core but was still detected. the glitch filtering circuit on the VCC line has been omitted by me.I can assume that this is some kind of second additional sensor.
It would be interesting to see your results. But I afraid, existing HW implementation of cryptographic algorithms, at least, AES is masked on modern smart cards. Even if you collect well aligned traces you will not able to recover the correct AES key.
I already faced with masked implementation. There are perfect traces, AES is also perfectly visible…but the key is not recoverable.
I haven’t reached the stage you’re describing yet. In my case, the main problem is the enormous noise added as SNR security. I’ve already largely cleaned up the power line by using optocouplers, but the AES example is still significantly noisy. I suspect the Infineon doesn’t use noise as security at all because it’s sufficiently protected in other directions (duel rail logic and other things). I also don’t think the masking implemented in 2010 is particularly impenetrable. My current target isn’t an Infineon; in the past, I’ve only practiced glitching on an Infineon, but I’ve seen traces that look clean and noise-free, which only confirms my suspicions. 
The photo I attached shows AES128-CBC after initial cleaning, which is still quite noisy. It is also clear that the algorithm peaks do not directly indicate AES rounds, but some kind of curved implementation with additional security 
What is even more strange is that the traces contain minimal jitter, which they shouldn’t - the DUT clock is synchronized with cwlite in this case, this DUT doesn’t use either PLL or internal clock generator, maybe it’s a defect of cwlite, I don’t know.