conorpp

Good points as to why we should move away from proof of work blockchains.

You could also say that the BTC/USD rate is proportional to the amount of interest...

Some problems I am excited about cryptocurrency fixing:

- Sending money across borders.

- Decentralized exchanges that actually charge fair fees, unlike the centralized exchanges of today.

- Allowing more people to purchase goods online that previously had to no way to.

- Providing stable rates of return for your crypto based savings account (e.g. via staking).

- Lowering interest rates on loans by cutting out the middlemen.

Reminds me of an ongoing & heated debate about T. rex -- Did the T. rex have lips?

You are right, I lied a bit to oversimplify :)

Just wanted to add since I didn't see this covered in other comments yet --

TOTP and any sort of one time code authentication are just as phishable as passwords. Perhaps the biggest benefit for most people using U2F or FIDO2, is the large resistance to phishing.

This is because of how the whole ecosystem has adopted FIDO2. When a FIDO2 key signs an assertion for a website, it includes the domain in the signature base, e.g. "example.com". The browser enforces that the request to the FIDO2 key always uses the correct name of the domain you're on.

If you accidentally go to a fake website, "exaample.com", then the key will make a signature for "exaample.com", which is invalid for "example.com". Nothing can be phished to get around that, unlike OTP codes.

Even if you have other 2FA options linked to your account, as long as you're using your FIDO2 key, you gain this benefit. Very strong benefit for both individuals and enterprises.

The epoxy can't be physically removed without great risk of ripping off the electronics on the underlying circuit.

The epoxy can be chemically dissolved, but would deteriorate the outside of the device as well. It the epoxy isn't completely cleaned out, then refilling it with new epoxy would look messy. With great care and skill, it could be done with little damage, but would be time consuming.

To add to this, we would like to be able to run open source & update-able code and leverage EAL certified secure elements. Chips like the SE050 have recently come on the market and will likely end up on our products eventually.

New in V2:

- More secure microcontroller supporting secure boot, PUF, flash encryption, etc.

- Firmware rewritten in rust.

- Much more robust and durable construction.

- Touch buttons, reversible USB-A, USB-C

NFC is passively operated similar to other authenticators and is more reliable.

ED255 is supported in V2!

Hi There!

I'm part of an open source based startup and we'd love to get some help with our web design.

We sell physical FIDO2/U2F security keys, for strong authentication on the web. Soon to replace passwords! All firmware and hardware is open source.

https://shop.solokeys.com/

Would you be interested in helping out?

Some bootloaders can be really simple. Here is one I wrote recently for my security key product (this particular code is for an ARM M3).

https://github.com/SoloKeysSec/solo/blob/master/targets/efm3...

https://github.com/SoloKeysSec/solo/blob/master/targets/efm3...

Like what others mention, it really depends on documentation from the vendor for the chipset you're working with. I mainly copied and pasted code from a form post by the vendor.

And of course link to the security key product :)

https://solokeys.com/

I agree, you could do this using more traditional methods, I just think leveraging a nice printing process could save some time/effort. Some other challenges that printing solves:

1. you can set the width of the jig to match your pogo pin spring "active region" easily.

2. You can make cutouts for the board and other features (USB-C + USB-C connectors in my case).

I admit, a Form 2 is an expensive perk. But there are much more affordable routes: https://dirtypcbs.com/store/print3d https://dirtypcbs.com/store/lasercut

I.e. when you order PCBs, you can order a $5 SLA jig :)

It'd be difficult to get all the holes lined up correctly

I think if we had a single chip solution, we could make it work, but since we're using 2 chips, it would be tight. I posted schematic in other comments.

Maybe one "affordable" idea could be to stack 2 two-layer PCBs XD.

We'd love to make something small like the Yubikey Nano!

Right now it'd be a bit tough, because to fit our chipset [1] in that tight space, it would likely involve making a custom IC package [2] or placing silicon die's directly on the circuit. I think it'd be really cool to do that, and if we get enough sales/interesting, we'll definitely go that route.

Using something like the Tomu seems promising as well. It doesn't have the same security features and is just an M0 core, so it's not the best fit.

[1] https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.p...

[2] http://www.icproto.com/

