Making a Secure Keyboard

[johnshearing]

I have made an opensource airgapped computer seen at the URL below:
www.privatekeyvault.com

I want to make a USB keyboard for it that could not possibly contain a keylogger.
I see the the teensy micro processor is used in most DIY keyboard projects.
Do any of the teensy boards have persistent memory when power is removed?
If so, which ones should be avoided for this project and which ones are safe to use.
Thanks, John

[Engicoder]

Some of the teensy boards have a microcontroller with a small amount of eeprom (1K), which is persistent, but no other persistent memory. More could be added by connecting an external eeprom or disk storage such as an SD card.

[Muirium]

I assume less is more in this scenario, with the desire being zero volatile storage at all!

[Findecanor]

The smallest Teensy, the Teensy 2.0 has 1K EEPROM. The others have more.
The program memory ("Flash") could also be written to but it is not supposed to be, as it is more difficult and writing to it wears out faster.

When I first read the thread title, I thought that you would want a little bit of persistent memory, actually — for an encryption key.
Key-loggers could also work as a separate sniffer on the wire, and a method to thwart that would be to use your own protocol that encrypts all traffic. For instance, the Matias SecurePro has a proprietary wireless protocol with encryption.

There are also dedicated keyboard controller chips out there on the market. If you would trust the manufacturer of one, then that might be an option. However, if the maker of such a dedicated chip is not trustworthy then I think it might even be more likely that it already contains a key logger as it's function is fixed.

[johnshearing]

Thanks all,
Sounds like my users are just as well off trusting the manufacturer of the keyboard.
Is there any way I can make a USB keyboard using circuitry so simple that it would be obvious to anyone's examination that no key logger is present? I don't mind making circuit boards and I have a laser cutter if that helps.
Thanks for any ideas.

[Anakey]

well there has to be some programmability to tell the keyboard what each key is. There are controllers that are non flashable so they can only be flashed a single time indeed that is how the majority of basic keyboards without programmability function. What you would need to do is find a dumb keyboard that runs from USB yet has no macro keys, programmable backlighting etc that has a locked chip already and use that if you really want to make one yourself. you would need to work out the matrix on the donor board and then reproduce it for the end board if you used a membrane as the donor board and wanted to create a mechanical one for example.

[vvp]

Sounds like my users are just as well off trusting the manufacturer of the keyboard.

If it is so then your clients need to review the keyboard firmware. Even the smallest keyboard firmware will have at least few kilo bytes. And you need a custom firmware. The reason is explained below:

You do not want to use an unknown closed firmware/controller without more investigation. Most firmwares scan for key presses in a defined order and and leak information through timing side channel. Traces in the keyboard matrix can serve as antennas. Each attempt to scan row/column sends out a signal through this "antenna". It can be received outside. If the firmware adds some additional processing when a key is pressed (most firmwares do) then the scanning of next row/column is postponed. This can be detected by a remote receiver (from a distance of about 6 m?) and the attacker at least knows that a key in given row/column was pressed.

If you are that paranoid about keyboard security then you actually need your own firmware which scans keyboard matrix either in a perfect uniformity regardless of how many keys are pressed or (worse option) you need to scan the keyboard matrix in a random order. You should also consider encryption over the USB to avoid insertion of a key-logger. I do not know how much a well shielded USB cable leaks, i.e. I do not know whether it is feasible to sniff it without a galvanic connection. I would guess it is not feasible from a 1 m or bigger distance.

If you are already forced to review the firmware then you do not need to care about EEPROM or FLASH. Just do not add the features to the firmware and disable the MCU debug port (e.g. by not putting it on PCB and immersing MCU in an epoxy or whatever).

[XMIT]

I read this and the first thing I thought was, IBM TEMPEST keyboard from the 80s.

Glad to year Van Eck phreaking is still on everyone's minds.

I think you want "trust but verify" here. You're probably dependent on an off the shelf commercial MCU. Give users a way to verify the hardware both visually and programmatically (like, is there some timing quirk or bug that you can exploit, to write a function that only returns TRUE if it is running on the correct part?). Release firmwares with signatures and known sha256sums so that users can re-generate them and flash their own.

You can get paranoid and add hardware to short out any capacitors on the board and tie together power and ground to kill any transients on chip, and, use an MCU with only a ROM and burn the firmware to ROM.

Just a few thoughts...

[johnshearing]

Hi All,
My device originally had only a virtual keyboard.
So I was only required to trust the raspberry pi, and the touch screen,
I was not required to trust the software on the micro SD card assuming an airgap and assuming no side channel attacks.
I will revisit those assumptions after this problem is solved.
The device looked like this:
https://www.youtube.com/watch?v=_vA4tTLdL2M

