EEVblog #771 - Electronic Safe Lock Powerline Attack Part 2 - Page 1
Forum section: electronics / general

author: EEVblog
author_rank: Unknown
timestamp: July 24, 2015, 12:01:23 am
content: 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

author: miguelvp
author_rank: Super Contributor
timestamp: July 24, 2015, 02:03:49 am
content: 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.

author: Xenon Photon
author_rank: Unknown
timestamp: July 24, 2015, 04:47:10 am
content: 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?Quote from: EEVblog on July 06, 2015, 10:32:10 am

author: miguelvp
author_rank: Super Contributor
timestamp: July 24, 2015, 05:11:04 am
content: 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.

author: Fungus
author_rank: Super Contributor
timestamp: July 24, 2015, 06:02:58 am
content: 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.

author: EEVblog
author_rank: Unknown
timestamp: July 24, 2015, 07:08:26 am
content: Quote from: Fungus on July 24, 2015, 06:02:58 amI like the convenience and obviousness of it, I think it's just a bit fiddly.

author: firewalker
author_rank: Super Contributor
timestamp: July 24, 2015, 07:16:42 am
content: I don't believe that the designer took any special measures (to the code part) to prevent those kind of attacks.Alexander.

author: hendorog
author_rank: Super Contributor
timestamp: July 24, 2015, 07:20:11 am
content: QuoteIt's slightly more reliable to push and hold the knob in while highlighting the option. Then release it to select.

author: Fungus
author_rank: Super Contributor
timestamp: July 24, 2015, 08:39:58 am
content: Quote from: EEVblog on July 24, 2015, 07:08:26 amThere's no reason why they can't do it both ways (push knobormenu button)- makeeverybodyhappy.

author: Hoodaly
author_rank: Newbie
timestamp: July 24, 2015, 08:51:50 am
content: 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.

author: f4eru
author_rank: Super Contributor
timestamp: July 24, 2015, 08:52:57 am
content: 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 password3) 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 cycleThe 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.

author: wreeve
author_rank: Unknown
timestamp: July 24, 2015, 11:13:54 am
content: Why use the Rigol when you have Tek and Agilent on the shelf....are you on commission Dave?

author: dr.diesel
author_rank: Super Contributor
timestamp: July 24, 2015, 11:23:11 am
content: Quote from: wreeve on July 24, 2015, 11:13:54 am

author: Wilksey
author_rank: Super Contributor
timestamp: July 24, 2015, 11:31:02 am
content: 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.

author: wreeve
author_rank: Unknown
timestamp: July 24, 2015, 12:15:50 pm
content: 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 :-)

author: EEVblog
author_rank: Unknown
timestamp: July 24, 2015, 12:20:56 pm
content: Quote from: wreeve on July 24, 2015, 11:13:54 amNo I'm not on commission. Kinda obvious i thought when I slag off the dicky adjustment knob and slow horizonal controlI 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?

author: wreeve
author_rank: Unknown
timestamp: July 24, 2015, 12:25:10 pm
content: Quote from: EEVblog on July 24, 2015, 12:20:56 pmSo 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!

author: Muttley Snickers
author_rank: Unknown
timestamp: July 24, 2015, 12:49:21 pm
content: 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

author: apis
author_rank: Super Contributor
timestamp: July 24, 2015, 01:21:13 pm
content: Quote from: miguelvp on July 24, 2015, 02:03:49 amIF 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.

author: kubatyszko
author_rank: Unknown
timestamp: July 24, 2015, 02:23:42 pm
content: 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).

author: coflynn
author_rank: Regular Contributor
timestamp: July 24, 2015, 07:37:19 pm
content: 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).

author: Matje
author_rank: Regular Contributor
timestamp: July 24, 2015, 08:03:10 pm
content: 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?

author: PA0PBZ
author_rank: Super Contributor
timestamp: July 24, 2015, 08:46:39 pm
content: Quote from: kubatyszko on July 24, 2015, 02:23:42 pmThis.

author: AF6LJ
author_rank: Unknown
timestamp: July 24, 2015, 09:35:51 pm
content: 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.

author: Badger
author_rank: Newbie
timestamp: July 24, 2015, 09:36:50 pm
content: 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 correctexample pseudo-codeCode:char correct = “123456”char 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 != entered)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.

author: eneuro
author_rank: Super Contributor
timestamp: July 24, 2015, 10:56:45 pm
content: Quote from: firewalker on July 24, 2015, 07:16:42 amSo 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 timeIn 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 thisAnyway, 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 softwareYep, 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

