EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2

[eneuro]

I don't believe that the designer took any special measures (to the code part) to prevent those kind of attacks.

So far, someone was able only watch osciloscope waveforms and you were not able to guess all numbers needed to unlock safe lock, because of there are so many combinations that small variation in power waveform lets say at nth digit will confuse you and you end only with lost time 

In my opinion, it could be much more interesting watch waveforms of VLF signals from nature to find strange signals in noise than trying to complete mission impossible with power analysis like this 

Anyway, it is interesting from another point of view-howto write MPU code to do NOT give so much fun to make any power analysis attempt and probably simply sensing temperature changes (TRNG) and taking random actions in interrupt generated so often that main code will be interrupted within a few instructions at random intervals should create random power line readings and this is what I want to test in my home security software 
Yep, it can help write better MPU code, but if guys from this established security company didn't wrote this software in a way that pressing any numpads doesn't create random power line response doesn't sounds well and I'd rather never bought his safe lock after watching osciloscope power line waveforms shown in this video, so yeah it can help find better security company and write better own software.
Good job overall @EEVBLOG 

[eneuro]

it may be possible to tell if how many of the leading digits entered are correct.

What about my example pseudo-code

Code: [Select]

char[6] correct = “123456”
char[6] entered = “314159”
bool isok= true;

bool check_code() {
    for (i=0; i<6; i++){
        if (correct[i] != entered[i]) {
          isok= isok & false;           
        } else {
           isok= isok & true;  // :P
        }

    }
    return isok;
}
Simply, show me other successfull power line analysis with.. source code writen by... noob, else probably you are loosing your time or... learning howto use your scope trying catch those power line waveforms

[miguelvp]

it may be possible to tell if how many of the leading digits entered are correct.

What about my example pseudo-code

Code: [Select]

char[6] correct = “123456”
char[6] entered = “314159”
bool isok= true;

bool check_code() {
    for (i=0; i<6; i++){
        if (correct[i] != entered[i]) {
          isok= isok & false;           
        } else {
           isok= isok & true;  // :P
        }

    }
    return isok;
}
Simply, show me other successfull power line analysis with.. source code writen by... noob, else probably you are loosing your time or... learning howto use your scope trying catch those power line waveforms

With that code they just need to try only 10 combinations since only the last digit has to be correct, no need for power analysis.

Nevermind, it's an and I missed it.

Edit: But power analysis might be feasible since doing an and with true might require different power level than doing an and with false.

[eneuro]

Nevermind, it's an and I missed it.

No problem. People and "big" car manufacturers has bigger security issues right now than guessing 6 digit safe lock code

I hope none of EEVBLog member is "lucky" owner of this hacked car 

Chrysler recalls 1.4 million hackable cars

Chrysler is recalling 1.4 million vehicles that can be remotely hacked over the Internet.

Jeep remotely hacked at 100 km/h

[miguelvp]

One problem with

Code: [Select]

        if (correct[i] != entered[i]) {
          isok= isok & false;           
        } else {
           isok= isok & true;  // :P
        }

Valid digits will have different execution times than invalid ones due to the branch caused by the comparison result.
So timing the power levels will tell you if you have none right or some right, then it's just a MasterMind game

[DanielS]

Anyway, it is interesting from another point of view-howto write MPU code to do NOT give so much fun to make any power analysis attempt and probably simply sensing temperature changes (TRNG) and taking random actions in interrupt generated so often that main code will be interrupted within a few instructions at random intervals should create random power line readings and this is what I want to test in my home security software 

There is no need to generate random events. As someone else wrote earlier, instead of doing plain-text match check, you can hash the key presses and compare against the key hash and add a "salt" value which may be generated when the password is set so the attacker cannot use a rainbow table of known power draw patterns to break the hash.

[eneuro]

One problem with
...
Valid digits will have different execution times than invalid ones due to the branch caused by the comparison result.

No problem-I dign't optimized this code-you should write such critical parts of code in assembler, since C compiler might optimize and completely remove this part of source code, since it doesnt chang elogical value 

Code: [Select]

isok= isok & true;  // :P
Anyway it can be rewriten as, but of couse written in assembler, so NOP instructions can be added to get exactly the same execution time in those two cases 

