EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2

[EEVblog]

Dave does some more quick basic testing of the La Gard Basic digital safe lock, for any obvious power line exploits.
Part 1 is here

[miguelvp]

To find out the first 2 digits (if you could tell 100% if the sequence is good or bad)
100*14 seconds (2 second keypresses 10 seconds wait 2 seconds analyze result) (also including 0X as a start sequence)

So that will take 24 minutes max. I guess with an MCU assisting the analysis and timing you could reduce it to  around 20 minutes.

3rd, 4th & 5th digit 140 seconds per digit manually or  2 minutes MCU assisted.

So far 26 minutes worst case MCU assisted or a bit above 30 minutes manually.

The last digit. You get 3 attempts at 42 seconds per attempt, Then wait the penalty time and repeat the next 3 digits, penalty next 3 digits and bingo.

Total, about 32 minutes with the help of the scope to wait for the shutdown, plus add 3 lock downs (15 minutes or 30 minutes depending if it's a 5 minute lock down or a 10 minute one)

So if you are pretty organized and you are unlucky and the last guess is the right one, well about 45 minutes to one hour depending on the lock down time.

But that is "IF" the patterns between right/wrong sequence are more discernible than what it's shown in the video.

[Xenon Photon]

Will the micro rest and clear the incorrect password count or the 5 minutes lockout if you disconnect the 9v battery and discharged (wait for few seconds or short the terminals) the caps?

#Edit - Partially answered before ... but how about the 3 tries before the lockout?Does it record in EEPROM how many wrong passwords are entered?

I did not see a big capacitor inside. It may be possible to override the lockout by disconnecting and reconnecting power, unless the safe does not open for 10 minutes after "replacing the battery".

It doesn't reset, I tried that.
It can't write the timer value to the EEPROM because that would kill it, and can't use SRAM obviously, so it must write one bit to the EEPROM saying it's in lockout mode. Upon power up if that bit it set it waits 5 minutes, otherwise it starts working right away.

[miguelvp]

It would be easier to undo the white knob and let the retaining screw fall inside the safe. That will give you a big hole but not sure if the angle from there to the lock would permit you to drill into the solenoid or if you know the right measurements right on the pin.

Maybe taking out that handle only gives you access to the screw and you have to mechanically rotate it from the outside to get the retaining big screw out.

Then again if you know the dimensions on where to drill you could probably cut the retaining pin going through both plates and the lock enclosure.

Or maybe with an angle to avoid the extra plate to make it easier.

[Fungus]

I've mentioned several times that pushing the multi-function knob to set values is a huge fail. Good to see that Dave agrees.

PS: They should change it so you can press the corresponding menu button again to select the value.

[EEVblog]

I've mentioned several times that pushing the multi-function knob to set values is a huge fail. Good to see that Dave agrees.

I like the convenience and obviousness of it, I think it's just a bit fiddly.

[firewalker]

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

Alexander.

[hendorog]

I've mentioned several times that pushing the multi-function knob to set values is a huge fail. Good to see that Dave agrees.

I like the convenience and obviousness of it, I think it's just a bit fiddly.

It's slightly more reliable to push and hold the knob in while highlighting the option. Then release it to select.

[Fungus]

I've mentioned several times that pushing the multi-function knob to set values is a huge fail. Good to see that Dave agrees.

I like the convenience and obviousness of it, I think it's just a bit fiddly.

There's no reason why they can't do it both ways (push knob or menu button)- make everybody happy.

[Hoodaly]

I think that the pattern is very clear from the measurements you made:
On a button press we see a medium dip, then a big dip. If the digit is wrong, we immediately get the huge dip from the beep. If the digit is right, we have a few (like one or two) cycles before the huge dip. IIRC that's consistent with all your data.

[f4eru]

3 possible ways to code that :
1) The SW compares each digit press on the fly (wrong implementation, security wise)
2) the SW stores the sequence in RAM, then, on the last digit pressed, compares the whole sequence to the cleartext password
3) the SW stores the sequence in RAM, then, on the last digit pressed, hashes it, then compares the whole sequence to the hash of the password. The hash should also include a salt that varies for each safe, and should not be stored in the eeprom.