But when implementing LUKS full disk encryption for the SD card I ran into a problem which I thought excluded the possibility of a virtual keyboard. The problem is that before the pi boots up, a temporary operating system used for entering a password and for verifying the user has rights to the encrypted partition is loaded. The temp OS is called initramfs. This OS presents the user with a command line console for entering the password. The console also allows you to execute all the commands available to BASH and many typical Linux commands as well. Sadly, There is no graphical user interface so I decide to use a keyboard and now my device looks like this:
www.privatekeyvault.com.

The new device does much more than the original and is much easier to use now that it has a keyboard. But when a users life savings may be on the line, it's too much to ask that they trust a keyboard which can not be personally verified as secure.

The Tempest attack requires the victim to be in a particular location. So the number of possible victims is limited. I am focusing on centralized attacks on the device, one of which might be a supply chain attack on the keyboard which could affect every user of the device.

I am wondering now if the GPIO pins on the pi (as opposed to USB) might allow some obviously simple and secure circuit to be used in the keyboard. Has anyone tried this? Is the keyboard circuit more simple and transparent as a result?

I am also wondering if my laser cutter/engraver could be used for making the circuit board and the chassis for the keyboard.
Is anyone in the forum using their laser cutters for this purpose?

Thanks for all your ideas.

[Findecanor]

Another issue: I think a keyboard made for security should also be made as silent as possible. Otherwise, the keys might be "sniffed" by the sound they make.

Different keys may sound slightly different because of:
• Slight differences between switches and keys. Different sizes give different hollow sounds. Stabilised keys tend to be louder and have distinct sounds.
• Different resonance at different spots.
• People tend to press different keys differently, even with the same fingers. Use different rhythm for different words, and for cursor keys etc.
• You could theoretically also triangulate where on a keyboard a sound is coming from.

Stabiliser mounts need to be types that don't rattle much. Lubrication can help.
Sound is added mostly when bottoming out and when topping up, but tactile mechanical switches could be even louder in the middle. There are mechanical key switches that have rubber bumpers to silence both the up-stroke and down-stroke but I think you should be able to find a better rubber-dome keyboard. Many rubber domes are a bit loud on the up-stroke though.
Resonance could be dampened in two ways: having a very solid frame, and/or using soft cushioning material.

There is a Wiki article on sound damping, but it is focused on mechanical keyboards.

If the firmware adds some additional processing when a key is pressed (most firmwares do) then the scanning of next row/column is postponed.

Huh? What kind of firmware stops scanning mid-scan? All keys need to be scanned regularly for debouncing, not just the one last pressed.

I know some firmware scan the matrix over and over continuously (for some reason), but I think that is very unnecessary because you could report to the host at most once every millisecond anyway ...
My own firmware (which is not nice enough for release) uses a timer to once every millisecond scan and debounce the whole matrix in constant time, and then detect key events. The matrix would not be a side-channel but maybe the power draw could be.

I do not know how much a well shielded USB cable leaks, i.e. I do not know whether it is feasible to sniff it without a galvanic connection.

BTW. There are both shielded and non-shielded USB cables on the market. USB has differential signalling which is often considered good enough on its own against interference but which may not protect against sniffing.

[Findecanor]

I am also wondering if my laser cutter/engraver could be used for making the circuit board and the chassis for the keyboard.
Is anyone in the forum using their laser cutters for this purpose?

Many mechanical keyboard cases have been made of sandwiches of laser-cut acrylic, yes.
For Cherry MX switches (and clones) even switch-mounting plates have been made from acrylic, but one 1.5mm sheet may be too thin and fragile.

[vvp]

Huh? What kind of firmware stops scanning mid-scan?

If there is a conditional command checking whether something is pressed after scanning started and before the whole matrix is scanned then that is enough. My firmware (and the firmware I branched from) has such a command there after scanning a column. I did not bother to fix this. Some commercial firmwares definitely have such a check as well since the study detected tiny pauses in the matrix scanning of an off-the-shelf keyboard.

It's nice your firmware has it fixed. I just would not assume most firmwares have this fixed without some investigation. I assume just the opposite because it is easy to add an "if" command into the scanning loop. Developers must consciously avoid adding it there to have it right.

[johnshearing]

Hi All,
I am getting some inspiration from this simple keyboard.
http://www.technoblogy.com/show?2AEE
All I need now is a ridiculously simple circuit that can talk to USB or perhaps GPIO such that anyone looking at the circuit could tell immediately that no key logger resides there.

[Humanoid]

Security is only as good as its weakest link. Your weakest link is the Broadcom soc in the raspberry pi. Not the keyboard connected to it.

Is there any way I can make a USB keyboard using circuitry so simple that it would be obvious to anyone's examination that no key logger is present?

It's not possible to do such a thing if you use any kind of integrated circuit, because every IC can have a logger in it, and nobody will be able to know just from examination. The usb communication chip itself can keep a secret rotating log of the last megabyte of data sent through it. Either you make the integrated circuit yourself... or trust whoever made it. And since we still can't make IC's at home, the best we can do is use FPGA's.