These are chat archives for esp8266/Arduino

2nd
Aug 2015
Michael Miller
@Makuna
Aug 02 2015 00:06
how do I dump one of the sdk routines like ets_isr_attach, so I see what it does (asm only is fine)
Angus Gratton
@projectgus
Aug 02 2015 00:43
that's baded on the RTOS SDK, and Arduino is based on the IoT SDK, it may be somewhat different
s/baded/based/
probonopd
@probonopd
Aug 02 2015 07:26
storing the wlan password on the esp is probably not the best idea; is there a way to increaase security by encrypring/obfuscating it?
remcohn
@remcohn
Aug 02 2015 07:34
encryption is quite useless if the key is also stored on the esp. same goes for obfuscation. but you would already need to read out the flash to do it
probonopd
@probonopd
Aug 02 2015 07:36
yes, reading the flash is trivial. feels almost like putting post-it stickies with the password all around the house.
for me, this is really a concern not to use the esp for home automation...
remcohn
@remcohn
Aug 02 2015 07:36
if someone can phisicaly grab a module to read it out, they might as well grab your ethernet cable and use that
probonopd
@probonopd
Aug 02 2015 07:37
there is truth in that
remcohn
@remcohn
Aug 02 2015 07:39
and basic obfuscation is not that hard. make a few functions that each add 1 letter to the password string, and 'assemble' it that way.
@igrr ah, so i guess the updater is not using the FS for temporary storage, but the remaining bit in the sketch area? meaning that to be able to update it, the max sketch size is 512k? but i guess that can be solved by changing the sketch/FS split in the board file, or is 1M the limit for the sketch size?
Angus Gratton
@projectgus
Aug 02 2015 07:49
basic obfsucation is pretty trivial to reverse as well, after all the same place you dump the password storage region from holds the de-obfuscation code
probonopd
@probonopd
Aug 02 2015 07:53
does the processor have any security functions for things like this?
remcohn
@remcohn
Aug 02 2015 07:54
@projectgus absolutely. but it requires more effort then just dumping the hex file, where if the SSID and password are defined right after eachother, they are very easy to spot
Angus Gratton
@projectgus
Aug 02 2015 07:58
that's true, but - as you already implied - if you already have physical access to the device and have connected a cable to dump the flash, then your attacker is already pretty motivated (and you're already pretty compromised).
remcohn
@remcohn
Aug 02 2015 07:59
@probonopd it does have AES functions (but those are not wrapped for arduino compatibility yet afaik), but they would still need a key. you can make it a bit more difficult again by using the chipID as (part of) the key used to encrypt the password. then a hex dump would not be enough, you would need access to the device. an attacker might just 'dump and return' the device once do you dont notice it missing, but he wont make that mistake a 2nd time. so again, not that usefull. in the end, the software needs access to the key in plain text
probonopd
@probonopd
Aug 02 2015 08:00
@remcohn sounds better than nothing to me
an ESP.scrabmle("key, value); function would be great
remcohn
@remcohn
Aug 02 2015 08:03
i saw functions for MD5, SHA, and AES in the linker list for the SDK, but there is arduino wrapper for them yet, so they would be tricky to use
remcohn
@remcohn
Aug 02 2015 08:05
ah yes, cool :)
Angus Gratton
@projectgus
Aug 02 2015 08:10
sha1 is a hash function, so you can hash your secret but you can't get it back as plaintext
probonopd
@probonopd
Aug 02 2015 08:10
argh. you're right
Angus Gratton
@projectgus
Aug 02 2015 08:11
I think the in-ROM functions only include AES decryption, but the axtls library (libssl in the SDK) has AES
remcohn
@remcohn
Aug 02 2015 08:12
you can XOR with the SHA1 of the deviceID
Angus Gratton
@projectgus
Aug 02 2015 08:20
yeah, ok
does anyone know much about the device ids? do they follow a pattern?
remcohn
@remcohn
Aug 02 2015 09:19
have not looked at them much. Mine is 0xFE5034
thats a nodemcu 0.9 with a datastamp of 05/12/2014
Neil Kolban
@nkolban
Aug 02 2015 15:49
I think the notion behind obfuscation is simply that if one glanced at the data on a screen, one wouldn't see the password then and there ... some some "small" amount of work would be needed to get the clear text password back. Now if you XOR'd the password with your devices Mac address ... that should be more than sufficient (opinion).
Michael Miller
@Makuna
Aug 02 2015 15:52
@nkolban please don't use the mac address, it is public and is is one of the most common data used to try to hack in.
Neil Kolban
@nkolban
Aug 02 2015 15:54
My thinking is that ... today ... the password is kept in flash memory in the clear. If that is true, then XOR'ing the password with the MAC address would obfiscate the password in flash memory. So if someone were to "grab" the data but did not know your MAC address ... then they couldn't figure out the password? The alternative ... for an XOR solution ... would be to XOR it against a constant magic number ... which ... I think would be less obfiscation that XOR against a constant magic number (your MAC address) that is specific to your device ...? Again ... I could be all washed up here ... but that is my thinking ... can you help me see where I am mistaken?
Michael Miller
@Makuna
Aug 02 2015 15:58
The mac address is public is the issue. When your device connects to a router, the mac address is in the packet, unecrypted. Back in the 1990s this was a common technique, and it also become a common vector for attack.
Michael Miller
@Makuna
Aug 02 2015 16:03
Without a TPM feature on the chip silicon, then physical access means total access.
At which point it becomes about how much effort they want to spend.