The right way to implement is the no. 3.
This resists even if you could read out the data on the SPI eeprom (which is perhaps feasible, but not with the 8 bit A/D of a scope)

The way no. 2 can be broken if the compare function is not constant time. But the measurement time base must be precise to a uC cycle

The way no.1 is easy to break.

The peaks in the waveforms you show seem to be waking up cycles, or periodic interrups of the micro. Probably only one "interrupt" every two can take key presses, so you see differences based on which of those two inteerups you hit with your button press. It could be more consistent if the button presses are simulated by HW always at the same time to hit the same "interrupt"

The height of the negative peaks probably shows the execution time of the function.

[wreeve]

Why use the Rigol when you have Tek and Agilent on the shelf....are you on commission Dave?

[dr.diesel]

are you on commission Dave?

    

[Wilksey]

I believe it's so "we" can follow along at home, not everybody has the budget for a Tek or Agilent / KeySight, but the Rigols are generously priced.

[wreeve]

It was clearly frustrating him a few times and that strange different trigger on "0". I would have loved to see one of the other scopes hooked up to see if spending more on the big brands is worth it from a use-ability point of view. I'm certainly not an equipment snob :-)

[EEVblog]

Why use the Rigol when you have Tek and Agilent on the shelf....are you on commission Dave?

No I'm not on commission. Kinda obvious i thought when I slag off the dicky adjustment knob and slow horizonal control
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. The Agilent is 2mV/div.
If I used the Tek or the Keysight, would you also say I'm on commission from them?

[wreeve]

Why use the Rigol when you have Tek and Agilent on the shelf....are you on commission Dave?

No I'm not on commission. Kinda obvious i thought when I slag off the dicky adjustment knob and slow horizonal control
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. The Agilent is 2mV/div.
If I used the Tek or the Keysight, would you also say I'm on commission from them?

So the machine for the job. I hadn't realised they went down to 500uV per division. Sorry about the commission comment, I meant to be flippant!

[Muttley Snickers]

For better or worse and I'm nobody's puppet, most of my education came from this fine group with no strings attached. Check out 35:00 onwards, this documentary series forms part of my professional training.

https://youtu.be/7pZgo5gLIQ0?t=2125

[apis]

So if you are pretty organized and you are unlucky and the last guess is the right one, well about 45 minutes to one hour depending on the lock down time.

But that is "IF" the patterns between right/wrong sequence are more discernible than what it's shown in the video.

IF this works with an one hour worst case, then I would say it's a major vulnerability. It might be faster to open this safe with power-tools but:

• The other safes Dave mentioned in the first video doesn't look so easy.
• There are advantages to be able to open one silently and without a trace.
• You get the code which is a big advantage: then you can open/close the safe at will and the same or similar code might be used elsewhere.

[kubatyszko]

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).

I'm simply thinking that if the micro inside has come decoupling then that definitely has limited capacity - if you wait long enough between keypresses it will deplete and reach into battery for more juice.

To prove or disprove that you would probably need a jig that would press the keys for you and allow for varying the time (up to 10 seconds of course).

[coflynn]

As a note: "0" is the programming mode ("000000"), see the manual posted online. They probably are all different, but for this model it is "0".... might explain the oddity.

Also the keypad has no smarts, it uses resistors to multiplex the data (i.e. based on voltages to determine key-press).

[Matje]

Dave, did you think about using the Waveform Record feature (the segmented memory kind of thing) of the Rigol?

I think it would make for nice comparisons between the waveforms for the keys in a sequence. You could even go full in and use the Waveform Analysis feature to automatically find differences, but for only 5 or 6 frames that is probably overkill.

Might still make for a good real life demonstration of these features?

