free-u2f

Description

free-u2f will be an open-source, open-hardware USB-A Universal Second Factor token based on the ultra-cheap CH55x series microcontrollers. The goal is to have the same level of security as a physical key or higher.

Why a super-cheap MCU and not a more expensive hardware security module you may ask? The answer is simple. Right now, U2F devices start at approx 10$, with most around 20$ (like the cheapest YubiKey available at the time of this writing). The goal is to produce a U2F device that is so insanely cheap that it can be rolled out to the masses quickly and without too much money. U2F is facing a chicken-and-egg problem right now. Websites don't implement it because not a lot of people have U2F devices.

This project can allow for the production of cheap U2F devices that companies can roll out to their employees, and individuals can buy for themselves (and for friends and family), thus increasing the pressure on websites or other authenticators to implement U2F devices.

Details

Got my PCBs from OSH park. They look pretty great, but their panelization or whatever added these nasty little bumps on the USB connector. It takes a bit to file these down, and its super annoying. I'll populate the boards very soon. I'm also still working on the software. I've been super busy lately with college app essay, work, and rocketry, but I'll still try to get this done

I've been documenting the project as I worked on it in a private discord. Over the next few days I'll copy over the progress I've made here.

Project Logs

Collapse logs

Quick Update: Plans for the next few months
Dhruv Gramopadhye • 05/11/2020 at 00:17 • 0 comments

Just a quick update, I know I haven't moved on this project by much in a while.
Luckily, I've stocked up on several CH55x parts, and I've done a LOT of soldering practice thanks to my effort on Oakton Rocketry's payload (maybe will document that on hackaday one day). I've also got a cheap CNC machine which I successfully used to mill a proof-of-concept PCB. I also have a few development boards sitting around, so I'm all set for quarantine!
Hopefully once my school commitment decreases, I'll be able to spend more time on this project. I look forward to making some changes to the PCB design and starting to actually write some code for this. I've been reading up documentation for the SDCC compiler, it has a nice section that helped me understand the 8051 architecture.
Also, special thanks to Aaron Christophel, who has already done a great deal of work as far as making the ch55x easier to develop for (including an android app that lets you flash your ch55x device). He gave me a few tips and pointers after I asked on his YouTube video where he describes his experiences working with the CH55x MCU's.
My next steps are as follows (not really in any particular order, and these are very much subject to change. I'm just thinking aloud)
- take a dev board and try to run some encryption tasks on it. uECC is an excellent library that I plan on using for this. If crypto tasks take way too long (more than say, 10 seconds), it may be best to use a more powerful CH55x device or consider some alternatives.
- Learn how to implement a USB device on the ch55x. There is plenty of sample code, but I want to re-implement an HID device meant for U2F. I already studied up some of the USB protocol, but I've got some ways to go. Ideally, it'll be capable of talking U2F to some minimal degree.
- Actually write code for the U2F crypto tasks....
- and integrate it with USB. At this point, I should have a functioning U2F device!
- Re-do the PCB and make some prototypes!
Soldering success, plug-in failure. Starting on software
Dhruv Gramopadhye • 12/25/2019 at 23:44 • 0 comments

I successfully hand soldered all the parts, including the SOIC ch554

After plugging the device in to a USB port, the chip caught some part of the metal chassis for the USB connector and ended up getting ripped out: pins bent and all.

I decided to switch to writing the software with the development boards that I had purchased earlier. I'll likely do a redesign of the hardware.

Attached is a photo of the carnage. Unfortunately I have no "before" picture.

Maybe if I decide to stay with this design, I'll go with an even thinner PCB. The thickness of the PCB combined with the thickness of the chip was too tight a fit I guess, even though I did the math and the whole thing should have still made it in.
Got PCBs
Dhruv Gramopadhye • 07/20/2019 at 01:53 • 0 comments

Got my PCBs from OSH park. They look pretty great, but their panelization or whatever added these nasty little bumps on the USB connector. It takes a bit to file these down, and its super annoying. I'll populate the boards very soon. I'm also still working on the software. I've been super busy lately with college app essay, work, and rocketry, but I'll still try to get this done
Catch Up
Dhruv Gramopadhye • 07/04/2019 at 03:12 • 0 comments

I'm syncing up with the informal progress that I've been documenting on the discord server I was putting this in. Everything is cut and pasted, and not necessarily curated for hackaday-style documentation.
Project U2F

Background:
U2F (Universal Second Factor) is a protocol developed by the FIDO Alliance for two-factor authentication that eliminates the effectiveness of phishing attacks by having a separate device confirm a domain name before authenticating, solving a problem that TOTP (Time based One Time Password) did not. It provides a specification for how physical U2F "tokens" can interact with browsers and web servers in order to provide a cryptographic ECDSA proof in response to a challenge provided by the server. A well known brand of U2F devices a "YubiKey", a quick google search for "U2F", "FIDO" or "YubiKey" will provide additional background information

Project Description:
To build a U2F device that is as cheap as possible. Instead of using an (expensive) secure element (SE) Project U2F will use a low cost micro controller and hardened software. This will result in a device that, if stolen temporarily, may be disassembled (components desoldered) and cloned, given a sufficient attack. Since a theif that steals a U2F token already has access to those keys, this slight decrease in security is not a concern, especially for the average user. Since U2F already operates on the premise of physical security, we're using different components in order to decrease the price without making any significant additional demands on the user for physical security
Microcontroller Requirements
- Reasonable program memory
- Hardware multiplier (for eliptical curve crypto)
- Reasonably clock speed
- USB Device capabilities
- Open source toolchain for linux OR macOS
- Supports languages other than assembly
- At least a couple other projects that have been able to interface with USB module
- Cheap, especially in volume
Cost and MCU selection
Given these requirements, I've decided to use one of WCH's microcontrollers, specifically one in their CH55x lineI've ordered two development boards for a total of ~8$ shipping, one for the CH554 which has both USB Slave and Host, one for the CH552 which has USB Slave only

The CH551 is cheaper than the CH552 which is cheaper than the CH553 (so on until the CH559, which has USB Host, Slave, and HUB capabilities. Overkill!))

Depending on compatibility, I may eventually use the cheaper CH551 after writing code for the 552 target. All of them have Intel 8051-compatible architecture

I plan to depend on the sdcc SDK for ch55x devices. My use of the CH551 will depend on SDK compatibility

The CH554 costs ~60cents in volume ,
The CH552 costs ~30 cents in same volume
The CH551 costs ~20 cents in same volume

Estimated PCB cost is <15cents/pc (bulk)

all other components are passive and should cost less than a couple cents. An LED (or two) will be included to indicate the state of the device. This should cost no more than another couple cents. There will be no physical button, instead there will be a capacitive touch button

All CH55x devices have a capacitive-touch driver

Entropy for use in crypto will be taken from ADC's least signifcant bits. This seems to be a standard practice.
I will post some resourced I found to aid in firmware development (implementations for other platforms that I will use as reference implementations, USB documentation and specification stuff etc.) as well as progress on firmware development very soon.