Code: [Select]

        if (correct[i] != entered[i])
          isok= isok & false;           
        }
        if (correct[i] == entered[i])
           isok= isok & true;  // :P
        }
Of course code above will be optimized, so as I said assembler statements have to be used to avoid any optimizations

As someone else wrote earlier, instead of doing plain-text match check, you can hash the key presses and compare against the key hash and add a "salt" value

Of course, only NOOB could write security software with password stored in MPU memory in clear form, so no chance to get anything interesting based on execution times differencies during enetring password 

[EEVblog]

How about a theory that the various (non-repeateable) waveforms might be caused by varying time between keypresses ?
(What struck me with that idea is that you reach with your right hand to get the scope back into single-shot).

This.

It seemed too repeatable for that to be the case. I did more off-camera.

[PA0PBZ]

How about a theory that the various (non-repeateable) waveforms might be caused by varying time between keypresses ?
(What struck me with that idea is that you reach with your right hand to get the scope back into single-shot).

This.

It seemed too repeatable for that to be the case. I did more off-camera.

I was not thinking about the good key versus bad key waveform but about the different waveforms you get for good key.

[wreeve]

Dave; if you did crack this with a simple resistor and 'scope would you publish? From what you said quite a few of these safes out in the wild. I am interested in the moral stand-point here.

[Fungus]

Dave; if you did crack this with a simple resistor and 'scope would you publish? From what you said quite a few of these safes out in the wild. I am interested in the moral stand-point here.

I certainly would, and I hope Dave would too.

So far Dave hasn't done anything that millions of other people couldn't have tried. If there's a vulnerability at this level of obviousness then:
a) The crooks already know it.
b) The manufacturers deserve to have their company shut down.

PS: If you want to know the lengths people go to to crack stuff then watch some of the "DEFCON" videos on youtube. You might read about Playstation/Xbox hacks in the press but the effort that goes into those hacks is astonishing.

eg.

[Fungus]

Or this one:



Quite incredible.

[Fungus]

Or this one - hacking the Xbox TPM:



So much work...manually putting in 'bodge wires' on the chip die, all through a wire mesh that zaps the chip if you break it.

[Kleinstein]

So the vulnarability helps to get first 5 digits - possibly within something like 20 min average 40 min worst case. For the last digit you still have to test without help - so after 3 tries you get the time penelty: still about 30% chance to get the right code by that time. It depends how the safe reacts an the 4 th and furhter wrong entries: it may already give an even longer timeout after number 4, or just after number 6.

There is also the question if removing the battery may restart the sequence, or possibly need an inital waiting time of maybe 30 min or so - which would be good.

[Badger]

One problem with
...
Valid digits will have different execution times than invalid ones due to the branch caused by the comparison result.

No problem-I dign't optimized this code-you should write such critical parts of code in assembler, since C compiler might optimize and completely remove this part of source code, since it doesnt chang elogical value 

Code: [Select]

isok= isok & true;  // :P
Anyway it can be rewriten as, but of couse written in assembler, so NOP instructions can be added to get exactly the same execution time in those two cases 

Code: [Select]

        if (correct[i] != entered[i])
          isok= isok & false;           
        }
        if (correct[i] == entered[i])
           isok= isok & true;  // :P
        }
Of course code above will be optimized, so as I said assembler statements have to be used to avoid any optimizations

As someone else wrote earlier, instead of doing plain-text match check, you can hash the key presses and compare against the key hash and add a "salt" value

Of course, only NOOB could write security software with password stored in MPU memory in clear form, so no chance to get anything interesting based on execution times differencies during enetring password 

If you were trying to show timing / power resistant code, this would have been a bettter example:

Code: [Select]

bool ok = true;
for (i=0;i<6;i++)
    ok &&= (correct[i] == entered[i])
return ok

From what little I can understand of your posts, you've missed the point; whether it's possible to write timing / power attack resistant code is irrelevant.

Who knows how this specific system is implemented? Do you know the designers were careful to avoid code timing / powerline attacks? I strongly suspect not.

