search

conorpp / u2f-zero

U2F USB token optimized for physical security, affordability, and style
Other
2.42k stars 203 forks source link

Upgrade microcontroller/design #76

Open conorpp opened 6 years ago

conorpp commented 6 years ago

I'm considering upgrading the microcontroller on U2F Zero to support more functionality. Some features that would be nice:

A couple microcontrollers that I like:

Thoughts/comments/questions?

al177 commented 6 years ago

Would it make sense to switch to EFM8UB3 as a stopgap? They are footprint compatible with UB1 and offers 40k flash and 3k RAM vs the 16/2 of the current part. Development could go forward on keystore type applications without having to roll out new hardware.

thearkadia commented 6 years ago

bluetooth that works only when i press the button is a lot better than NFC in my opinion since nfc is rarely used and bluetooth would work better out of the box for laptops and smartphones (and the ark) from what i understand

the NFC key does the "only work when pressed" in an interesting way https://www.youtube.com/watch?v=jHH1Tiufzvo

ideally i would have a u2f key with bluetooth that works from my necklace to my laptop and a seperate crypto key i could keep in safe locations.

YakBizzarro commented 6 years ago

The Nordic Semiconductor nRF52840 datasheet claims that it embeds a ARM-CryptoCell-310 which should support ECC

conorpp commented 6 years ago

I think EFM8UB3 could be a nice quick upgrade to U2F Zero. I'm thinking about making an official upgrade to that.

I must have initially missed the nRF52840 CryptoCell. That solves the crypto acceleration and even offers other asymmetric algorithms (RSA) which might provide more flexibility for FIDO 2. I don't think it offers any sort of tamper resistance or private key readout to protect from exploited firmware. But I still think it's a pretty nice option.

@thearkadia I agree, Bluetooth seems ideal. The big potential pain I see is including a battery and having to keep it charged. I'm going to start prototyping soon and hopefully get some power consumption numbers.

rmhrisk commented 6 years ago

I have looked into the nRF52840, it provides only acceleration and no key protection or other security isolation concepts. That said it looks like a great platform if you don’t need that and want BT and NFC.

MaPePeR commented 6 years ago

I would prefer nfc over Bluetooth because it can work without a battery.

So an open source version of this reference implementation would be the great.

The USB/NFC reference design provides USB for Laptop and PC access while the NFC interface enables mobile devices like cell phones and tablets.

conorpp commented 6 years ago

AFAIK, ISO 14443/NFC ICs (the ones that can be powered just by the interface) are difficult to get a hold of. Only sold to businesses with high enough volumes, NDAs, etc. Getting one of them to work with an open source project might be tricky and people wouldn't be able to purchase and program their own easily. I don't know of any that you can just buy from a distributor.

I tried going through the NDA process for one of NXP's A7005 secure microcontrollers through Avnet but they never got back to me. It might be worth trying again.

MaPePeR commented 6 years ago

What about LPC8N04FHI24E? It claims to be ISO 14443.

