Project Logs

Collapse

• Cancelled Project

  Dhruv Gramopadhye • 11/20/2021 at 02:53 • 0 comments

  I did some work on this project several months ago, before deciding it wasn't viable. It turns out getting the code size small enough to fit on the CH554/CH552 is not a very easy task. Getting the thing to run crypto is therefore nearly impossible. 

  I've tried working with some really really low footprint libraries for crypto; uECC (micro ECC) looked like a good bet. Even with space-optimized configuration, it didn't seem viable. I tried smaller libraries that I found on github (derivatives of uECC), and still found no luck. 

  I don't think this project is viable, but it was fun exploring!

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

View all 5 project logs