Secure 5-button keyfob with enclosure (was: 8-button keyfob)
-
@MiKa The LIR2032 have much smaller capacity, tough. The 4uA quiescent current of the HT7333 alone will suck them dry in about a year. Probably even destroy them, due the lack of undervoltage protection :(
The solution is far from optimal.
What tantalum cap capacity did you use? How low is the range? -
@elcaron I using 10u/10V, I didnt measure distance exactly,but is "visible" difference when is node powered from USBasp(3.3V) or from 2.7 V :)
@MiKa That is very low. I am not an expert for tantalums, but I guess 6.3V should be save, shouldn't it? You get 100uF at that size and voltage. I even managed to stack 2 of them. It might even be possible to squeeze an 220uF 3528 in there, not sure.
Perhaps I should use the space on the back of the battery opposite of the HT7333 for an array of big tantalum caps.
Could you maybe test the range with a strong external supply at 2.7V? -
- How can it be sniffed if the transmission is AES encrypted by the RFM69?
- How is it pointless if it could be read by a bad guy from a lost keyfob? I thought it was the point of the ATSHA that it can be safely lost.
I thought security was given because a badguy cannot change the ATSHA id and also cannot extract the PSK. SO the id doesn't seem private.
@elcaron
I don't want signing security to be dependent on encryption. Especially when the sw AES encryption used for nrf24 does not use IV:a and therefore is easy to crack.
And suppose you use whitelisting in your network, and the serials was exchanged OTA. So someone could figure out the serial of all secure nodes in your network.
Then they could take your keyfob which has a valid hmac key stored. They cant read the key but they don't have to since they still can use it.
And they also know the serial of other nodes, so they can spoof any secure node you have and you wouldn't notice.
If they don't know the serial they would at least have to guess a valid node id and serial pair to be able to fake that node. And they can obtain the serial of the stolen device but if you use whitelisting you can just remove your lost node from your gw whitelist and they would not be able to use it. -
@elcaron
I don't want signing security to be dependent on encryption. Especially when the sw AES encryption used for nrf24 does not use IV:a and therefore is easy to crack.
And suppose you use whitelisting in your network, and the serials was exchanged OTA. So someone could figure out the serial of all secure nodes in your network.
Then they could take your keyfob which has a valid hmac key stored. They cant read the key but they don't have to since they still can use it.
And they also know the serial of other nodes, so they can spoof any secure node you have and you wouldn't notice.
If they don't know the serial they would at least have to guess a valid node id and serial pair to be able to fake that node. And they can obtain the serial of the stolen device but if you use whitelisting you can just remove your lost node from your gw whitelist and they would not be able to use it.@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?
-
@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.
-
