Vida CEM swapping

[RickHaleParker]

Few seconds. I've mentioned a possibility of a side-channel timing attack on BUSY line in my first comment to the thread.

Scroll down the slides, M16 portion is in the middle: http://q3k.org/slides-recon-2018.pdf

17,057,594,037,927,937 * 2 seconds = 34,115,188,075,855,874 seconds = 480,793,563.27 years.

3μs when you get one or more correct or 3μs for each one correct?

If it is 3μs for each one correct. One could get the value of all the bytes by trying strings all the same and then calculating how many are that value. From there it would be a matter of determining the correct order.

[vtl]

Jitter for a next matched byte. 256 * 7 with a good SNR. More rounds to accumulate entropy with a bad SNR, but still not years, days or even hours.

[RickHaleParker]

Jitter for a next matched byte. 256 * 7 with a good SNR. More rounds to accumulate entropy with a bad SNR, but still not years, days or even hours.

For seven bytes a exploiting a phenomenon like that would not make much of a difference. But it is something to look for when cracking longer keys.

[vtl]

I'm not sure I follow you. With a good signal-to-noise ratio (i.e. you can detect the BUSY anomaly right on spot) you need to do only up to 256 * 7 passes.

[RickHaleParker]

I'm not sure I follow you. With a good signal-to-noise ratio (i.e. you can detect the BUSY anomaly right on spot) you need to do only up to 256 * 7 passes.

3μs when you get one or more correct or 3μs for each one correct?

If it is 3μs for each correct number. Try all 00, if the delay increase come out 6μs there are two 00s in the key and so on for all the other 255 numbers. You could determine what the seven members of the key set are in 256 passes or less.

If it is 3μs when you get one or more correct. You can still use this to detect the members of the Key set. Just keep in mind if there is repetition, detection will be less then 7. But that is not a problem you still know what the members of the Key set are.

This reduces the 256 in your calculation to 7 max. Now you know which numbers to try in each position. No wasting passes on at least 249 numbers that are not part of the key. Finding the correct permutation would take not more then 49 ( 7 * 7) passes. 256 + 49 = 305 passes max. A 83% reduction over 256 * 7 = 1792.

[vtl]

Delay exists only if there were no mismatched bytes sent yet. Each byte in ID has to be scanned potentially in the full range, 0 to 255. Up to 256 *7 scans per ID. Most probably, it would need many more scans for entropy, because I run Renesas at full speed, the delay/jitter will be real small. ESP32 can read IO every 0.2us in a tight loop, that would be it's maximum resolution.

[RickHaleParker]

Delay exists only if there were no mismatched bytes sent yet.

You sure about that?

In the side attack description it looks like the author is sending six FF (255) along with the test byte. FF is a member of the 256 member set. FF is a potential match but will be a mismatch in most cases. This is what tipped me off to it might be 3μs for each correct byte.

[vtl]

He measures delay after each byte sent, not sequence.

[RickHaleParker]

He measures delay after each byte sent, not sequence.

Boy I miss the Amiga programmers, Software engineers and Hackers. They were well versed in spoken languages also.

"Thus, we can enumerate all bytes of the key one by one, using the timing difference for each correct byte to reduce our search to just 0x100*7 checks. And we get the key."

How does he deal with repetition? The only thing I can come up with is he runs the test byte through like a Johnson ring counter.

[vtl]

The guy is from Poland, be merciful he speaks any English

My old CEM is not responding even to Renesas E8...