author: eneuro
author_rank: Super Contributor
timestamp: July 24, 2015, 11:35:35 pm
content: Quote from: Badger on July 24, 2015, 09:36:50 pmWhat about my example pseudo-codeCode:char correct = “123456”char entered = “314159”bool isok= true;bool check_code() {for (i=0; i<6; i++){if (correct != entered) {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

author: miguelvp
author_rank: Super Contributor
timestamp: July 24, 2015, 11:46:48 pm
content: Quote from: eneuro on July 24, 2015, 11:35:35 pmWith 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.

author: eneuro
author_rank: Super Contributor
timestamp: July 25, 2015, 12:09:32 am
content: Quote from: miguelvp on July 24, 2015, 11:46:48 pmNo problem. People and "big" car manufacturers has bigger security issues right now than guessing 6 digit safe lock codeI hope none of EEVBLog member is "lucky" owner of this hacked carChrysler recalls 1.4 million hackable carsQuoteJeep remotely hacked at 100 km/h

author: miguelvp
author_rank: Super Contributor
timestamp: July 25, 2015, 12:34:23 am
content: One problem withCode:if (correct != entered) {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 aMasterMindgame

author: DanielS
author_rank: Frequent Contributor
timestamp: July 25, 2015, 02:00:48 am
content: Quote from: eneuro on July 24, 2015, 10:56:45 pmThere 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.

author: eneuro
author_rank: Super Contributor
timestamp: July 25, 2015, 07:36:07 am
content: Quote from: miguelvp on July 25, 2015, 12:34:23 amNo 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 valueCode:isok= isok & true; // :PAnyway 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 casesCode:if (correct != entered)isok= isok & false;}if (correct == entered)isok= isok & true; // :P}Of course code above will be optimized, so as I said assembler statements have to be used to avoid any optimizationsQuote from: DanielS on July 25, 2015, 02:00:48 amOf 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

author: EEVblog
author_rank: Unknown
timestamp: July 25, 2015, 07:43:35 am
content: Quote from: PA0PBZ on July 24, 2015, 08:46:39 pmIt seemed too repeatable for that to be the case. I did more off-camera.

author: PA0PBZ
author_rank: Super Contributor
timestamp: July 25, 2015, 08:13:09 am
content: Quote from: EEVblog on July 25, 2015, 07:43:35 amI was not thinking about the good key versus bad key waveform but about the different waveforms you get for good key.

author: wreeve
author_rank: Unknown
timestamp: July 25, 2015, 09:18:09 am
content: 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.

author: Fungus
author_rank: Super Contributor
timestamp: July 25, 2015, 10:11:27 am
content: Quote from: wreeve on July 25, 2015, 09:18:09 amI 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 manufacturersdeserveto 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.

author: Fungus
author_rank: Super Contributor
timestamp: July 25, 2015, 10:22:53 am
content: Or this one:Quite incredible.

author: Fungus
author_rank: Super Contributor
timestamp: July 25, 2015, 05:32:40 pm
content: 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.

author: Kleinstein
author_rank: Super Contributor
timestamp: July 25, 2015, 07:43:11 pm
content: 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.

author: Badger
author_rank: Newbie
timestamp: July 25, 2015, 11:01:45 pm
content: Quote from: eneuro on July 25, 2015, 07:36:07 amIf you were trying to show timing / power resistant code, this would have been a bettter example:Code:bool ok = true;for (i=0;i<6;i++)ok &&= (correct == entered)return okFrom 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 howthis specific systemis implemented? Do youknowthe 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.

author: Bud
author_rank: Super Contributor
timestamp: July 25, 2015, 11:40:24 pm
content: Quote from: EEVblog on July 24, 2015, 12:20:56 pmThis sucker does not have it either. The 500uV thingy is not more than a marketing gimmick. It is aDigital 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.

author: DanielS
author_rank: Frequent Contributor
timestamp: July 26, 2015, 05:46:04 am
content: Quote from: Badger on July 25, 2015, 11:01:45 pmThe 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.

author: eneuro
author_rank: Super Contributor
timestamp: July 26, 2015, 08:28:30 am
content: Quote from: Badger on July 25, 2015, 11:01:45 pmTo compute MD5 on 8bit MPU like tiny ATTiny85 less than 1KB of code needed, so no need for any Unix systems

author: f4eru
author_rank: Super Contributor
timestamp: July 26, 2015, 09:22:21 pm
content: Quotelook at responsible disclosure practices....https://en.wikipedia.org/wiki/Responsible_disclosure

author: Fungus
author_rank: Super Contributor
timestamp: July 27, 2015, 02:55:58 am
content: Quote from: f4eru on July 26, 2015, 09:22:21 pmThat's for software. Safe manufacturers can't really issue a patch for people to download.

author: dgtl
author_rank: Regular Contributor
timestamp: July 27, 2015, 08:49:47 pm
content: For even better constant-time behaviour, you can avoid any conditionals by using XOR operator:Code:char result=0;for (i=0;i<6;i++)result |= (correct ^ entered);return result==0

author: Fungus
author_rank: Super Contributor
timestamp: July 27, 2015, 09:04:59 pm
content: Quote from: dgtl on July 27, 2015, 08:49:47 pmNope. 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.

author: dgtl
author_rank: Regular Contributor
timestamp: July 27, 2015, 09:58:41 pm
content: 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-markupLinux:http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/crypto/memneq.c#n82The 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.

author: helius
author_rank: Super Contributor
timestamp: July 27, 2015, 11:16:03 pm
content: Quote from: Fungus on July 27, 2015, 09:04:59 pmA &cplus; B &iff; &not;(A &equiv; B)&therefore; (A &cplus; B)=0 &iff; A=B

author: Fungus
author_rank: Super Contributor
timestamp: July 28, 2015, 04:52:04 am
content: Quote from: helius on July 27, 2015, 11:16:03 pmMy bad, I misread the code.Quote from: dgtl on July 27, 2015, 09:58:41 pmYep, you're right.

author: apis
author_rank: Super Contributor
timestamp: July 28, 2015, 02:51:06 pm
content: 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.

author: acourtois
author_rank: Contributor
timestamp: July 28, 2015, 05:56:28 pm
content: 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 001122030405 334455 667788991098 876543 321314151617 181924 252627282920 353637 383930344647 484940 424357585950 516869 606562797073 808471 957174727596- Grab traces of each key-press- Mark the pair of digits that are accepted- You should encounter 8 pauses of 10 minutesSo let's say that unbeknowst to you, the code is 766129You see in your chart that these accepted sequences came up;12 66 76 61 and 29Revisiting the rules at the top, one can deduce easilythat the code cannot be anything else than 766129.In a little more than 1 hour, it's cracked.There is brute forceand there is smart brute force.

author: eneuro
author_rank: Super Contributor
timestamp: July 28, 2015, 07:22:21 pm
content: Quote from: apis on July 28, 2015, 02:51:06 pmLets 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 blockAnother 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 additionallyWhat 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

author: eilize
author_rank: Contributor
timestamp: July 28, 2015, 08:42:03 pm
content: 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 consumptionyou 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 ==1bad cell->value ==0)or you can use NOP to match the same number of instructions.don't you follow a bad path?

author: DanielS
author_rank: Frequent Contributor
timestamp: July 29, 2015, 09:28:51 pm
content: Quote from: apis on July 28, 2015, 02:51:06 pmIf 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.

author: Badger
author_rank: Newbie
timestamp: August 01, 2015, 10:53:31 pm
content: Quote from: eneuro on July 26, 2015, 08:28:30 amDo 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 saltingSalting 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.

author: DanielS
author_rank: Frequent Contributor
timestamp: August 02, 2015, 04:07:58 am
content: Quote from: Badger on August 01, 2015, 10:53:31 pmThose 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.

author: apis
author_rank: Super Contributor
timestamp: August 02, 2015, 08:22:15 pm
content: Quote from: Badger on August 01, 2015, 10:53:31 pmIt 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.Quote from: DanielS on August 02, 2015, 04:07:58 amYou 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 assecurity through obscurityand is generally best avoided since it typically only add system complexity (and thus the risk of making mistakes) without adding any real security.

author: eneuro
author_rank: Super Contributor
timestamp: August 03, 2015, 11:13:50 am
content: Quote from: Badger on August 01, 2015, 10:53:31 pmNope, 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

author: DanielS
author_rank: Frequent Contributor
timestamp: August 03, 2015, 03:09:21 pm
content: Quote from: apis on August 02, 2015, 08:22:15 pmIIRC, 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.

author: apis
author_rank: Super Contributor
timestamp: August 03, 2015, 04:58:08 pm
content: Quote from: DanielS on August 03, 2015, 03:09:21 pmI'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 leakmoreinformation, 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).

author: f4eru
author_rank: Super Contributor
timestamp: August 03, 2015, 05:16:14 pm
content: QuoteI 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.

author: eneuro
author_rank: Super Contributor
timestamp: August 03, 2015, 08:32:23 pm
content: Quote from: apis on August 03, 2015, 04:58:08 pmI'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 glitchinghttp://reverseengineering.stackexchange.com/questions/1698/bypassing-copy-protection-in-microcontrollers-using-glitchingQuoteHowever, 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 locksAnyway, 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 storedQuoteThey 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 lockThat 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 whyHe, 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 !!!

author: apis
author_rank: Super Contributor
timestamp: August 03, 2015, 09:29:11 pm
content: Quote from: eneuro on August 03, 2015, 08:32:23 pmHow 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.

author: DanielS
author_rank: Frequent Contributor
timestamp: August 04, 2015, 10:30:43 am
content: Quote from: apis on August 03, 2015, 09:29:11 pmYes, 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.

author: Badger
author_rank: Newbie
timestamp: August 08, 2015, 09:19:57 pm
content: Quote from: DanielS on August 02, 2015, 04:07:58 amhttps://en.wikipedia.org/wiki/Security_through_obscurity

author: Badger
author_rank: Newbie
timestamp: August 08, 2015, 11:49:22 pm
content: Quote from: eneuro on August 03, 2015, 11:13:50 am1. Whether MD5 can fit is still irrelevant (see last post).2. You still have no explanation of why hashing the passcode is beneficial to securityin 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.