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.