(I searched for "NFC" ICs on Mouser and don't know a lot about ICs/NFC, so this might be a stupid suggestion)

conorpp commented 6 years ago

Nice find! LPC8N04 family would work for passive operation. The ARM M0 core may be too lightweight for computing ECC signatures (sec256r1/P-256 for U2F) and would take on the order of 1 second to compute 1 signature. I think that would be too long for normal NFC readers.

That's encouraging though, maybe there is an attainable ISO 14443 option out there.

MaPePeR commented 6 years ago

I think we want to use a separate security IC for storing the key and doing the ecc calculations anyway.

I remember that during my search I found nfc ICs that could provide the gathered power. And that should be enough to power such a security IC or otherwise we wouldn't have non battery nfc keys already on the market.

conorpp commented 6 years ago

I believe most security keys on the market use single chip solutions i.e. with both ISO 14443 and asymmetric crypto peripherals. Getting acccess to something like that I think would be best.

I think the claimed energy harvesting for the LPC8N04 is just for powering the chip. I don't see any specs or applications for using harvested energy to power other chips. It's not very clear from the data sheet but NXP has these two app note videos (one, two) for the LPC8N04. For the "energy harvesting" demo, they just read and write to the chip's internal flash. For the "IoT sensor" demo, they use a coin cell rather than power the external sensor via NFC. I suspect other energy harvesting NFC chips to be similar, but I could be wrong.

Not to say it can't but done, but I think it would be challenging. Asymmetric crypto operations are not typically low power either. For the ATECC508A, it will peak at around 15 mA when computing signatures.

MaPePeR commented 6 years ago

The NT3H1101W0FHKH claims to provide "Energy harvesting functionality to power external devices (e.g. microcontroller) " and is ISO/IEC 14443 Type A compatible. (Datasheet)

One feature i would really like from an NFC-Key, which the solutions on the market are missing is: Need to press a button to authenticate with NFC. They claim its a feature, that you don't need to press a button. I think otherwise.

eric-appion commented 6 years ago

I'm in favor of using the Nordic nRF52840. Contrary to the statement at the start of this thread, it DOES have hardware support for cryptography, including ECC.

ARM TrustZone Cryptocell 310 security subsystem:

I've been doing a lot of work lately with the earlier nRF52832, and have used the nRF52840 a little bit.

Back when this thread started, the nRF52840 was not yet in volume production, but it is now, and is in stock at distributors including Digi-Key.

conorpp commented 6 years ago

The NT3H1101* datasheet reports that it can typically harvest 5 mA @ 2V of power from a normal mobile device NFC reader. I wonder if this could power the nRF52840? With all peripherals turned off except to do 1 hash and 1 ECC operation with the crypto cell. The current datasheet doesn't seem to have good power consumption numbers yet. Does this sound crazy?

al177 commented 6 years ago

nRF52840 runs down to 1.6V. You could put in a supercap and gate power to the nRF52840 until it's charged above that level. But SMT supercaps that would keep the nRF alive long enough to complete the transaction are either very expensive and small or moderately expensive and about the size of a coin cell.

It would make more sense to use a primary coin cell or tiny LiPo in and get some use out of the Bluetooth functionality as well.

ghost commented 6 years ago

I agree with the need of NFC and Bluetooth, but they need to be made such a way that they need to be individually manually activated each time one wants to use that individual feature. (Always on NFC is the dumbest thing I ever seen and is available in all most all new debit and credit cards this days... and hackers/ criminals taking advantage of that is obviously a reality that this company's want to hide any way they can, including sueing tv show's and others to make sure the information doesn't get the general public has people could start demanding the governments to forbid this technology.)

A rechargeable/ changeable battery that can be recharged by usb connection and that can be easily changed when no longer holds the charge needs also to be taken in account.

Since this technology is being changed from second factor of authentication to just the one and only way authentication is made I thing is necessary to review all the concept of a small device to something that can protect it self by requiring people to enter some sort of password before allowing to use (note that fingerprint is not a password... should be something you know... not another thing you have/ you are)... otherwise anyone that gets to hold it physically (I'm thinking: boarder agents, people stealing, ...) can immediately impersonate the user... precisely what this technology should be preventing in first place! And without password protection or even some sort of derived private key that is created based on that password (something SQRL - Secure Quick Reliable Login uses to allow in their case to use the same private key in the same web site with multiple accounts... but this has the benefit to allow the user to personalize to its taste the "login" such that even if their private key is obtain people still can't enter on the web sites unless they know that information also) anyone can just use it... and that is not nice when is your first and only factor of authentication.

Something that is not in the specs but should be taking in account is the availability of other than NIST ECC curves since this are known to be weak ( https://safecurves.cr.yp.to ) better ones are for example Curve25519, Ed448-Goldilocks and for example E-521. This availability will allow third party's to develop a better and more secure authentication mechanism... I'm thinking Wordpress/ Drupal/ Joomla! and many others CMS's plug-ins for example.

MaPePeR commented 6 years ago

Since this technology is being changed from second factor of authentication to just the one and only way authentication is made I thing is necessary to review all the concept of a small device to something that can protect it self by requiring people to enter some sort of password before allowing to use

I don't see this happening. This device is designed to be a second factor. Adding a password prompt to it would only make it more cumbersome to use. Especially requiring more buttons on the device and the user to remember another password, which defeats the purpose. I agree, that the device only should authenticate when the user is actively allowing it to function and not be always on, though.

Something that is not in the specs but should be taking in account is the availability of other than NIST ECC curves since this are known to be weak

Even though i agree with that claim i don't think we can change that. FIDO U2F devices can only function, when they fulfill the standard. The usage of the weak curve is written into the standard, if i'm not mistaken.

conorpp commented 6 years ago

@JoaoPortugal Yes I agree, Bluetooth will need to have a battery but the NFC interface should not depend on it, and passwordless login will need support for a pin code. @MaPePeR FIDO (and other companies) intend FIDO2 to be used for passwordless login; FIDO specifies how to set, change, and use PINs for this I believe.

Adding a set of buttons and display might be cumbersome, although some of the bitcoin wallets seem to have found success with using a small display and 2 buttons. I don't think that it would work while using the NFC interface though haha. The board could be laid out in two versions: password-less support version (with pin codes), 2FA version. (see next comment)

nRF52840 does have support for other curves (like Curve25519) so adding support for those is a good idea.

conorpp commented 6 years ago

I've been reading the FIDO2 spec regarding pin codes and there isn't a need to put a display and set of buttons on the device. The platform/client assumes most of the burden of a pin.

A FIDO2 token (authenticator) supports having a pin code set on it (via the platform). A platform will subsequently need to have the pin input to be able to register or authenticate to the authenticator. Encryption, HMAC, shared secrets are used so that the pin isn't ever shared in the clear on the wire. It's not clear to me what's stopping a thief from just setting a new pin code and using that, but I'm guessing the platform will have to be smart and require a password if the pin-code is changed.

jawnmon commented 6 years ago

Have you looked at the Signet project so the device can also work as a password manager? https://www.crowdsupply.com/nth-dimension/signet

conorpp commented 6 years ago

I think extra functionality like a password manager would be neat. FIDO2 aims to replace passwords so I might be more interested in a host based password manager that just converts FIDO2 to a password for sites that haven't implemented it yet.

conorpp commented 6 years ago

I took some power measurements, hopefully it'll be clear if NFC charging a supercap is feasible.

It takes about 35 ms for either authenticate or register and draws about 10 mA from a 2.5V coin cell.

I have a "draft" of a FIDO2 implementation and programmed it onto the NRF52840 preview DK. I set up a test for the authenticate and register commands and measured the time and power consumption. SHA256 and ECC is hardware accelerated. Only the SoC is powered and no peripherals aside from timer and cryptocell are used. The NFC interface isn't used. Measurement done using crappy oscilloscope and shunt resistor.

A cap like this I believe could work: https://www.digikey.com/product-detail/en/eaton/KR-5R5H474-R/283-2821-ND/1556249

But it would take on the order of 10-100 seconds to charge from an NFC reader. So I think this might be infeasible.

MaPePeR commented 6 years ago

It takes about 35 ms for either authenticate or register and draws about 10 mA from a 2.5V coin cell.

So you said earlier:

The NT3H1101* datasheet reports that it can typically harvest 5 mA @ 2V of power from a normal mobile device NFC reader.

So do you have a conclusion now? Is that difference solvable with a capacitor for power storage?

For the M24LR16E-R there is more detailed information about the harvested energy: (Page 131)

image

Edit: didn't see your edit before writing the post.

dmazzella commented 6 years ago

Have you see stm32wb?

sbrl commented 6 years ago

Should I wait on buying one of these until the new version is available, or buy one now?

Edit: I can't buy one anyway, because they are out of stock in Europe :confused:

NovaaRF commented 6 years ago

Very excited for an nRF52 version! Let me know if I can help on the layout/rf side.

It takes about 35 ms for either authenticate or register and draws about 10 mA

This would be dwarfed by any sort of LED indications the user gets (likely 10mA over 300ms, before and after auth?)

Assuming some 600ms at 10mA, 10x a day + 2uA drain 24/7, that amounts to ~5mAh (LEDs) + 17.5mAh (drain)/year A small 50mAh lithium primary cell doesn't seem terrible if it lasts a couple years.

Immortalin commented 6 years ago

@conorpp support for ssh/TLS/x.509 key-gen/CA signing would be very attractive!

conorpp commented 6 years ago

@Immortalin can you elaborate what you mean?

marcelorodpinheiro commented 6 years ago

What I found atractive in u2f zero was that it was so inexpensive i could lose one and replace it with another exactly like my bike key or my house key. Buy a batch of 3 or 4 , register them together where needed, store at least one in a safe (aka socks drawer) and you are good to go. How much is the new version expected to cost? Is there a roadmap with goals and milestone we want to achieve with this upgrade? I want to contribute if possible.

Examples of goals:

conorpp commented 6 years ago

Yes, U2F and FIDO2 will both be completely supported. It will also permit firmware updates over USB (signed). I've tested NRF52840 chip and EFM32 Jade/Pearl micros.

What I like about EFM32 series, is that they are pin compatible with Silab's EFM32 Blue Gecko (Bluetooth SoC). So in theory, a single PCB could be use for USB only or Bluetooth operation. EFM32 jade/pearl don't have USB so a EFM8UB1 can be used to cheaply bridge to USB. I haven't used Blue Gecko before, so open to feedback.

EFM32 also seems more power efficient that NRF52. Recently I was able to get full FIDO2 operation running, powered only by phone NFC via NT3H2111 (cc @MaPePeR). Then I figured out I need a Type 4 tag for FIDO, not Type 2 haha. So I'm going to try AMS AS3955 next. I have confidence :)

Not really microcontroller related, but I've been testing printing enclosures on an SLA 3D printer. I printed 2 parts that snap together tightly. I think so far they have come out pretty well.

These are the goals I have.

I was thinking NFC support could be added by simply adding the NFC IC and a flat coil that can be embedded in enclosure. Maybe similar for Bluetooth down the road.

I don't have a roadmap outside of this thread. I'll start toward releasing what I have and setting up a mailing list to better organize development.

jans23 commented 6 years ago

EFM32 jade/pearl don't have USB so a EFM8UB1 can be used to cheaply bridge to USB.

I don't think this is true because Tomu uses just an EFM32 without a separate USB bridge.

Immortalin commented 6 years ago

https://lauri.xn--vsandi-pxa.com

https://developers.yubico.com/PIV/Guides/Certificate_authority.html

@conorpp

Immortalin commented 6 years ago

Preferably key-gen can be done solely on-key too but that's going to make backups difficult...

Immortalin commented 6 years ago

https://dennis.silvrback.com/openssl-ca-with-yubikey-neo

Something like this.

This would be a killer function as most smartcards don't have proper CA features.

Immortalin commented 6 years ago

Any thoughts on the ATECC508A? It's also a pretty popular chip.

conorpp commented 6 years ago

@jans23 True, but of the ones with 128KB+ available memory and ARM M3 or M4, there aren't any USB options.

al177 commented 6 years ago

@Immortalin The current design uses an ATECC508A. Some of the discussion here is around micros that have integrated crypto to eliminate the need for a separate keystore.

As for EFM32 Jade/Pearl Gecko lacking a USB device interface, maybe this could be adapted for USB-LS HID: https://github.com/MarkDing/lufa-efm32

conorpp commented 6 years ago

@Immortalin Yeah that sounds totally doable. Could be implemented as a vendor custom command and then a custom script/program could used to load private keys or do signing.

NovaaRF commented 6 years ago

RE the bluetooth capability--are you considering a real FCC certification, or just selling them as "development boards"? I wonder how chill they would be if there's a couple thousand coming through amazon

rkrasin commented 6 years ago

@NovaaRF I am not affiliated with @conorpp, but I feel like a public forum is not the best place to discuss such matters.

gonzopancho commented 6 years ago

@Immortalin I’m not sure why the focus is on the ATECC508, when the 608a is out.

Immortalin commented 6 years ago

@gonzopancho annoying that it still doesn't support AES 256 and above

Zjemm commented 6 years ago

@conorpp, im looking to buy a solution for storing ssh keys and pgp keys en do 2fa/fido. I found the yubikeys and later i found your project u2f-zero. i noticed they are out of stock and then i found this topic.

do you have any idea on releasing a new version? im really curious and like this whole project

conorpp commented 6 years ago

@Zjemm Planning to open new project later this week. I have a progress update here: https://conorpp.com/designing-solo-a-new-u2ffido2-token

Planning to support SSH / PGP keys :)

Zjemm commented 6 years ago

@conorpp It might be a nice idea to start a community room on the matrix.org (synapse/riot) platform? users/devs could talk/discuss there matrix is a great open source platform for that idea?

sbrl commented 6 years ago

@Zjemm Or even Gitter / Discord?

Zjemm commented 6 years ago

@sbrl i'm not familiar with those :) Matrix.org is nice because it's open-source / decentralized / quickly growing in the community, and lots more. but its just a suggestion.

conorpp commented 6 years ago

Open sourced the code! Contributors are more than welcome. https://github.com/SoloKeysSec/solo

Still working on the hardware :)

I opened some new issues over there. A recent chip I found was the SAM L11 which provides an impressive number of security features, low power, cheap.

sriharshaguthikonda commented 10 hours ago

I don't know if people have said it, but NRF 52840 dongle is a good choice.