3 days ago •
The next important step of making autonomous FIDO2 Authenticator device is the power source. In general, I have two options - replaceable or rechargeable batteries.
The replaceable option is the cheapest and most easy to implement. While the coin size cell (CR2032) has a slightly lower voltage (3.0V vs 3.3V) it should provide enough power for the device built on ESP32 microcontroller.
The biggest concern here is - what to do in the situation where I need to authenticate but the battery is already dead? Always have a spare battery? Does not look good, to be honest…
The rechargeable option is better from this point of view. However, it’s more expensive and more complex to implement.
Personally I think the rechargeable option is the best in my case. I have purchased the tiny LiPol cell used in hearing assistant devices and bunch of TP4054 charging ICs. They are tiny and should perfectly fit the small PCB.
And then comes the very interesting question - which connector to use for charging? USB Type C is reversible and easy to plug in. The Micro USB connector takes the least space on the PCB. USB A can be found almost everywhere as a universal charging solution but really huge compared to others.
Another important thing for battery-powered device is measurement of the battery level. Fortunately, there’s not much to invent here - the nice discussion on the StackOverflow gives a circuitry for that. Simple voltage divider is connected to the ADC input and MOSFET enables/disables it to prevent power loss while voltage is not measured.
So, for me, the general design of the power board is more or less defined. I am going to build a power board featuring tiny LiPol rechargeable battery and USB Type C connector. The circuit should be simple and will not differ very much from the datasheets of the respective ICs.
02/03/2020 at 12:37 •
And, now the project has reached the next important milestone. So far I have the following building blocks:
- I have built a prototype board for the authenticator device.
- The fingerprint scanner was connected and the fingerprint image was acquired.
- Security chip was connected and communicated.
That means now it’s time to build everything together on a single PCB and start moving towards the autonomous authenticator device.
The new PCB was designed and ordered. It’s slightly smaller than the previous one but features basically the same set of components.
I have skipped voltage regulator for now since I want to experiment with different ones on separate board. Connector to the UART fingerprint scanner was replaced with the connector to the FPC1020AM which was placed to the other side of the board.
To display different states of user interaction I have soldered three LEDs - red, blue and green. Blue one should be used to display different states of user interaction while red and green should display error and notification messages.
The board features mounting holes so I started to think about putting it into a decent case. Meanwhile, the spare PCB placed with brass spacers provides a general look and feel of the future device.
It’s not a huge step, really, but just a compilation of what I already had. Nevertheless, now all the small pieces work together as one device and the device started to get a shape. I can hold it in my hand, I can confirm authentication request with my finger and it makes me absolutely happy how it goes. Yes, I think now it’s time to give the project a name.
Last summer, when I just started to think about making own FIDO2 Authenticator I came with the name for the project - “URU Auth”. “URU” is an abbreviation which reads as “You Are You” and I think this name fits quite well for the authentication device.
What is the next challenge then? Now it’s time to experiment with the power source to make it really autonomous while keeping small and lightweight. And, still, I have to process and recognise fingerprint image.
01/06/2020 at 15:57 •
Surprisingly, scanning the fingerprint image was not an easy task. I’ve spent several days trying to retrieve any data from the sensor except the hardware id but without any success. Apparently the task of processing raw images from the capacitive scanner is not a very common task and it was hard to find any code examples or documentation online.
However, some search could help me to solve this problem. I have discovered that some branches of Android kernel have a special driver for the FPC1020A scanners written by the company Fingerprints. And, working with these sources could help me to find out that documentation I have is incomplete.
First of all, the FPC1020A chip has at least four revisions requiring different setup procedures. Many of the setup values are real “magic numbers” as they are not described in the documentation and look like 64bit integer values. Probably the full and proper documentation could bring some light on this topic but I don’t have it at the moment.
I did not write the code to detect which revision I have but just tried out one setup sequence by one. Suddenly, the revision A3 enabled finger detection and scanning functions.
So, at the moment, I have a code for ESP IDF to work with both types of the FPC1020A scanners I have, detect the presence of the finger and receive a huge array of 8-bit values representing the fingerprint image. Not a big step, but a very important milestone - now the biometric part of the project moves from the hardware to software section - I need to find/build algorithms for recognition and matching fingerprints
12/13/2019 at 11:40 •
There was a long delay after previous project update. As you might remember the current challenge is connecting to the fingerprint scanner for proper authentication of user. I have ordered two fingerprint scanner modules - FPC1020AM and FPC1020AP and, unfortunately, the delivery took more than month and a half. Nevertheless I have finally received them and the project continues. I was surprised how small and thin the scanners are.
Both devices are small and thin capacitive fingerprint scanners with resolution 192x192 pixels at 508dpi and SPI interface.
FPC1020AM features flexible cable with flat 16 pin connector. Connector model is BM10NB(0.8)-16DS-0.4V(51) by Hirose.
FPC1020AP is the same scanner in LGA package and I’ve spent some time figuring out how to properly connect it.
More details on connecting these scanners to microcontrollers and corresponding Eagle CAD libraries are available in my personal blog.
To test both scanners I have designed a very simple PCB with a pin header and LP2985 1.8V voltage regulator with ceramic decoupling capacitors.
The board is connected to the ESP32 development board with four wire SPI interface.
I was able to write a script communicating with the board and receive proper hardware ID, as described in the datasheet.
Next step is proper setup of the scanner and receiving the fingerprint image from it.
Stay tuned! ✌️
11/04/2019 at 09:30 •
After a few weeks of waiting the postal service delivered the PCBs for the device prototype. Usually I order my boards from the JLCPCB manufacturer and the quality is very good, as always.
Of course, I could not resist and started to assemble the first board.
ESP32 Pico D4 has LQFN package with contact pads under the chip body. It was first attempt to solder chips like this with the hot air gun. Tricky, but luckily YouTube is full of videos how to do it. The soldering paste works exactly as in the videos - the chip is magically centered on the board and excess solder is pushed out with the surface tension.
Other components were soldered using the same method with soldering paste and hot air gun. The process is much more satisfying than working with usual components with pins. Later I plan to order special stencil for placing soldering paste more accurate and I want to build special oven for the reflow process. This should drastically improve the quality of my devices.
The soldered board looks quite boring and with a lot of free space. I did not try to optimize it in any way for the first prototype and placed components very sparse. However, in the future I plan to use smaller 0603 components and smaller power regulators like AP2112.
I did not place any special connectors for the power, just the simple pads. I plan to experiment with different power sources like LiPo or CR2032 batteries so I do not want to stick to any particular connector at the moment. That’s why I’m connecting separate board with micro USB connector using just two wires.
The connector for the UART fingerprint scanner is not soldered yet - I am going to make decision which one to use after experiments with different ones I have.
The assembled board was successfully identified by ESP32 programmer. Flashing went smooth at the speed of 921600 baud. The device works exactly the same way as the development board and it is still able to pass both registration and authentication procedures I showed in previous video.
What is more interesting - it’s still working without connection to the host computer powered from power bank. I think it’s a clear success at this stage - I already have small independent device which can be used for FIDO2 authentication. Yes, there are a lot of problems to solve, but still.
Next step is going to be very complex and vital for the success of the whole project. I have two fingerprint scanners already and ordered two more. If I will be able to read fingerprint image and implement matching algorithm then I have all the building blocks and I can improve the device working on every block independently. Stay tuned!
10/14/2019 at 19:39 •
It is sad, but not everything went smooth during my experiments with fingerprint scanners. I have desoldered fingerprint scanner from the GROW R300 device wanting to find a way to connect it to the MCU directly.
Unfortunately the pad arrangement on the bottom side does not match any of the scanner datasheets I have found so far. And at the moment I have no idea how to connect it. Definitely I will continue my searches but I guess purchasing scanner of other kind will be a much better idea.
On the other hand I have decided to make custom development board for the authenticator device. It will feature ESP32 Pico D4 microcontroller, ATECC508a security chip, few LEDs and connectors for programming and connecting UART fingerprint scanner.
The design is not ideal but as a first step towards making my own authenticator it should be enough. I am going to improve it step by step until I have working device.
So, the boards and chips are ordered and I’m waiting for the delivery.
09/30/2019 at 14:59 •
While working on ESP32 based Authenticator device I came into an interesting problem - User Verification. At the moment it is implemented really simple - just a button connected to the IO0 port. However, anybody is able to push this button and therefore authenticate with the device. Then I came to idea of adding some biometric authentication for the user.
I have ordered two fingerprint sensor modules capable to perform the user validation.
First one is GROW R300:
Second one is FPC1020:
Both modules operate at 5V, have UART interface to communicate and their price including delivery is around 12€. Modules have STM32 MCUs on board to implement all required operations from storing fingerprint data to authenticate users.
What I like about these modules is that it’s relatively easy to add user verification procedure to my project. What I dislike is that simple Arduino based sketch can simulate fingerprint scanner like this and become an easy way to hacking security of the device - one can just replace the scanner module with this Arduino device.
However, R300 module seems to provide way to transfer scanned finger image to the MCU. It closes the security issue, but means need of writing own fingerprint recognition and matching algorithm. But then I do not need the MCU located at the module itself, all I need is the actual fingerprint scanner to scan and process images.
So, at the moment my plan is - try to implement fingerprint scanning with R300 module and try to find algorithm for authentication and validation. If I succeed I plan to desolder fingerprint scanner from the module board and try to communicate it directly, without MCU in between.
09/16/2019 at 10:19 •
Finally I have managed to make ESP32 development board to work as FIDO2 Authenticator device. I have trimmed a lot of functionality to achieve this. For example, I have implemented only one credential which is stored in volatile memory. User validation and presence is implemented as click with single button.
Nevertheless, I was able to pass both "Make Credential" and "Get Assertion" procedures on https://webauthn.bin.coffee/ webpage.
So, so far I have almost all required pieces to continue with the build of personal Authenticator device.
08/19/2019 at 08:45 •
During last two weeks I continued to work on ESP32 part of this project. I needed to figure out how notification system works internally (could not make it work properly) and has to check the source code of the Arduino BLE library. In fact it's a very thin wrapper around functions provided by ESP IDF framework and I have tried to run some examples from there. Worked really good and I have rewritten the whole project without Arduino framework. The footprint of the application became 30% smaller with the same functionality.
So, at the moment ESP32 advertises itself as FIDO2 device, handles BLE connection and receives commands from the browser. I was able to process GetInfo command and respond with device's capabilities.
Next step would be to process MakeCredential command and create new credential for the user. It's more complex and I assume it'll take few weeks to complete.
08/05/2019 at 09:49 •
Last (and previous) weekends I've spend on real implementation of FIDO2 WebAuthN protocol. In reality the problem is more deep and difficult than I was thinking before, so I have re-implemented the GATT server on Android to have higher level language and libraries and better debugging capabilities.
At the moment I have fully working "Make Credential" workflow with proper certificate generation and response signing.
Meanwhile I have found two interesting glitches in google's implementation of FIDO2.
First one is more likely not accurate protocol definition. In the authenticatorMakeCredential section in response definition we have parameters authData and fmt with respective map indexes (0x01) and (0x02). In reality Chrome requires response with these parameters swapped - fmt parameter should have index 0x01 and authData paramter should have index 0x02. Hopefully the documentation and implementation will be more consistent in the future.
Second glitch is related to the user's interface and you clearly can see it in the video. When communication with Authenticator is about to start Chrome displays dialog window asking which authenticator device should be used. But in the background the communication with paired device is already performed. So, the user interface is totally misleading. The user has no clue they already have to open the Authenticator device and perform all necessary steps with it. But this is question to the Chrome dev team how to improve the interface.