Secure 5-button keyfob with enclosure (was: 8-button keyfob)
-
Wow, good progress! :)
Finnaly I start up sketch, but with USBasp is not possible to upload firmware to atmega when the radio is connected :angry: I put temporary radio via pin socket and I need to remove radio during programming :open_mouth: , maybe RFM69HCW need to have connected RESET pin or some pull-up is missing.
From sleep mode Im able to wake up node just via SW5 wchich is conneted to pin D3 (INT1), Its possible to wake up from some sleep mode also via another pins (except D2 which is INT0)?@MiKa What? Unsoldering the radio is terrible ... I really don't see a reason for that, it should be SPI and the radio should do nothing ... maybe we need to pull CS low to make sure the radio is not selected? Someone here should know that ...
Regarding wake up: Yes, THAT I know about :) All the button pins are on PCINT1_vect: https://playground.arduino.cc/Main/PinChangeInterrupt
Consider setting a mask to limit it to the 5 button pins. -
@elcaron sure, that works. Just remember to take a note of the serial. Or use the TX pad you just made and run the personalizer again :)
-
@Anticimex If the personalizer can read it indefinitely, can't I just send it out over the radio?
-
Wow, good progress! :)
Finnaly I start up sketch, but with USBasp is not possible to upload firmware to atmega when the radio is connected :angry: I put temporary radio via pin socket and I need to remove radio during programming :open_mouth: , maybe RFM69HCW need to have connected RESET pin or some pull-up is missing.
From sleep mode Im able to wake up node just via SW5 wchich is conneted to pin D3 (INT1), Its possible to wake up from some sleep mode also via another pins (except D2 which is INT0)? -
- 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 No problem, I playing with it when I have time :) I will play now with interrupt changing :)
btw. LIR was an good idea, I have for test now CR2023 which have cca 2,75V and working distance from the gateway is really low. :)@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? -
@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?
