| cad | ||
| notes | ||
| sketch/diyus | ||
| .gitignore | ||
| cat.svg | ||
| diyuskey.webp | ||
| LICENSE | ||
| README.md | ||
| text.svg | ||

Diyuskey - Digital Fabrication Final Project
Diyuskey is a physical, offline-first password manager. The name is derived from both the existing "Yubikey" product and the initial plan of using an (ATSAM)D11C microcontroller to create a USB key. Here is a short presentation showing it in action.
Summary
In short, Diyuskey is a USB HID (human interface device) containing some set of passwords that you have decided to store on it. You can use it to input those passwords by plugging in your Diyuskey, entering a PIN code to unlock the device, selecting your password and finally pressing a button to send it to your computer.
The device features a custom-designed and made PCB as its base. It is a simple one-sided CNC milled copper-clad board with the driver circuit on the coppery side and an OLED breakout board on the other one. This design allowed for quick iterations while containing the whole device in a relatively small package.
At the core of the circuit itself is an ATSAMD21E17 MCU. The initial plan was to use the ATSAMD11C MCU, but due to time constraints and a lack of software support (and onboard flash storage for that software), I eventually decided to switch to the D21E. Connected to this are the OLED screen, and a set of three buttons. The OLED is driven by the MCU via an I2C bus using the U8g2 library. The states of the buttons are multiplexed on a single connection by using resistors in series and read on the MCU through an ADC-capable pin. Each button press then corresponds to a different analog value. This design was initially set due to the limited amount of pins on the D11C, but I decided to keep it due to the bonus property of reducing the required connections from five to three (ADC, 3V3 and ground).
A big part of the initial plan that's missing is the interface to a USB flash drive via a MAX3421E USB host IC. The idea was to take use of an old USB flash drive as the actual storage for the passwords. This too, was eventually scrapped from this prototype scope. The main reason for this was that the device would simply have been too thick; it would not have fit on the USB port of my laptop without lifting up the side. Another considerable reason for this change, as well, was the lack of time. Testing out the flow of data from the USB stick through the MAX to the MCU would have taken a considerable chunk of time which just was not available. Instead, the passwords are hard-coded into the flash memory of the MCU. What makes this terrible security practice is that they are, for the moment, simple plaintext. But as this is only a prototype it's not an issue.
Read more about the full process here.