Secure 5-button keyfob with enclosure (was: 8-button keyfob)

[elcaron]

While most of my home is made smart using ESP8266s, I plan to dive into MySensors for more energy critical stuff. The first project is a keyfob.

Attached is a first design for a 8-button keyfob mit hardware HMAC authentication via an ATSHA204, running on a CR2032 coin cell and fitting into a commercially available keyfob enclosure (see README on github repository).
The ATMEGA is supposed to run in power-down mode (400nA with disabled ADC, internal oszillator @ 8MHz), the powered down RFM69HCW should take 100nA in sleep mode and the ATSHA <150nA in sleep mode, so the overall standby consumption should be well below the self-discharge rate of the coin cell.
In standby, the buttons will have interrupts attached via PCINTx_vect, so that a button press will wake the ATMEGA.

Before I send out the PCB order, perhaps somebody is interested in having a closer look ... this is both my first MySensors project and my first low power project. Also, it is probably the most compact thing I have ever clicked together. (I am so glad about KiCAD's push and shove router ...)

Any comments? Tips? Ideas? Errors?
I would hate to send this to production and end up with 80 unusable PCB (Taking about PCBs, I will have a lot of spare ones in Germany, is anybody is interested ...)
The major issues I could currently think of are:

• Does MySensors implement the sleep mode of the ATSHA? Is it even possible in that package? I don't really know much about the chip (only followed the MySensors tutorial) and it would be a bugger if it sucked my battery dry ... - Answered: Yes it does.
• Will the coin cell provide enough current for transmission? I added a 22uF tantal, should I include more?

KiCAD project on github: https://github.com/kvoit/MySensors_SecureKeyfob/commits/master

Schematic: 0_1492625836524_MySensors_SecureKeyfob.pdf

[elcaron]

Older 8-button version, abandoned since no case exists. Never tested, but I am not aware of issures.

Changelog:

• v2.0: Rotated NRF module
• v2.1 moved 2 caps out of the battery
• v2.2 small trace optimization (towards back mostly vertical, front mostly horizontal), made through-holes for ICSP header larger to fit a machine header deeper into them
• v3.0 centered the switches, new routing, ground planes in areas far away from the antenna

Most recent version:
Schematic: 0_1491890133730_keyfob.pdf

KiCAD project v3.0 (it seems I cannot upload ZIP files?)
Not sure if you can open the KiCAD project without my custom libraries.

[korttoma]

Downloading the .zip does not seem to work?

[elcaron]

You are right, I'll giving it another try. But again, I'll change the routing quite considerably, so there is not much use for the KiCAD project yet.
EDIT: Nope, the ZIP upload doesn't seem to work. I'll find another possibility for the finalized next version. Go for the schematic PDF for now.

[elcaron]

• removed uninformative post about old 8-button version -

[Anticimex]

@elcaron The MySensors library handles ATSHA204A sleep modes. The device is put to sleep whenever it is not required to be kept alive due to ongoing signing operations.

[elcaron]

Awesome, one point off the list.

[MiKa]

Hi,
Check for inspiration and nice enclosure https://oshpark.com/shared_projects/guV5HKTW Is just missing ATSHA204A
Regards,
MiKa

[elcaron]

@MiKa Hm, having an enclosure ready is a major benefit. Pitty it doesn't have KiCAD files available, so I would have to measure everything ...

[MiKa]

Someone know that guy which one shared pcb on OSH park?
Would be good to have a kicad project for small editing

[elcaron]

@MiKa I was a little skeptical at first because it seemed the enclosure wasn't that easily available for me in Germany. Now, however, I found out that it seems to be identical to the RND 455-00014 that is e.g. sold at Reichelt for less than 4€. They also have a datasheet with good documentation of the measures. I will not have the keyfob from above made but attempt a redesign over eastern for that enclosure.

Two questions for the general public:

• Should I switch to an RFM69? I do not have anything installed yet, so I am free. I understand that range and wall penetration are better, but I am a little worried that the antenna will not fit.
• Any idea if the contacts for those buttons are an existing footprint in KiCAD?

[Anticimex]

@elcaron I definitely suggest rfm69 because it supports AES encryption in hw and is therefore better suited for security sensitive use (not that encrypting keyfob data makes much sense but anyway...). Also like you say, it has better range. Antenna can probably be coiled. Perhaps a chip antenna could work as well.
Regarding kicad, it is always possible to make any footprint needed given proper measurements.
We have official MySensors libraries where the footprints can be stored if created so everyone can benefit from them (perhaps they already exist). See here.

[elcaron]

@Anticimex AES is a big plus. I already looked for coiled antennas on Aliexpress and as far as I can see, these will fit into the case. i will make a cutout in the PCB for that. I hope my Reichelt shipment will arrive on Saturday, so I can test it with some coiled 433MHz antennas I have lying around. Diameter is probably the same, I should even be able to clip them off to convert them.
I know I can make footprints. But if there was a footprint for that type of contact, I would rater use that. Since I am neither a professional nor a native speaker, I don't really have an idea what to look for ...

Pity that the OSHPark guy chose to name himself after a transistor, that doesn't really make finding him easier ...

[elcaron]

I have created a 5 button version that fits into the keyfob enclosure. I put the KiCAD project and a dxf file with the PCB measures on GitHub. I'll add an image later.
https://github.com/kvoit/MySensors_SecureKeyfob/commits/master

Schematic attached. I would like some comments before I put this into production.0_1492625836524_MySensors_SecureKeyfob.pdf

[MiKa]

Hi,
Good job!
Add also some RGB LED or Fast LED (WS2812B) good place will be on opposit side of the battery
MiKa

[elcaron]

Yeah, I could do that. No free PWM pins, though. But one could use Software PWM on A0/A1/A7, those woud be easy to route.
Any footprint+Aliexpress/EBay link ready for a suitable LED?

[MiKa]

for example: http://www.tme.eu/sk/details/hsmf-c114/diody-led-smd-farebne/broadcom-avago/ its in 0606 package with common anode

[elcaron]

If anybody cares, I have improved a few things - rgb led (choose the standard 505 that is used on RGB strips), impedance to antenna, button footprints ... It is all pushed to Github. There is also a branch with gerbers for a panelized version with v-cuts.
I will order it tomorrow evening. (Hint: I'll sit on 60 PCBs for this, soon. Location Germany.)

[Anticimex]

@elcaron cool. Do you have atsha204a footprint on them?
Edit: of course you do. Sorry for asking such a stupid question

[elcaron]

This post is deleted!

[elcaron]

@Anticimex Yes, that was the whole point. Someone else already posted a link to a PCB for the same keyfob enclosure without an ATSHA. The ATSHA is next to pin6 of the RFM69.
The other PCB also doesn't have dedicated space for an antenny, so I suspect they just somehow shove a wire in there. My design has a cutout for a spring antenna (already tested that it fits into the enclosure), with a defiined 50Ohm impedance trace leading to it.

[MiKa]

Good work, Thanks!

[elcaron]

@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 ...

[MiKa]

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

[elcaron]

@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.

[elcaron]

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

[MiKa]

You created it for some enclosure? (MySensors_SecureD1MiniGateway)

[elcaron]

@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.

[elcaron]

@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 ...

[MiKa]

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

[elcaron]

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.

[MiKa]

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

[elcaron]

@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.

[MiKa]

Ok, I go to order HT7333 and RX and TX smd pad will be good to have it anyhow

[MiKa]

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

[elcaron]

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.

[elcaron]

@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.

[Anticimex]

@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.

[elcaron]

@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 ...

[Anticimex]

@elcaron yes, but how would you obtain the atsha204a serial if you want to be able to whitelist your keyfob?

[MiKa]

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)?

[elcaron]

@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.

[Anticimex]

@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

[elcaron]

@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]

