Secure 5-button keyfob with enclosure (was: 8-button keyfob)
-
@MiKa Thanks, lets hope so. Did one of you have a close look for issues, at least on the schematic? It's actually my first (MySensors/Ultra low power/THAT small) project.
Anyway, Seeed just dropped the price for 10 10x10cm^2 PCBs to 5$ plus shipping, so there is not much to loose except for 3 weeks waiting. I'll report any success or failure. Until then, the design is to be considered untested.I'm a little afraid of the TQFP package
Hope I can handle it with my rework station, don't have a toaster oven ...
-
Hi,
I ordered some pieces of PCB 3 days ago based on your repo in Github (before last finalization by You) lets see in 3 weeks
TQFP package need just little bit practise and it will be OK
Im excited about this project
Regards,
MiKa
-
@MiKa said in Secure 5-button keyfob with enclosure (was: 8-button keyfob):
before last finalization by You)
You should be fine. The antenna might need a little bending at the base, because the cutout didn't fit perfectly, but it is just a matter of <<1mm. The other changes, as far as I remember, were a purely cosmetic shift of the RGB LED and a little modification to keep the clearings for the v-cuts for the panelization.
If you have issues, I could send you a PCB for shipping costs. With the panelization, I'll have more PCBs than I ever could use.
-
Since I wanted to get a gateway into the same shipment and only found the shield type gateway for the Wemos D1 Mini, which I didn't like, I quickly clicked together a PCB for that, supporting the RFM69HW (with 50Ohm impedance trace to an SMA connector), the through-hole NRF24L01 module and the SMD version with the ceramic antenna. (And of course an ATSHA204A.)
It can be powered over the D1 Mini or alternatively with up to 24V over a switching regulator.
I guess there are dozens of those things around, so I won't spam another topic (as long as nobody disagrees), but I'll put it here for completeness.
https://github.com/kvoit/MySensors_SecureD1MiniGateway
-
You created it for some enclosure? (MySensors_SecureD1MiniGateway)
-
@MiKa No, I didn't. This goes into my attic, so I didn't really care for that. But it is square, 38x72mm^2. Shouldn't be hard to find a box to throw it in.
-
@MiKa Hi, have you already received your PCBs? Mine came friday. on The bright side: Mechanically, everything fits fine into the keyfob enclosure. Nothing shakes, buttons fit accurately.
Unfortunately, I have more issues with the QFN package than I hoped. So I cannot tell anything electrically. Do you ahve it running? I am increasingly concerned that the coin cell will not be able to provide the necessary voltage and current spikes for a reasonably long time ...
-
Hi,
pcb received today, ATmega is in place and running Currently just blink green and blue LED (red LED is connected to pin A7 and this can be just analog input and not output - what I understand from datasheet of ATMega328), I dont have slim RFM69 radio, but already ordered, test with radio is in plan for Wednesday
-
Oh, A7, yeah, I remember something like that. Does the LED flash with the coin cell? The one I took from an RGB strip doesn't light up on blue at 3V because of the required forward voltage. I fear green might have the same fate when the battery voltage drops ...
Looks like V1.1 is required.Looking forward to hearing from the actual radio tests. Depending on that V1.1 might get some more caps or a HT7333 so it is possible to use a LIR2032.
-
Hi,
till now just tested from supply of USBasp programmer -3.3V, today I hope, I will have a time to play little bit with it
I already order couple of RFM95 for testing LoRa I hope RFM95 have the same footprint like RFM69HCW
As a option for v1.1 is good to have some LDO in SOT23-5 package (SPX3819M5-L-3-3) with possibility to bypass - than You can use CR2032 and LIR2032 as well
Next idea for v1.1 is to have RX,TX,DTR,GND and VCC pins somewhere on the edge of pcb for debugging and uploading sketch via bootloader and serial port
MiKa
-
@MiKa The SPX3819M5-L-3-3 has massive (well, comparably) quiescent current. Ten times the HT7333. That alone will suck a LIR2032 empty in about a month. I think I can fit the SOT-89 of the HT7333 package next to the LED. Alternatively, one could conider boosting with a MCP16252.
Serial flashing capabilities requires one more capacitor and resistor ... And the routing is also already pretty difficult. What is the avantage? As far as I can see, it is just another flashing device ...
I do intend, though, to add 2 pins rx/tx to the icsp header. How did you do that one, by the way? Does your version already have the bigger holes? In the most recent version, it is intended to take a machined female header. with that, it fits into the enclosure. I am still thinking about changing it over to SMD pads, which I would interface with pogo pins.
-
Ok, I go to order HT7333
and RX and TX smd pad will be good to have it anyhow
-
V 1.1 of pcb should have really bigger side pads for battery holder, I already destroyed one pcb pads when I put in coin battery, probably reason is overheating this small pads during soldering the battery holder
-
Thanks, I'll change that.
BTW, I found another reason against adding a serial programming interface: To safe power, brownout detection should be disabled. If the battery runs low, erratic behavior may occur, which includes jumping to arbitrary addresses in flash. If a bootloader is still there, there is code to write to the flash, which might damage the programming. On the other hand, I highly doubt that a failing mcu will manage to go through the full process of sending an authenticated button pres, especially since high current RF tasks are involved.
So it is probably generally advisable to not have the Arduino bootloader on there.
-
@MiKa I have made a big new push to the repository. Here are the changes from the commit:
- Doubled size of battery pads.
- Added HT7333 to allow for LIR2032 lithium coin cell (Bridge pads for CR2032).
- Changed A7 to A2 to make LED work.
- Added SMD contacts for TX and GND for debug output (interface with pogo pins).
(Getting TX out was hard enough, RX just wasn't worth it, I thing we really do not need to send anything to a keyfob :))
I would have liked to put a step-up converter on there, but I have not found a possibility for one that does not need an inductor that is too bit to fit on there.
-
@elcaron you will need at least TX from your board in order to personalize the atsha204a. Lest you personalize it before you solder it on the board. The personalizer can operate without TX.
-
@Anticimex Why? I thought there is SKIP_UART_CONFIRMATION. I have to set USER_KEY, but isn't that generated once for the whole network? I figure it doesn't have to be the keyfob node that does that ...
-
@elcaron yes, but how would you obtain the atsha204a serial if you want to be able to whitelist your 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 I put temporary radio via pin socket and I need to remove radio during programming 
, 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)?
-
@Anticimex Ok, I see ...
Well, good that we have TX now If my current version works, I'll personalize the ATSHA outside of the board. It's really easy to solder with a hot air gun.
-
@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
-
@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.
-
@Anticimex If the personalizer can read it indefinitely, can't I just send it out over the radio?
-
@elcaron no. Never. Then it can be sniffed. And made pointless.
-
@MiKa BTW, thanksfor testing. I have very little time right now, so I am glad I don't have to do the tests AND update the PCB. I still haven't finished my adapter from my 10 pin usbAVR to the 6 pin ISCP header ...
-
- 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?
-
@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?
-
@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?
-
@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?
-
@MiKa Suspected that. Will put it in.
-
@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?
-
@elcaron yes, until you remove that nodes entry in the whitelist on the receiving side
-
@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.
-
@elcaron I don't understand. Why would the attacker leave your node alone?
-
This post is deleted!
-
@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.
-
@elcaron then we are on the same page
-
@elcaron whitelisting is on a per-node basis.
-
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 Version with pullup is pushed to Github
-
@elcaron Perfect, THX!
-
@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.