Tomu, being a ARM M0 core, might take some time to compute ECC signatures, but it is probably fine in practice.

Our code is designed to be small and portable, so I think it could easily be run on the Tomu. Just need some work to change the USB drivers stuff.

We are using the EFM8UB1 chip to implement the USB HID interface, then communicate with the SAM L11 via SPI.

After considering many MCUs with USB interfaces, it seems to always be more cost effective to get the non-USB MCU and use the EFM8UB1 (from a BOM perspective anyways). The lesser chance of having a backdoor is a plus!

Here's our schematic: https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.p...

Still have to document this better on Github :)

Yes using a normal MCU for U2F is a bit of a compromise since EAL chips are unobtainium. So flash read protection is the main barrier to physical cloning methods.

I'm not sure of any methods to bypass the read protection on normal MCUs in a 10s "drive by" attack. AFAIK, the special companies that provide flash readout (http://www.break-ic.com/), do so by decapping the chip and using involved imaging techniques. I suspect they get good at identifying various flash technologies, many of which are common to many chips. But don't think it's feasible for a drive by.

The I2C eavesdropping shouldn't be an issue because the ATECC508A does apply a mask.

This is a bit late, but the atecc508 does apply a random mask, see PrivWrite command in datasheet.

http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pd...

Yup it will be. I've actually been in touch with Dmitry, he came up with a nice backup solution. We were thinking about coming up with some sort of protocol so devices may initially be designated as this sort of backup.

Typically these keys are designed to be secure against remote attacks (i.e. adverse software on PC can't extract any secrets). If the attacker physically steals the key, he can just use it directly, no need for DPA. So protecting from physical access typically isn't in threat model.

This is a hardware project I started when I was a senior in college. U2F Zero, a open source U2F token / two factor authentication device.

https://www.amazon.com/gp/product/B01L9DUPK6 https://conorpp.com/designing-and-producing-2fa-tokens-to-se...

Brings in around $500-$1000 per month of revenue (when in stock haha). I started just to learn how to lay out a circuit board and make my own embedded device, just kind of took off.

Using the U2F protocol is nice, since it's a standard and the PC side infrastructure is all there for the users to use it. I just have to do the hardware development :)

Also, I'm working on a new U2F token. It supports FIDO2 (password replacement protocol, upgrade to U2F), NFC, USB-C, and will have a nice case. If you're interested, sign up here, we'll be releasing more news soon :)

https://solokeys.com/

ATECC608A is nice but can't provide total key isolation with the key derivation method most U2F keys use. E.g. it calculates the key using an HMAC, it gets sent back to MCU, the MCU writes it as a private key back to the ATECC608A to be used for signature. Also the ATECC608A requires an NDA.

Given this, I think having a 1 chip solution really simplifies the design and allows more flexibility.

We are using a EFM32 Silabs chipset and plan to use some sort of conformal coating to add water/weather resistance. We also plan to have a silicone case. I don't know about getting run over by a car, but they will certainly be resilient to dropping, getting wet, surviving key-chains.

This is a good point and generally a hard issue to solve completely.

Right now, we plan to do the programming ourselves to at least verify that goes okay. Since we are bootstrapping, we are outsourcing the PCB-A, but hopefully since this is pretty expensive threat for an adversary to invest in, I don't think it would be an issue unless we show to have a large market. By then, we can move more supply chain in house :)

FIDO2, possibly some other extensions.

Also planning to have case, USB-C option, NFC option

Yes :(. I've been soldering with paste, stencil, and air gun and have had a good success rate, but it can be a bit more difficult.

I'm thinking about making a short video showing how to solder one reliably for folks interesting in making their own. Unfortunately newer MCUs these days often don't come in easy-to-solder packages.

Thanks!! This next should will come with case and be more robust!

Assuming valid FIDO2/U2F implementation and same origin policy, this shouldn't be an issue. A browser will enforce that the APP-ID/domain name submitted to the token is the same as the origin requesting it. So in order to be tricked into signing into your bank, it would actually have to be your bank requesting the authentication. HTTPS is also a requirement.

A good idea is to store backup codes some place safe. You can use them as one time 2nd factors. Then you can then either disable 2FA, or more preferably, register a different 2FA option.