The entire safe logic could be comfortably implemented in a cheap 8-bit micro and it only needs to handle a single user. The micro is on the "secure" side of the safe - there could well be no hashing or salting. This is a minimal, commodity electonic device - not a full-blown unix system.

Whether it's possible to measure the subtle time differences on a scope... well, I think that's unlikely. I'd like to see Dave try though - please have a look at any differences in behaviour after entire codes - correct, fully incorrect and incorrect but starting with correct digits - have been entered.

[Bud]

I used the Rigol because it was right there at the time. It also probably helps that is has a "low noise" 500uV front end the others don't.

This sucker does not have it either. The 500uV thingy is not more than a marketing gimmick. It is a Digital Zoom, NOT a proper amplification range. From the attached pictures it can be seen that 500uV/ setting has twice as less ADC steps than on 1mV/ (or any other higher input range, I have verified). What rigol did on 500uV they just stretched by 200% the data sampled at 1mV per division. And they even did not bother interpolating it to at least look better on the screen. The 500uV/ display contains NO more details about the signal than 1mV/. And everyone sucked their BS up.

[DanielS]

Whether it's possible to measure the subtle time differences on a scope... well, I think that's unlikely.

The mask-programmable controller in there runs at maybe a few MHz and 2-4 cycles per instruction. Timing analysis at somewhere in the neighborhood of 1MIPS should not be particularly difficult as long as you manage to get a decent amplitude signal to look at. Here though, what Dave sees is only 20ms long dips with no distinct features in them aside from the RC filter waveform shape from the shunt measurement resistor and the lock's power filtering caps.

[eneuro]

This is a minimal, commodity electonic device - not a full-blown unix system.

To compute MD5 on 8bit MPU like tiny ATTiny85 less than 1KB of code needed, so no need for any Unix systems 

[f4eru]

I am interested in the moral stand-point here.

look at responsible disclosure practices....

https://en.wikipedia.org/wiki/Responsible_disclosure

[Fungus]

I am interested in the moral stand-point here.

look at responsible disclosure practices....

https://en.wikipedia.org/wiki/Responsible_disclosure

That's for software. Safe manufacturers can't really issue a patch for people to download.

[dgtl]

For even better constant-time behaviour, you can avoid any conditionals by using XOR operator:

Code: [Select]

char result=0;
for (i=0;i<6;i++)
    result |= (correct[i] ^ entered[i]);
return result==0


[Fungus]

For even better constant-time behaviour, you can avoid any conditionals by using XOR operator:

Code: [Select]

char result=0;
for (i=0;i<6;i++)
    result |= (correct[i] ^ entered[i]);
return result==0


Nope. That could lead to a lot of false positives (when two errors give the same result they cancel out to zero).

There's all sorts of CRCs and hashes you could use and get constant time, XOR isn't one of them.

[dgtl]

Perhaps I'm misunderstanding your comment. Using ORed byte-wise XOR to compare 2 memory areas in a time-constant fashion is a quite common technique, ie:
BSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/string/consttime_memequal.c?rev=1.4&content-type=text/x-cvsweb-markup
Linux: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/crypto/memneq.c#n82
The idea is not CRCing the words and comparing CRCs; it is still byte-wise comparision. XOR result is one iff the operands are inequal. The results are ORed together and finally the comparision to zero checks that none of the XOR checks triggered inequality. Of course, this solution only helps for timing attacks when comparing two memory segments both in memory. It still leaves a lot of vulnerabilities open, ie power analysis during comparision; flash read vulnerabilities; brute force vulnerabilities etc.

[helius]

Nope. That could lead to a lot of false positives (when two errors give the same result they cancel out to zero).

  A &cplus; B ⇔ ¬(A ≡ B)
∴ (A &cplus; B)=0 ⇔ A=B

[Fungus]

Nope. That could lead to a lot of false positives (when two errors give the same result they cancel out to zero).

  A &cplus; B ⇔ ¬(A ≡ B)
∴ (A &cplus; B)=0 ⇔ A=B

My bad, I misread the code.   

Perhaps I'm misunderstanding your comment. Using ORed byte-wise XOR to compare 2 memory areas in a time-constant fashion is a quite common technique, ie:

Yep, you're right.