TurtleAuth DIY Security Token Gets (Re)designed For Durable, Everyday Use

[Samuel]’s first foray into making DIY hardware authentication tokens was a great success, but he soon realized that a device intended for everyday carry and use has a few different problems to solve, compared to a PCB that lives and works on a workbench. This led to TurtleAuth 2.1, redesigned for everyday use and lucky for us all, he goes into detail on all the challenges and solutions he faced.

When we covered the original TurtleAuth DIY security token, everything worked fantastically. However, the PCB layout had a few issues that became apparent after a year or so of daily use. Rather than 3D print an enclosure and call it done, [Samuel] decided to try a different idea and craft an enclosure from the PCB layers themselves.

The three-layered PCB sandwich keeps components sealed away and protected, while also providing a nice big touch-sensitive pad on the top, flanked by status LEDs. Space was a real constraint, and required a PCB redesign as well as moving to 0402 sized components, but in the end he made it work. As for being able to see the LEDs while not having any component exposed? No problem there; [Samuel] simply filled in the holes over the status LEDs with some hot glue, creating a cheap, effective, and highly durable diffuser that also sealed away the internals.

Making enclosures from PCB material can really hit the spot, and there’s no need to re-invent the wheel when it comes to doing so. Our own [Voja Antonic] laid out everything one needs to know about how to build functional and beautiful enclosures in this way.

STM32 Blue Pill Turned GPG Security Token

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.

Blue Pill proof of concept

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.

PGP Vulnerability Pre-announced By Security Researcher

From the gaping maw of the infosec Twitterverse comes horrifying news. PGP is broken. How? We don’t know. When will there be any information on this vulnerability? Tomorrow. It’s the most important infosec story of the week, and it’s only Monday. Of course, this vulnerability already has a name. Everyone else is calling it eFail, but I’m calling it Fear, Uncertainty, and Doubt.

Update: eFail site and paper now available. This was released ahead of Tuesday’s planned announcement when the news broke ahead of a press embargo.

Update 2: The report mentions two attacks. The Direct Exfiltration attack wraps the body of a PGP-encrypted email around an image tag. If a mail client automatically decrypts this email, the result will be a request to a URL containing the plaintext of the encrypted email. The second attack only works one-third of the time. Mitigation strategies are to not decrypt email in a client, disable HTML rendering, and in time, update the OpenPGP and S/MIME standards. This is not the end of PGP, it’s a vulnerability warranting attention from those with a very specific use case.

Update 3: Hackaday has published an in-depth explanation of how eFail works which details the scope of the vulnerability.

[Sebastian Schinzel] announced on Twitter today he will be announcing a critical vulnerability in PGP/GPG and S/MIME email encryption. This vulnerability may reveal the plaintext of encrypted emails. There are currently no fixes — but there’s no proof of concept, or any actual publication of this exploit either. The only thing that’s certain: somebody on Twitter said encrypted email is broken.

The EFF has chimed in on this exploit and advises everyone to immediately disable and uninstall tools that automatically decrypt PGP-encrypted email. It also looks like the EFF came up with a great little logo for eFail as well so kudos on that.

While there are no details whatsoever concerning eFail aside from a recommendation to not use PGP, a few members of the community have seen a pre-press of the eFail paper. [Werner Koch] of GnuPG says eFail is simply using HTML as a back channel. If this is true, PGP is still safe; you just shouldn’t use HTML emails. If you really need to read HTML emails, use a proper MIME parser and disallow access to external links. It should be noted that HTML in email is already an attack vector and has been for decades. You don’t need to bring PGP into this.

Should you worry about a vulnerability in PGP and email encryption? Literally no one knows. European security researchers are working on a publication release right now, but other experts in the field who have seen the paper think it’s not a big deal. There is no consensus from experts in the field, and there is no paper available right now. That last point will change in a few hours, but for now eFail just stands for Fear, Uncertainty, and Doubt.

Practical Public Key Cryptography

Encryption is one of the pillars of modern-day communications. You have devices that use encryption all the time, even if you are not aware of it. There are so many applications and systems using it that it’s hard to begin enumerating them. Ranging from satellite television to your mobile phone, from smart power meters to your car keys, from your wireless router to your browser, and from your Visa to your Bitcoins — the list is endless.

One of the great breakthroughs in the history of encryption was the invention of public key cryptography or asymmetrical cryptography in the 70’s. For centuries traditional cryptography methods were used, where some secret key or scheme had to be agreed and shared between the sender and the receiver of an encrypted message.

Asymmetric cryptography changed that. Today you can send an encrypted message to anyone. This is accomplished by the use of a pair of keys: one public key and one private key. The key properties are such that when something is encrypted with the public key, only the private key can decrypt it and vice-versa. In practice, this is usually implemented based on mathematical problems that admit no efficient solution like certain integer factorization, discrete logarithm and elliptic curve relationships.

But the game changer is that the public key doesn’t have to be kept secret. This allows cryptography to be used for authentication — proving who someone is — as well as for encryption, without requiring you to have previously exchanged secrets. In this article, I’ll get into the details of how to set yourself up so that anyone in the world is able to send you an e-mail that only you can read.
Continue reading “Practical Public Key Cryptography”