Can we design the teensy alternative for keyboards?

[pomk]

Resistors and pins are fine for a couple of leds, just dont overdo it by going beyond total of 100mA. As for bt, I was talking about a bt only solution with wireless firmware updates.

[tentator]

uh.. wireless fw updates? now that sounds interesting!!

tent:wq

[pomk]

yeah, no need for a pesky usb connector ruining otherwise clean looking cases anymore

[matt3o]

we don't have the main board yet

[pomk]

Just thinking ahead here
I went through the PCB again, and it looks to be fine even after the routing for the two pull-ups. Before any meaningful amount of boards are to be ordered, it would be good if someone with real skill would go and validate the HW design in its entirety. I know one person from work who might be able to do it, but I'm not sure if he would be interested. He did get exited when I said to him that something that I've drawn is going through a pick'n'place machine though

[vvp]

uh.. wireless fw updates? now that sounds interesting!!

Just make sure it requires some non-easy bootloader startup by somebody who has physical access to the keyboard because otherwise it is only a cool security hole. An instant remote keyboard-sniffer / keystroke-emitter is a wet dream of black-hats

Edit: To tell to the truth I would not want a keyboard controller which can get it's firmware changed over wireless. It is just too dangerous without wireless authentication / encryption for the firmware update which makes it uncomfortable and complicated.

[pomk]

I don't see the problem here. The firmware bootloader checks if a certain key-combo is pressed before starting the bt radio, and if not, boots the previously installed firmware. It would be suspectible to attacks only in the update mode, and even then would have to be done in great synchronization with your update and the crc for the entire image would also have to match. This would be possible if the machine you use to update is already swarming with viruses, but extremely difficult to do by an outside force.

[tentator]

well yeah for doing that nowadays if you can get so close to your target, black hats use things like this one: https://samy.pl/poisontap/

and cementing usb ports might be not so popular for keyboard enthusiasts...

[pomk]

Good thing that you can just disable usb completely when using wireless keyboards

[vvp]

pomk, that is the point of wireless. A different machine than yours can do the firmware update. (If you do not have authentication/encryption.) Your machine can be completely virus free. More over the attacker machine does not need to be physically connected. It may be behind that thin wall next the keyboard. It can be there for weeks listening whether your wireless boot loader starts. If it does the only thing it needs to do is being quicker than you to start the firmware update. The attacker firmware can behave not only as keyboard but also as e.g. a USB flash disk and as a first thing it can infect your PC.

Is this attack probable? Not yet because there is very small number of keyboards which can update firmware over wireless. But maybe with the elf board this will change Anyway it is not a big deal. People who want it can risk it. Other people can remove the wireless boot loader from the firmware to be on the safe side.

[pomk]

You do know that both of the connected parties employ a 128-256 bit encryption scheme, and validate each other with a key that is not shared via the wireless connection? I'd be more worried about someone listening your wired keyboard already in the room next door. http://www.pcworld.com/article/161166/article.html

[vvp]

I'm not that much concerned about listening than about injecting a malicious firmware to my device. Once it can be done over wireless then it is more dangerous because it does not require physical access. Injecting packets on your USB cable requires physical access or compromised host. Injecting packet to wireless does not need physical access.

I know that Bluetooth/Wifi are encrypted but the encryption can be disabled. So just make sure elf firmware does not allow that.

Paired device has complete trust. If somebody manages to pair with you then it can do much damage. You can by mistake pair an elf board with attacker if you do not care about pairing a lot. This is probably again configurable but some devices alow to pair by asking you whether two numbers are the same. If one does not really check them then he can pair with something different. And the pairing information can be cached.

There are some weaknesses in E0 cipher used by Bluetooth.

I'm not a security expert but idea of changing firmware over wireless does not look good to me. It increases attack surface too much by lowering the need for physical access.

[pomk]

I just find it far more probable, that should someone wish to update your keyboard firmware unknown to you, he would do so by gaining access to your PC instead of trying to crack the problem with combined physical access (you have to press buttons to start the firmware update process and these can be incorporated to a more extensive degree to the update procedure if needed) and a wireless man in the middle attack. Also, what kind of stuff you are worried about with malicious firmware, if you are not that worried about wireless keyloggers in the first place?

[vvp]

Uff key loggers are very bad but sneaky firmware is worse. That is the reason why I'm worried about unauthorized firmware more. Really, it does not matter much. I bet there are people who want to update firmware over wireless. And they will be quite safe because it is not used much (yet) so there is not much black market support for hackers in this area. And why develop it for a few instances of the future elf boards? Also the boot loader is activated only after a special button press or whatever.

