- Sun Jan 25, 2015 2:51 am
#8139
Hm, this is a weird idea
You could use the RTC RAM area to store the passphrase (either loaded from flash and deleted, or obtained in AP mode, or received from smartlink-like sequence). This way it will survive common "deepsleep" resets (like every 30seconds?).
But this will work only if the attacker is unaware of the idea. If he steals the device (with batteries inside) he could attack it over the JTAG interface. We don't have enough information if the RTC RAM area is accesible over JTAG, or if the JTAG could be disabled with some burn-once fuses.
Still, you have to manage the problem that the user would have to deal with power disconnect - for example, when he replaces the batteries. Maybe this can be solved if you "command" the module (httpd, mqtt, tcp command) to enter "battery replacement mode". This means that it will store the password back to the flash until next power on.
Seem complicate, isn't it?
Security aspects are important. I am not an expert there but I suspect that even without protection of the flash content it would be possible to organize a system where each node has own "client" certificate. I mean with proper system design. So when this module/cerificate is stolen the attacker will get access to a limited subset of the global services - only those that were allowed for the stolen module. And he had phisical access to steal the node that maybe he could do the same things without breaking the flash content?
This should not be a problem - if we look at home security system, there would be several nodes - one keyboard at the front door, and another one to "unlock" the door. Imagine that the "keyboard" is on the outside of the door and could be easily stolen. The unlock node is on the inside and one needs to unlock the door first to see it/access it.
So the thieve steals the keyboard device. Our goal is that he cannot make anything harmful. If he was stanging in front of the door, he could press all the buttons. If he steals this device and moved it to his apartment he could still press buttons and try to brute-force the system. If he analyzes the flash memory he could find out the public IoT broker that we were using in our system, e.g. iot.eclipse.org. So he can connect to this server. Having the security info from the module (WPA, mqtt password, SSL client certificate) he can build up a PC node that runs the brute force algorithm. So he can pass "trial" codes to the internal lock control node. So as long as the internal lock control node is well protected against brute-forcing (e.g. stop listening on third failed code, and ignore everything of 1 hour) we are safe. One could not press buttons more often that once in 300ms so any new code that comes in less that 300ms since the last one is classified as brute-force attempt and enters the one hour dead mode.
But there needs to be a way to "learn" new pin codes for new users. This might provide a backdoor - if the unlock node provides "add new user" service to be used from web front we need additional protection.
In order to have this working we have to be sure that this node is not allowed to access services outside of predefined range. Because in another system there might be another central access control server that received the key codes and in case of match sends "unlock" command to the unlock node. If the theive finds the address (mqtt topic) of unlock he could issue unlock command. So unlock command needs to be protected - it must be accepted only if posted by recognized publisher (node/certificate).
In general, this means that each node in your network needs to have own certificate so the central server (e.g. mqtt broker) is sure that it speaks to the real node (or a complete clone of it).
gwizz wrote:gicho wrote:so if somebody steals your garden light switch and dumps SPI flash on the ESP module, he will only get access to this separate network.
Ok, bear with me if I ask a slightly OT question - but would it be possible to load the passphrase into ram during startup and then overright the flash copy? (and still be able to use this copy to provide encrypted transport?) Then you can have a 'graceful' shutdown option, but otherwise, if bad guys/gals steal your thing, they inevitably take it out of wifi range and then powerdown, loosing the keys to the kingdom!!
I'm not just thinking about Wifi passwords here, but any certificates etc. that are loaded onto devices. Or are there any such security features in the chip itself?
Hm, this is a weird idea
You could use the RTC RAM area to store the passphrase (either loaded from flash and deleted, or obtained in AP mode, or received from smartlink-like sequence). This way it will survive common "deepsleep" resets (like every 30seconds?).But this will work only if the attacker is unaware of the idea. If he steals the device (with batteries inside) he could attack it over the JTAG interface. We don't have enough information if the RTC RAM area is accesible over JTAG, or if the JTAG could be disabled with some burn-once fuses.
Still, you have to manage the problem that the user would have to deal with power disconnect - for example, when he replaces the batteries. Maybe this can be solved if you "command" the module (httpd, mqtt, tcp command) to enter "battery replacement mode". This means that it will store the password back to the flash until next power on.
Seem complicate, isn't it?
Security aspects are important. I am not an expert there but I suspect that even without protection of the flash content it would be possible to organize a system where each node has own "client" certificate. I mean with proper system design. So when this module/cerificate is stolen the attacker will get access to a limited subset of the global services - only those that were allowed for the stolen module. And he had phisical access to steal the node that maybe he could do the same things without breaking the flash content?
This should not be a problem - if we look at home security system, there would be several nodes - one keyboard at the front door, and another one to "unlock" the door. Imagine that the "keyboard" is on the outside of the door and could be easily stolen. The unlock node is on the inside and one needs to unlock the door first to see it/access it.
So the thieve steals the keyboard device. Our goal is that he cannot make anything harmful. If he was stanging in front of the door, he could press all the buttons. If he steals this device and moved it to his apartment he could still press buttons and try to brute-force the system. If he analyzes the flash memory he could find out the public IoT broker that we were using in our system, e.g. iot.eclipse.org. So he can connect to this server. Having the security info from the module (WPA, mqtt password, SSL client certificate) he can build up a PC node that runs the brute force algorithm. So he can pass "trial" codes to the internal lock control node. So as long as the internal lock control node is well protected against brute-forcing (e.g. stop listening on third failed code, and ignore everything of 1 hour) we are safe. One could not press buttons more often that once in 300ms so any new code that comes in less that 300ms since the last one is classified as brute-force attempt and enters the one hour dead mode.
But there needs to be a way to "learn" new pin codes for new users. This might provide a backdoor - if the unlock node provides "add new user" service to be used from web front we need additional protection.
In order to have this working we have to be sure that this node is not allowed to access services outside of predefined range. Because in another system there might be another central access control server that received the key codes and in case of match sends "unlock" command to the unlock node. If the theive finds the address (mqtt topic) of unlock he could issue unlock command. So unlock command needs to be protected - it must be accepted only if posted by recognized publisher (node/certificate).
In general, this means that each node in your network needs to have own certificate so the central server (e.g. mqtt broker) is sure that it speaks to the real node (or a complete clone of it).
