Secure 5-button keyfob with enclosure (was: 8-button keyfob)
-
@Anticimex Ok, let's take encryption out of the equation. I still don't get it.
As long as the PSK is not transmitted, I don't see how HMAC could be broken. If a soft-signing device is lost, the PSK could be read. But if an ATSHA device is lost, the PSK cannot be read. An attacker could only use the PSK in combination with the fixed ID of that ATSHA; that could be un-whitelisted or blacklisted (I really would like to see blacklisting because of that, I think.)
Can you sketch a valid attack with a known Id, but without a leaked PSK, or a way how my PSK could leak if I generally only expose ATSHA devices?
@elcaron the PSK is programmed into the atsha. If it is stolen, the PSK is still in the atsha. How do you prevent someone from reprogramming your keyfob and use the atsha with your PSK in it? And if you use black listing, how do you ensure the attacker does not simply just use a different serial by customizing the firmware? The attacker does not have to know the PSK in order to use it if he has your keyfob.
-
@MiKa for your USBASP programming problem, you could try to add a pullup resistor for the radio. This should fix your issue. 10k, 56k etc.. between CS line and VCC.
-
@elcaron the PSK is programmed into the atsha. If it is stolen, the PSK is still in the atsha. How do you prevent someone from reprogramming your keyfob and use the atsha with your PSK in it? And if you use black listing, how do you ensure the attacker does not simply just use a different serial by customizing the firmware? The attacker does not have to know the PSK in order to use it if he has your keyfob.
the PSK is programmed into the atsha. If it is stolen, the PSK is still in the atsha.
Of course.
And if you use black listing, how do you ensure the attacker does not simply just use a different serial by customizing the firmware?
My understanding was that the fixed ATSHA ID goes into the signature inside the closed signing process in the ATSHA. So one ATSHA can only provide signatures with its unique, unchangeable id. If signatures with that id are blacklisted, then the ATSHA is worthless.
Is that not the case? Can an ATSHA be used to create a signature with an id that is not it's own? -
-
the PSK is programmed into the atsha. If it is stolen, the PSK is still in the atsha.
Of course.
And if you use black listing, how do you ensure the attacker does not simply just use a different serial by customizing the firmware?
My understanding was that the fixed ATSHA ID goes into the signature inside the closed signing process in the ATSHA. So one ATSHA can only provide signatures with its unique, unchangeable id. If signatures with that id are blacklisted, then the ATSHA is worthless.
Is that not the case? Can an ATSHA be used to create a signature with an id that is not it's own?@elcaron the atsha ID is completely separated from the hmac calculation circuitry. The atsha204a calculates a symmetrical hmac (symmetrical in a non cryptography-meaning). It has to, or another atsha would not be able to redo the same calculation. So no, the serial of an atsha is not included in a hmac calculation. This is done externally as documented in the signing documentation. Therefore blacklisting is not an option, and the whitelisting feature has been developed, so that it is possible to revoke nodes without changing all hmac/PSK keys in the network. This is also the reason for why whitelisting is a completely optional feature (but highly recommended if you have nodes that are publicly accessible).
-
@elcaron the atsha ID is completely separated from the hmac calculation circuitry. The atsha204a calculates a symmetrical hmac (symmetrical in a non cryptography-meaning). It has to, or another atsha would not be able to redo the same calculation. So no, the serial of an atsha is not included in a hmac calculation. This is done externally as documented in the signing documentation. Therefore blacklisting is not an option, and the whitelisting feature has been developed, so that it is possible to revoke nodes without changing all hmac/PSK keys in the network. This is also the reason for why whitelisting is a completely optional feature (but highly recommended if you have nodes that are publicly accessible).
-
@Anticimex Ok, I see my misunderstanding. But that would mean that a lost node (to obtain the ATSHA) and an accessible node (to extract a whitelisted ID but then left in place) combined would give access, wouldn't it?
-
@Anticimex The idea is to let one accessible node alone. Just get the id out and leave it where it is. So there would be no reason to take that node's id off the whitelist.
-
@Anticimex Oh, forget what I said. I thought that the whitelisting was on network access basis. But the doorlock has to trust the id via whitelisting, and of course it wouldn't trust a patio motion sensor.
-
@Anticimex Oh, forget what I said. I thought that the whitelisting was on network access basis. But the doorlock has to trust the id via whitelisting, and of course it wouldn't trust a patio motion sensor.
-
@Anticimex Oh, forget what I said. I thought that the whitelisting was on network access basis. But the doorlock has to trust the id via whitelisting, and of course it wouldn't trust a patio motion sensor.
-
So apparently it it will be a while until I can do active testing. Right now I am struggling to get my network running at all.
I'll quickly post it here in case someone has an idea, else I'll open a thread next week when I actually have time to react to suggestions.
I have flashed the GatewayESP8266MQTT sketch to my gateway (Wemos D1 Mini + RFM69HCW). This is the output:
0;255;3;0;9;TSF:LRT:OK 0;255;3;0;9;TSM:INIT 0;255;3;0;9;TSF:WUR:MS=0 0;255;3;0;9;TSM:INIT:TSP OK 0;255;3;0;9;TSM:INIT:GW MODE 0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0 0;255;3;0;9;MCO:REG:NOT NEEDED scandone f 0, scandone state: 0 -> 2 (b0) state: 2 -> 3 (0) state: 3 -> 5 (10) add 0 aid 3 cnt connected with MySSID, channel 1 dhcp client start... ...ip:192.168.2.127,mask:255.255.255.0,gw:192.168.2.1 .IP: 192.168.2.127 0;255;3;0;9;MCO:BGN:STP 0;255;3;0;9;MCO:BGN:INIT OK,TSP=1 IP: 192.168.2.127 0;255;3;0;9;Attempting MQTT connection... 0;255;3;0;9;MQTT connected 0;255;3;0;9;Sending message on topic: home-le/mysensors/868/in/0/255/0/0/18 pm open,type:2 0The message is successfully published on the MQTT server.
I flashed the LightSensor sketch on another breadboard node (Arduino Pro Mini + RFM69HCW). This outputs
0 MCO:BGN:INIT NODE,CP=RRNNA--,VER=2.1.1 4 TSM:INIT 4 TSF:WUR:MS=0 8 TSM:INIT:TSP OK 10 TSM:FPAR 141 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 2148 !TSM:FPAR:NO REPLY 2150 TSM:FPAR 2281 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 4290 !TSM:FPAR:NO REPLY 4292 TSM:FPAR 4423 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 6432 !TSM:FPAR:NO REPLY 6434 TSM:FPAR 6565 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 8574 !TSM:FPAR:FAIL 8577 TSM:FAIL:CNT=1 8579 TSM:FAIL:PDTWhich apparently indicated that no parent could be found. The gateway doesn't output anything.
I did not make any changes to the gateway sketch except for password and name stuff (especially no inclusion mode). Devices are a meter apart, one with a spring antenna, the other with a big screw-on antenna.
-
-
@MiKa If you happen to have time, could you test the range with
- a stable 2.7V supply and
- a 1mF cap in parallel to the battery?
I am really not happy with the HT7333 solution, since the shelf life of the keyfob will be limited and the quite expensive LIR2032 can easily be damaged by undervoltage.
If the second test works, I could fit 4 220uF 6.3V tantalums next to the LED.
Else I would give the step-up thing another go. There are low profile inductors, but I didn't find any for cheap (shipping) at Aliexpress.