@Anticimex If the personalizer can read it indefinitely, can't I just send it out over the radio?

[Anticimex]

@elcaron no. Never. Then it can be sniffed. And made pointless.

[elcaron]

@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 ...

[elcaron]

@Anticimex

1. How can it be sniffed if the transmission is AES encrypted by the RFM69?
2. 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.

[MiKa]

@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.

[elcaron]

@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]

@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

[elcaron]

@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?

[Anticimex]

@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]

@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?

[scalz]

@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.

[Anticimex]

@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]

@scalz THX for tip, pull-up CS to VDD solved problem!
@elcaron please add pull up to CS line

[elcaron]

@Anticimex

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]

@MiKa Suspected that. Will put it in.

[Anticimex]

@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]

@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]

@elcaron yes, until you remove that nodes entry in the whitelist on the receiving side

[elcaron]

@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]

@elcaron I don't understand. Why would the attacker leave your node alone?

[elcaron]

This post is deleted!

[elcaron]

@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]

@elcaron then we are on the same page

[Anticimex]

@elcaron whitelisting is on a per-node basis.

[elcaron]

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 0

The 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:PDT

Which 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.

[elcaron]

@MiKa Version with pullup is pushed to Github

[MiKa]

@elcaron Perfect, THX!

[elcaron]

@MiKa If you happen to have time, could you test the range with

1. a stable 2.7V supply and
2. 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.