A USB key that simulates a keyboard to automatically enter your [Google] Authenticator code automatically.
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
sadly this project has not been chosen to go through to the next stage of this year's Hackaday compatison. It was never going to win but it world have been nice to recugnised for something. Perhaps it can be entered next year when it is more functional. Either way the project continues, but at a more leashurly pace.
I have managed to get the prototype shrunk down to a usable size. It needs some tidying but is usable. This gives a platform to refine the firmware and add features.
After a little tidying of the code and hardware I have made an video introduction and demo of the prototype.
It is a bit cobbled together, but the prototype is working. Very much a minimum viable but it is working and doing what it needs to do.
I used the USB keyboard emulation code from my ZX Keyboad project that uses the VUSB for Arduino library. This currently limits it to the Arduino 1.0.x IDEs but I intend to update this library in time and this is another good reason to do so.
Next I need to miniaturise it so it is portable. The final version will be a low cost custom board, but I really need to try it in the field first, and this means a some what smaller hardware prototype.
Also I have a lot of features I want to add to the device, including making the setup easy for the "man in the street", but one step at a time.
The RTC module has been added thanks to https://github.com/msparks/arduino-ds1302 . I used the DS1307 over the DS1307 as it was lower cost and had all the functionality I needed, but I was surprised at the lack of support in the Arduino world. Partly because of the I have decided to stick with the software clock and have that synced with the hardware clock when inserted in to a computer. This allows any RTC module to be easily retrofitted to the design without a large anount of work.
Considering the head start I had this took longer than it should have done, but it is working now. Here are some test codes being generated and being compared to the Google Authenticator app on my phone. Apologise for the bad framing. I did not want to show and real codes although they expire after 30 seconds.
Also full credit to...
Also thank you to https://github.com/damico/ARDUINO-OATH-TOKEN for the useful documentation in their project.
The hack days I was hoping to have worked on the base of this project have just not happened so I have decided to use the Hackaday prize as an excuse to have a weekend of hacking away at the base of this. It is an excuse as I have zero chance of winning, but that is not the reason I do building this.
I have the components together and have started on the USB interface. I will not have time to get the optical reader working this weekend and will come back to that later, perhaps at a hack day.
I have also done some research and it appears that a lot of the heavy lifting has been done. Annoyingly the licence of the code most are build on is not clear so I suspect I will need to rewrite the Authenticator code, but I have a framework to work from.
Here is the overview of the project plan. The minimum viable solution will have to have a processor that and a real time clock to calculate the correct keys, and a way of emulating a USB keyboard. I am keen to keep the hardware simple and use the V-USB library on the same processor that will calculate the keys.
Another element to this project will be configuration as the computer needs to be able to securely deliver a key from the web site, and the real time clock will need setting at least once. For this I am going to try and transfer data at a low speed from the PC screen to the device using optical sensors. This has been done in the past but will need refining.
Although not essential to it's initial operation I suspect I will probably add some kind on user input (a button) and device feedback (some LEDs) to help with development and debugging.
So the headline development tasks are...
I have already done the RTC and V-USB parts in other projects and this code can be used here. Some work has already been done by others on porting the checksum calculation code but this needs finishing. My intention is to put this together as a prototype in a weekend or at a hack day.
Although there have been projects that use optical sensors to read data from the computer screen they have not worked very well. I have the advantage on not needing to move much data, and that it does not happen often, so I can do it slowly. My hope is this will solve the issues others have had. Again my intention is to put this together as a prototype in a weekend or at a hack day.
The client software will need some thinking about to make it secure. It is easy to hack together, but for the final version we do not want the secret keys being passed back and fourth across the internet. I believe it should be possible to make this as an HTML5 web app that runs completely on the client machine.
Create an account to leave a comment. Already have an account? Log In.
Although I have not made the conscious decision to abandon it I don't have any plans to progress it in the near future. If you are wanting to progress it and make a PCB then please do so. All my work should be online and I can make if available if I missed anything.
crosspost from comments on the blog: Oh man I used the same 'optical programming' approach to program SSIDs and passwords on the first generation CC3000 boards. A quick search shows almost everyone who approaches this problem in this fashion ends up reinventing manchester encoding and thinks about "why hasn't anyone else done this oh wait..."
For checksumming I ended up just using parity bits. Simple to implement and (in my experience) robust enough for such small packets, especially if they're all ASCII, you can use the 8th bit for parity.
I know what you mean about eventually reinventing Manchester encoding and if I was using only one sensor then I suspect I will be going the same. If know of someone releasing a simple Arduino or C library then I will give it a test.
The big difference that I am considering for my solution is to use two sensors, most likely one for data and one for a (slightly delayed) delayed clock. I suspect it has been done before but I can not find anything to learn from at the moment.
Thanks for the thought. I intend to use the same V-USB library that you are referring to, but I don't want to lock the project in to only working on set hardware so will run it on the main micro-controller instead. The Arduino Uno and others actually use two micro-controllers and many components to do what can be done with 3 resisters and 2 diodes and a shared use of the central micro-controllers. My ZX keyboard is good example of this... https://hackaday.io/project/2076-zx-keyboard
i didn't know it was so simple to add HID functions :-)
Become a member to follow this project and never miss any updates
Have you abandoned this project? I'd really like to build it in a single pcb.