Feeling the cost of commercial options like the YubiKey and Nitrokey were too high, [TheStaticTurtle] started researching DIY alternatives. He found an open source project allows the STM32F103 to act as a USB cryptographic token for GNU Privacy Guard, which was a start. All he had to do was build a suitable device to install it on.
The first step was to test the software out on the popular “Blue Pill” development board, which [TheStaticTurtle] documents in the write-up should anyone want to give it a try themselves. The ST-Link V2 was already a supported target, so it only took some relatively minor tweaks to get running and add support for a simple push button. The output of gpg --card-status showed the device was working as expected, so with the software sorted, it was time to take a closer look at the hardware.
To create his “TurtleAuth” dongle, [TheStaticTurtle] started with the basic layout of the Blue Pill and added in a TTP223E touch control IC. The original Micro USB port was also swapped for a male USB-A connector so the device could be plugged directly into a computer. An upper PCB, containing the status LEDs and touch pad, was then designed so it would fit over the main board as an enclosure of sorts. While the sides are still open, the device looks robust enough to handle life in a laptop bag at least.
While it’s not exactly a common project, this isn’t the first time we’ve seen somebody spin up their own hardware token. More evidence of what the dedicated individual can accomplish these days on a relatively limited budget.
Why so big?
https://tomu.im/
https://hackaday.io/project/167005-femu-an-esp32-wi-fibluetooth-board-in-tomu-form
Because a custom 4 layer PCB is rather expensive, plus assembling pre-built modules is rather cheap. Not to mention the added complexity of PCB design and layout and thinking everything through and poring over datasheets a custom project entails.
Yes the project you linked is impressive, but that doesn’t mean this one isn’t, either.
So, what exactly does this do, for those of us not familiar with YubiKey and Nitrokey ?
It emulate a GPG smart card. It store the private keys and allow GPG to use them without them leaving the device.
And what’s the advantage over putting the private keys on your computer ?
The key has a hardware enclave that protects the key from attacks – like a TPM chip, only the USB key can be taken with you and used on multiple computers.
So this would be useful for sticking it in a computer that you don’t own, for example ?
Or for a company to hand these out to their employees, to prevent the employee from copying their private keys.
But if the hardware and the keys are all my own, there’s not much point in dealing with the extra hassle of a USB key, I think. If my laptop is compromised by an attacker, everything is lost anyway.
Similar to a second factor hardware key this is something you have (and can’t clone) to go with something you know (password). But for your signing (and to a lesser extent de/encryption) needs.
Unlike a printed or hard drive stored long term master it can not (in theory) be cloned. So long as you have it no one else does (GPG keys can be copied).
It resists brute force (enforces delays between key attempts and will nuke itself if too many attempts) unlike a paper or electronic copy which can be worked on at the attackers leisure.
Many people rightly or (more likely) wrongly worry about their computers random number generation, fears of backdooring by the NSA or straight up Intel /AMD this will independently generate high quality random numbers and you won’t have to trust IME or TMP or whatever those security modules are called.
The unit can be subject to audit as it will register the number signings etc so a company can watch out for illicit signing.
I have no where safe to store my long term master key (identity key) so it’s stored on a GPG smart card. That’s my personal use and I don’t _need_ it but it’s better than it sitting on a laptop hard drive I lose or printed to paper someone could photocopy (not that anyone would want to).
That is gpg let’s on your hard drive can be cloned private keys can not be exported from the cards (in theory).
I also didn’t mention (this is more important in cryptocurrency settings).
The singing is segregated from document generation and segregated from maleware. It can only do crypto functions and that’s a good thing for security.
I don’t see how you can safely work on a computer that you don’t trust. Everything on the screen has to be in cleartext, and the same applies to the keyboard and mouse. So, if your computer is compromised, the attacker could eavesdrop your communication, or even modify it.
The hardware key will happily sign a forged text.
Unless you are using cryptographically secure memory blocks on the micro and using read disabled memory then it’s relatively easy for anyone with physical access to the device to read out the key.
The Yubikeys do exactly that (and more)
Think of it as a USB pluggable smart card. You can save an encryption key on it and use it as a two-factor device that doesn’t need any kind of special reader.
You should really make an article about repurposing those cheap stlinkv2 clones:
https://hackaday.io/project/162597-st-link-clone-repurposing
https://github.com/zoobab/DirtyJTAG/blob/master/docs/install-stlinkv2-swd.md
https://www.hobbiton.be/blog/repurpose-stlink/
Nice! Thans for the tip.
What about repurposing those cheap stlinkv2 flashers?
https://www.hobbiton.be/blog/repurpose-stlink/
That’s a good idea: it has a sturdy aluminium case and USB connector for few €, out of the box!
yes, so good that it was already done few times
https://hackaday.io/project/164683-st-link-v2-clone-security-key
https://blog.danman.eu/2-usb-crypto-token-for-use-with-gpg-and-ssh/
That’s exactly what [danman] did, and he was the inspiration for [TheStaticTurtle]’s project.
https://blog.danman.eu/2-usb-crypto-token-for-use-with-gpg-and-ssh/
I used Gnuk on a repurposed ST-link clone and the first thought was: “nice hardware”.
Initially I believed it was based on the same acknowledge interface used by the FST-01SZ token
https://www.gniibe.org/memo/development/fst-01/fst-01sz-testplan.html
but it seems the author implement his own interface in the firmware.
I wonder if it is deliberate or if the author simply had not noticed that there was already something like that.
From a security point this is a horrible idea. Why would you ever want to put a private key on a completely open MCU? The whole point of having dedicated hardware is to make it impossible to extract the private key in clear. At the very least that means to physically secure the token and prevent someone from tampering with it easily if not destroy it if someone attempts to tamper with it. Better devices also include dedicated security hardware to prevent readout of the key in clear even if you do manage to get access to the hardware.
You can set protection bits so the flash can no longer be read.
Side note: Bitcoin Trezor AFAIK uses STM32.
I wouldn’t say it’s a horrible idea, but agreed it is suboptimal. I’m sure the dude is doing it more for fun than for purpose. Anyway, we’ve been contentedly securing our houses, etc, with two-dimensional patterns in metal for ages, so it seems there can still be utility in the pretty-good relative to the perfect.
I do agree with his sentiment that the existing devices are too expensive. If this is to take off, they need to be something like $1 rather than $20.
$1 seems a bit too cheap for a high quality device.
The cheapest STM32F103 already cost more than $1 if you get it from a reputable distributor. And like you said, it’s still suboptimal because that MCU was never designed to operate in high security applications.
Having someone’s door key also required physical access to the house and allows them to steal items from the house. Gaining access to a private key slows them to intercept and impersonate messages from anywhere with an internet connection. Very different security situations.
Also, comparing this to a u2f (like a yubikey) is an apples to oranges comparison. U2f facilitates logins, you too in your username and password then it sends a request to the key and you hit a button or scan a fingerprint to complete the login. It is not an encryption key storage device for message signing (although the do utilize asymmetric crypto to do their job)
I totally agree that the stm32f103 wasn’t design for that in the first place there is even an exploit for it (see https://github.com/rot42/gnuk-extractor) but I did it more for the challenging aspect of building my own device that could “compete” with commercial products. Anyway it dosen’t store my logins but I think it’s still better than jsute having my private key laying on the computer drive
The exploit only works because flash protection was not enabled. That would be a simple thing to fix.
it’s a great project — I love it
Wouldn’t it have been more secure to use something from the product lines listed at https://www.st.com/content/st_com/en/products/secure-mcus/secure-hardware-platforms.html?