I personally just do not want wireless firmware update. Because if this idea spreads in the industry then we are in a serious shit. Look at the internet of things security debacle. I do not like an idea that somebody can hook up to my hardware from a great distance (*). It is bad enough that they can listen to the activity if they are determined since the wireless encryption is crapy and hackers kits are available out there. It is terrible if they can potentially replace the firmware and keep their foot in my hardware in a very unexpected way. It is not like I'm upgrading firmware that often that connecting a cable would take much of my time even when accumulated over a year.

(*) Even a short range bluetooth can be reached from few hundreds of meters with a good antenna.

Wifi is bad since it allows no encryption but at least the best encryption options are quite good. Bluetooth after v2.0 does not alow non-encrypted communication after pairing but the pairing is still unsafe. And moreover the only available encryption E0 is "pathetic". It may use 128 bit key but effectively it is only around 38 bits. If the cracking algorithm can be ported to a graphics hardware then the decryption time is in the range of seconds. Though the needed data collection will take much much longer.

[pomk]

Well if the thought of someone constantly looking to update your KB firmware via an elaborate hack is too much (I'm by profession very interested in how this could be done), one option is to go to a safe location for the firmware update. A cabin in the woods would be a natural choice, at least for us finns. Another option would of course be to update via a SWD interface, but this requires a HW purchase. As all keyboards can already be listened to at a distance with minimal investment, I don't think that the shortcomings of the encryption are a big concern.

Also, even paired devices have to work together using a pre-defined set of commands. For HID KB device over bluetooth, the number of commands one can send is very limited. Unless there is a bug or a backdoor in the communication stack, I find it difficult to accept that the commands available could be used to modify the device firmware permanently.

The problem with IoT is that they want the devices to be updated without physical access, while not committing to the security aspects on a serious level. Wireless firmware updates can be done successfully and in a safe manner, if enough thought is put to the process.

I have a feeling that we are drifting a bit off topic here

[vvp]

... one option is to go to a safe location for the firmware update. A cabin in the woods would be a natural choice, at least for us finns. Another option would of course be to update via a SWD interface, but this requires a HW purchase.

... or just use USB boot loader. If the PC is not compromised then nobody will inject packets remotely on your USB bus.

As all keyboards can already be listened to at a distance with minimal investment,

Well I'm not that sure this is so easy for USB keboards. My suspicion is that it would be eaiser to use sound then the ground wire for an USB keybaord. The atricle you posted even claims it is harder with USB than with PS/2. USB is a twisted differential link. It will not leak much to the ground wire at wavelengths of around 25 m and more (where full speed USB is). Using low speed USB should help. The biggest concern are probably untwisted wires in the PC case or in the keyboard itself. I guess the attackers were measuring ground wire against real ground. So they must do it long before the ground wire is really grounded. That imposes a distance limit. Maybe a 5 nF capacitor in your socket to a separate ground wire would help. Actually I would read the detailed report how they sniffed an USB keyboard through mains. What was the setup, what values did they measure, how easy it actually was... Do you have a link?

Wireless firmware updates can be done successfully and in a safe manner, if enough thought is put to the process.

Yes, I agree. E.g. you can just sign the firmware and any updates over wireless would require a signed firmware. But it is additional hassle. It may be easier to just use a cable.

I have a feeling that we are drifting a bit off topic here

Yes, I'll stop

[pomk]

I'm not aware of any bt chip that would have a usb core on it, of course v-usb could be used to deliver the firmware via a cable. Also bt 4.x uses 128bit AES, which I have thought to be quite secure.

The paper is available here: https://www.usenix.org/legacy/events/se ... agnoux.pdf
It seems that they do not rely on ground wire for usb, but rather interpret the scanning keyboard matrix as a series of antennae to listen to. Because this is a completely wireless setup, it can be done at a distance and it does not matter what kind of a (micro switch based) keyboard is used. The amount of EMI available could be limited with certain designs though.

[vvp]

AES is ok (so far). If they improved also the pairing process then Bluetooth 4.x may be OK.

Thanks for the link. I looked at it and I'm not concerned about USB keyboards. Only Matrix Scan Technique works for them. They did it in a semi-anechoic from 1 m distance. Well they probably can replicate this in real life. But the biggest problem with their attack is that it is timing based. The keyboard they investigated delayed the matrix scanning after a key in column was detected. Thanks to that they were able to identify the column. So they did know that one of 5 keys was pressed, although they did not know which one exactly. I'm not afraid since my firmware does not significantly change matrix scanning speed regardless which keys and how many are pressed. It only inserts pressed keys into a pressed key array. Scanning patterns depend only very little on what keys were pressed. When I'll work on firmware for v0.8, I'll make sure scanning is always the same regardless of what was pressed. During scanning I'll only fill a bit array which indicates what was pressed. The timing will be exactly the same regardless what was pressed. And maybe I'll print my next keyboard case from a metallic filament just as an additional measure

[pomk]

Well their antenna in the test was just a one meter wire on a table, and does not really reflect the performance one could get with some additional research.
Also if the matrix is scanned in one go, as in most mechanical keyboards, one just receives the peaks in a fast successions and you need to check the spectral properties as the key rather than the timing. I recall reading a research paper on this topic years ago, but could not find it right now. Even using their technique, you should still be able to detect which rows have keys pressed, and depending on noise, maybe more based on the observed amplitude.
Note too that the research was just a low funding student study and should not be taken as the definitive limit one can achieve with additional effort.
It's too bad that I have actual work to do, otherwise this would be a fun project to delve into and publish results of

[vvp]

Well, with the cheap hardware they used, the maximum distance in an office was about 3 meters for MST (7 meters in an anechoic chamber). And that was the easy technique which needs only to measure time distance between two signals. Comparing shape of the signals will be harder. A conductive case will rule out MST regardless of how expensive hardware they have. Then they are back down to analysing sound waves.

[pomk]

I'm not sure if just conductive case is enough, as the switch holes are quite large on one side. I'd use 4 layer PCB with solid ground planes on the top and bottom layers.

[vvp]

Based on this page the attenuation is about:
30 * shieldThickness / holeDiameter * √(1- (frequency / cutOffFrequency)²)  [dB]
If the formula actually applies to our case then the attenuation without shielded PCB would be about 2 dB for frequencies below 4 GHz. Not much.
Interesting that shieldThickness / holeDiameter ratio defines the maximum shielding achievable. I would not guess that shieldThickness is so important. Also the article indicates that the top and bottom shield plates should be densely connected with vias at the PCB edges. Even then it may not be enough since shield thickness is very small for a PCB layer. The formula probably does not apply in these extreme cases.

[pomk]

The PCB edges can be continuous plated slots

[KitWasHere]

Are the two switches that the board is to be soldered to wired on the PCB? Like, would you need to handwire the switch to a pin after soldering to the board or are they already connected? I'm having trouble wording this elegantly haha

Great work everyone, this will be awesome for hand wiring. Definitely in for one when you do a group buy

[pomk]

The switches are not connected to anything on the board, so a proper design will either hand wire to them as well, or has a motherboard pcb with traces to them.

[matt3o]

don't leave me now that we are so close!

[tentator]

why? no, I'm here waiting

[hasu]

I did quick and dirty job on this hand-wired keyboard and it kind of works and I'm typing on it. TMK firmware on KL27Z is not finished yet and some issues but I hope future users can fix them in the end. My current firmware is located here, btw.
https://github.com/tmk/tmk_keyboard/tre ... /kl27z_kbd

Spoiler:

There are some observations I had during making the keyboard.

1. Silk print of pin name would be useful if possible.
I had to check pin names on schematic for pin names repeatedly when soldering wrires and coding firmware. I made this diagram for this purpose but it still would better if the controller board has silk prints for pin names.
https://github.com/tmk/tmk_keyboard/blo ... #elf-board

2. Some pins should be marked on diagram or silk print to warn users that the pins have pull-up resistor or push switch; PTA2(Reset), PTA4(NMI), PTA1 and PTC5. Users may want to avoid using those pins to circumvent unintentional issue.
I used PTA4 for matrix scan carelessly and my keyboard registers ''6yhn" when pussing 'bl' button

3. Some components may be close to pinout pads.
I melted and removed capacitor C2 with back side of soldering tip unintentionally when soldering wire to pin 24. I use usually 2mm bevel tip, btw. I just mean, you have to be careful when soldering wires, because re-soldering 0402 chips is not easy job

[matt3o]

thanks, Hasu! ALPS switches I presume? I like your keyboard feet melted glue? Genius! Can you post a picture of the top of the keyboard?

And thanks for the suggestions I hope pomk is still with us

[pomk]

Yeah, sure. There is not much room for silk screening everything, or the text becomes unreadable. We could just mark the pins that you really should avoid though. Any suggestions on how to mark suff would be helpful. I already added the pull ups to the pcb layout without problems.