[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.

[AF6LJ]

Well lets see...
Good supply decoupling, added with what is most likely not a new battery that could be presenting variations in internal resistance. I think power line attacks in this day and age are like chasing windmills.

You need to try and attack it from its emissions.
You might even be able to open this with something as simple as an AM radio tuned to a dead spot in the band to hear the logic noise emitted from the safe.
Van Eck Phreaking.

[Badger]

The current powerline attack approach presupposes the keyed digits are compared against the correct code as each digit is entered. I think it's more likely the entire 6-digit code is compared once the complete sequence has been entered.

I expect the safe software waits for a complete code of 6 digits before checking against the correct combination. This comparison is probably done character-wise from the start of the code so there may be a timing attack there; the comparison takes longer when more digits on the left side are correct

example pseudo-code

Code: [Select]

char[6] correct = “123456”
char[6] entered = “314159”
// function may be susceptible to timing attack as function exits when first incorrect digit is encountered. Execution time is linked to the number of correct digits on the LHS.
bool check_code() {
    for (i=0; i<6; i++){
        if (correct[i] != entered[i])
            return false;
    }
    return true;
}
If it's possible to measure a timing difference in the checking function (e.g. between last button press and uP sleep) it may be possible to tell if how many of the leading digits entered are correct.

[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.   

[apis]

Hashing and salting would normally be the right thing to do. In this case it might make life harder for an attacker perhaps but if the attacker get the hash and the salt it won't work because 6 digits --> 1 000 000 combinations which isn't enough to prevent brute force attack.

[acourtois]

Based on these simples rules ;

- Six digits combinations maximum
- After 3 unsuccesful tries, locks up for 10 minutes
- According to Dave' captured traces;
   - Accepted sequence of 2 # shows definitively different traces than any unaccepted sequences
   - A 10 second delay between key presses allowed

- Print this chart with these sequences of tries
(It might be optimized, I don't know)
123456 678902 001122
030405 334455 667788
991098 876543 321314
151617 181924 252627
282920 353637 383930
344647 484940 424357
585950 516869 606562
797073 808471 957174
727596

- Grab traces of each key-press
- Mark the pair of digits that are accepted

- You should encounter 8 pauses of 10 minutes

So let's say that unbeknowst to you, the code is 766129
You see in your chart that these accepted sequences came up;
12 66 76 61 and 29

Revisiting the rules at the top, one can deduce easily
that the code cannot be anything else than 766129.

In a little more than 1 hour, it's cracked.

There is brute force and there is smart brute force.

[eneuro]

if the attacker get the hash and the salt it won't work

Lets say we hide salt and hash inside 1KB bytes flash, where 20 bytes of hash will be stored not in sequence, but... based on used random (TRNG) salt in those 1024 bytes. maybe in spare time will try estimate number of combinations of possible 20 bytes MD5, assumming that salt will be two times bigger, so 40 bytes -2 bytes to index each of 20 bytes of final MD5sum, so MD5sum will located at (1024-20-40) TRNG bytes indexes and we need 20 to store MD5, but it can be not one salt, but a few and not one MD5, but a few times with encapsulated results from previous MD5. It is interesting how hard it could be to test all possible MD5sums composed of sparse bytes within 1KB flash range, but it can be 4KB easy as well-attecker will see only 1KB of random bits, even if he will be able read somehow flash memory-reading another open safe memory will not help, since each safe MPU will have different bits there and final MD5 sum hidden somewhwere insode this 1KB TRNG bits block 

Another story is attacker have to read somehow MPU memory which will be not possible before it cracks safe code, while MPU is hidden inside and he have to open safe to get access to MPU abnd its flash...but it is OTP MPU additionally 

What can I say... mission impossible, unless someone spends one drink night in the bed with safe owner... who will be forced open the safe to take another bootle of drink kept inside safe 

[eilize]

hello,

i don't see why do you expect a current rise in case where you encode a bad digit.

exeample:

there is a rom, isn't it?
so you can use it + use interrupt (and not polling) to have exactly the same consumption

you use the digit to configure the offset  and use an AND function on the value of the cell's rom you read
(good cell ->value ==1
bad cell->value ==0)


or you can use NOP to match the same number of instructions.


don't you follow a bad path?

[DanielS]

Hashing and salting would normally be the right thing to do. In this case it might make life harder for an attacker perhaps but if the attacker get the hash and the salt it won't work because 6 digits --> 1 000 000 combinations which isn't enough to prevent brute force attack.

If you are somehow able to read the salt and hash data, you are also able to read whatever alternate representation of the correct key sequence may have been stored. The point of the hash is to eliminate any easily identifiable deterministic timing or macroscopic power variation related to any specific key sequence.

If the safe controller reads and compares the hash one byte at a time, then you will need a minimum of 16 failed attempts to read all 16 bytes of a 128bits MD5.

Another complication is that you need perfect knowledge of how the hash algorithm is implemented in order to do an offline attack. How does the salt gets mixed with input data? Which has function is used? Did the hash function use standard coefficients? Did it used the standard number of rounds? Is there any post-processing of the hash output? As soon as any of these differ by even one bit from your offline attack model, your offline brute force attack fails - the solutions you find offline won't match.

[Badger]

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

Do you include "face palm" smilies in every post?

You missed the point again I didn't suggest it isn't possible to implement hashing (or salting) on a low-end MCU.

My point is that the attacks hashing (and salting) of passwords mitigate are mostly irrelevant on this platform; there's no good reason to expect that's done here.

Password hashing: useful / necessary if you wish to stop the actual password from being compromised when an attacker gains access to one or more users' credentials - the attacker only get the hash and not the password. Probably irrelevant here because:
 1 the password can be stored on the secure side of the safe in a simple keypad-only system with a very small attack surface. In this case, if an attacker is able to gain access a stored password or hash, they're in the safe and the security has already been broken.
 2 the passcode space is susceptible to cheap forward search given its only 6 digits. If a hash was compromised, the passcode can be calculated from it.
 3 Hashing does not magically make a system immune to side-channel attacks. A hash function - and the subsequent comparison againt the correct value - would have to be coded to minimise or avoid such attacks. Coding a side-channel-immune password comparison is probably easier (if the designers even bothered to do that).

Password salting Salting prevents a  single forward search (i.e. brute force) attempt on a hashed password being used to attack multiple passwords concurrently. The safe only has one password. Relevant on web services / multi user OSs /etc but not on a safe with one password.

If the safe doesn't yield to side-channel attack, I'll bet it's because of more mundane factors such as input power supply filtering and not how the software's implemented.

[DanielS]

2 the passcode space is susceptible to cheap forward search given its only 6 digits. If a hash was compromised, the passcode can be calculated from it.
 3 Hashing does not magically make a system immune to side-channel attacks. A hash function - and the subsequent comparison againt the correct value - would have to be coded to minimise or avoid such attacks. Coding a side-channel-immune password comparison is probably easier (if the designers even bothered to do that).

Those only work if the exact hash function is known. On operating systems and network protocols, all participating systems must agree on which hash algorithms to use and produce exact results out of the same input in order to interact. In self-contained systems, the hash only needs to be coherent within said system. Possessing a copy of the hash and salt does you no good if the exact hash function is unknown.

Side-channel attacks on SSL are possible only because every minute detail of SSL or any other standard are known to the attacker.

[apis]

Password salting Salting prevents a  single forward search (i.e. brute force) attempt on a hashed password being used to attack multiple passwords concurrently. The safe only has one password. Relevant on web services / multi user OSs /etc but not on a safe with one password.

It also helps if there is only one password since attackers typically have precomputed database of common password/hash combinations, so you should always add a salt when hashing passwords.

Those only work if the exact hash function is known.

You should almost always assume the attacker knows all the details of the system. Information will either leak to the attacker, or as in this case, the attacker has access to the hardware. If Dave was sufficiency motivated he could trace out the circuit and read the program from the micro-controller as well as any flash data and determine exactly how everything works. That is more or less always the case unless it's a one-off system that only one person has access to. What you are suggesting is known as security through obscurity and is generally best avoided since it typically only add system complexity (and thus the risk of making mistakes) without adding any real security.

[eneuro]

My point is that the attacks hashing (and salting) of passwords mitigate are mostly irrelevant on this platform; there's no good reason to expect that's done here.

Nope, there is reason to expect some quality since this lock was made not by China NONAME, but company which has experience in this field.
While I've shown that MD5 could be easy implemented even on low cost 8 pin ATTiny85 with 8KB of flash, there is a chance they did it right and maybe you watched too many James Bond films if you think you could crack this safe lock within hours or so

[DanielS]

If Dave was sufficiency motivated he could trace out the circuit and read the program from the micro-controller as well as any flash data and determine exactly how everything works.

IIRC, Dave said the microcontroller appeared to be an old mask-programmable ROM type. Good luck reading the program off of that. Much simpler and cheaper to beat the heck out of the safe.

[apis]

If Dave was sufficiency motivated he could trace out the circuit and read the program from the micro-controller as well as any flash data and determine exactly how everything works.

IIRC, Dave said the microcontroller appeared to be an old mask-programmable ROM type. Good luck reading the program off of that. Much simpler and cheaper to beat the heck out of the safe.

I'm speaking generally with regard to security enginering, I don't think they have bothered to hash or encrypt anything in this particular case. It always comes down to what kind of effort you expect an attacker to be willing to make.

I think you underestimate how much effort people put into reverse enginering stuff (not simply to defeat security but also to keep track of the competition) and you underestimate how hard it would be to read the program in that mcu. It's an old chip, probably withouth any security features. I'm guessing it would be trivial with the right equipment and it might be trivial even without fancy equpment (but I'm not in a possition to prove it so we'll have to leave it at that. Fungus posted some interesting defcon videos that might give you a clue though.) Breaking the safe open would be easier in this case but you don't know where else this lock is used and what it's protecting. If you reverse engineer one of these locks you have reverse engineered all of them and it might well be worth the effort to many people.

The arrogant attitude of people who design stuff that "no-one would go through the trouble or be smart enough to decode a system" just because you couldn't is probably one of the main reasons why many security systems are so crappy. You should always assume the attacker knows how the system works and is smarter than you are. Analyse all attack vectors and make sure they meet the specifications you are designing for, don't rely on the attacker not figuring out you hid the key under the doormat.

The biggest problem (IMO) with adding obfuscating code in this case is that you risk to inadvertently leak more information, not less because more processing means you need to use more power and the processor generates more RF, etc. A more complicated system makes it easier to screw up, so why bother unless there is a clear benefit to doing so (KISS).

[f4eru]

My point is that the attacks hashing (and salting) of passwords mitigate are mostly irrelevant on this platform; there's no good reason to expect that's done here.

I woudn't be so shure of that.
The contents of the eeprom are passed to the MCU via a SPI. The EMC of that SPI could potentially be snooped on if there is a capacitive coupling to the wires going "outside".
Hashing and salting would very well prevent this atack, especially if the microcontroller serial number is used as salt, and therefore not visible on the SPI.

[eneuro]

It's an old chip, probably withouth any security features. I'm guessing it would be trivial with the right equipment and it might be trivial even without fancy equpment (but

I'm really interested in using (old) ATTiny85 MPU at home automation security system and that is why I'm interested in MD5 implementation and possibility to read back MPU flash, so quick research leads to this:
Bypassing copy protection in microcontrollers using glitching
http://reverseengineering.stackexchange.com/questions/1698/bypassing-copy-protection-in-microcontrollers-using-glitching

From time to time, forum posts are made by companies offering their services to read out protected ATmega chips. There are also sites, generally .ru, that offer these services. Price tends to be around $500-$1500 with a turnaround time of a few weeks.

I suspect at these costs, they are not decapsulating the chip and using a laser probe to reset the fuse bits. I have queried if they return the chip undamaged, but did not get a response.

However, even if the costs to read out protected AVR from flash read using ISP (lock bits) could be acceptable, still in the case of the safe lock, while MPU is inside it doesn't help to much if you brake sample safe MPU and read its code when this code will be different in other safe locks 

Anyway, to make those glitchers work as I read you have to have full control about MPU power, so you have to replace oryginal, so while you have access only to battery, but threre is regulator IC inside safe lock, caps, etc, you can't make successfull glitch sttack to try read MPu flash program code to be able try find place where hashed and salted password is stored 

In order to read out the flash contents for an Atmel AVR ATmega MCU?you can break the master chip. It doesn't return the chip undamaged, but provides the code and program.

They wrote that those services doesn't return you not damaged chip, but provides code and program, so it is not a trivial and probably not possible, when ... you can not send them MPu itself while it is inside safe lock 

That is why, robbers do not loose time to try guess any passwords, but use... explosives to destroy.. ATM.

However this attempt was avarded to epic fail watch why 

He, was lucky he survived this uncontroled expolsion-what a donk? 

And now how professional robbers open ATMs-they even protected adventitious unaware man to keep him in safe place during ATM explosion !!! 

[apis]

However, even if the costs to read out protected AVR from flash read using ISP (lock bits) could be acceptable, still in the case of the safe lock, while MPU is inside it doesn't help to much if you brake sample safe MPU and read its code when this code will be different in other safe locks 

Anyway, to make those glitchers work as I read you have to have full control about MPU power, so you have to replace oryginal, so while you have access only to battery, but threre is regulator IC inside safe lock, caps, etc, you can't make successfull glitch sttack to try read MPu flash program code to be able try find place where hashed and salted password is stored 

How hard it is differs from chip to chip, in some cases it's really easy because you can circumvent the copy protection or reset the read protection fuse with the right signals and voltage levels. In the end you can always decap the chip and circumvent read protection by probing the chip directly. In the video Fungus found a guy explains how he is reverse engineering chips that have a lot of extra security features specifically designed to prevent reverse engineering by decapsulating, but that isn't the case for general purpose mcus like this.

It might be OK to store a salt/serial in the chip if it's not normally accessible. I was talking about reverse engineering a system you have full access to in order to determine the details of how it's working (possibly destructively). In this case, if the attacker has already opened the safe, protecting the password is probably low priority so they might not have done that (but you never know). As for the eeprom leaking out as EMI when read, if that is a problem then hashing might help assuming there is no way for the salt to leak out as well.

Big companies can go to extreme lengths to reverse engineer the competitors products. Car manufacturers completely dissemble and test all parts of their competitors cars routinely to determine their marginal cost and other details for example. And you have to assume information will leak anyway. If it's only you who designed and use the system at home you can get away with hiding the design, but that is generally not the case for commercial products like this lock.

And yes of course, in the end most thiefs are not so clever and will just use powertools, bulldozers, explosives or put a gun to your head anyway. 

But in some cases, especially for networked equipment it can be really important to get the security right.

[DanielS]

In the end you can always decap the chip and circumvent read protection by probing the chip directly.

Yes, given enough time and money, just about anything can be broken into. For a safe like this though, the electronic lock only needs to be good enough to make breaking the safe the conventional way more practical than attacking the MCU.

If you are already going to have to drill through the safe just to insert the EMI probe (the mounting holes should be plugged by bolts and washers) so you can attempt to read the SPI/I2C traffic, you might as well drill the hole in a place where you could directly pick the locking mechanism: measuring the exact location of that little plunger pin so you can drill it out from the front is much simpler than reverse-engineering the MCU. Since the MCU is inside a metal can inside the safe, you may need to drill into the MCU's box to get usable EMI readings anyway.

As far as extreme reverse-engineering and leaks go, how successful have hackers been at reverse-engineering WiFi, 3G and 4G chipsets to create open-source firmware and drivers for them? I do not remember reading about any successful attempts.

[Badger]

2 the passcode space is susceptible to cheap forward search given its only 6 digits. If a hash was compromised, the passcode can be calculated from it.
 3 Hashing does not magically make a system immune to side-channel attacks. A hash function - and the subsequent comparison againt the correct value - would have to be coded to minimise or avoid such attacks. Coding a side-channel-immune password comparison is probably easier (if the designers even bothered to do that).

Those only work if the exact hash function is known. On operating systems and network protocols, all participating systems must agree on which hash algorithms to use and produce exact results out of the same input in order to interact. In self-contained systems, the hash only needs to be coherent within said system. Possessing a copy of the hash and salt does you no good if the exact hash function is unknown.

Side-channel attacks on SSL are possible only because every minute detail of SSL or any other standard are known to the attacker.

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

[Badger]

My point is that the attacks hashing (and salting) of passwords mitigate are mostly irrelevant on this platform; there's no good reason to expect that's done here.

Nope, there is reason to expect some quality since this lock was made not by China NONAME, but company which has experience in this field.
While I've shown that MD5 could be easy implemented even on low cost 8 pin ATTiny85 with 8KB of flash, there is a chance they did it right and maybe you watched too many James Bond films if you think you could crack this safe lock within hours or so

 

1. Whether MD5 can fit is still irrelevant (see last post).
2. You still have no explanation of why hashing the passcode is beneficial to security in this case.
3. Regarding your argument: "there is reason to expect some quality since this lock was made not by China NONAME, but company which has experience in this field."
   a. are you serious?
   b. Closed firmware like this is almost always crap. Assume so until proven otherwise.
   c. See 2.