Upgrade microcontroller/design
conorpp opened this issue · comments
I'm considering upgrading the microcontroller on U2F Zero to support more functionality. Some features that would be nice:
-
More program memory.
- Makes room for bootloader, configuration functions, and application to all fit in same firmware and simplifies the setup/flashing process. The current programming process could be greatly improved.
- More room for other services. PGP, encrypted storage, bitcoin wallet, etc.
- Crypto could be implemented in software and DPA countermeasures could be added. This is a double edged sword as it would become more vulnerable to software vulnerabilities.
-
More interfaces
- NFC and Bluetooth interfaces
A couple microcontrollers that I like:
- Silabs Pearl Gecko. It has a lot of program memory and has hardware encryption peripherals built in, including 256 bit ECC. I'm not aware of any other MCU with asymmetric crypto hardware that can be purchased without an NDA. No U2F interfaces though.
- Nordic Semiconductor nRF52840. Plenty of program memory and supports BLE and NFC. The NFC cannot be powered from a reader though and would need a battery. Bluetooth would need a battery anyways. There are no ECC peripherals so crypto operations would need to be done in software or offloaded to something else.
Thoughts/comments/questions?
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.
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.
The Nordic Semiconductor nRF52840 datasheet claims that it embeds a ARM-CryptoCell-310 which should support ECC
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.
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.
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.
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.
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)
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.
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.
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.
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.
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:
- NIST SP800-90A and SP800-90B compliant random number generator
- AES-128: ECB,CBC,CMAC/CBC-MAC,CTR,CCM/CCM
- Chacha20/Poly1305 AEAD supporting 128- and 256-bit key size
- SHA-1, SHA-2 up to 256 bits
- Keyed-hash message authentication code (HMAC)
- RSA up to 2048-bit key size
- SRP up to 3072-bit key size
- ECC support for most used curves, among others P-256 (secp256r1) and Ed25519/Curve25519
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.
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?
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.
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.
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.
@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.
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.
Have you looked at the Signet project so the device can also work as a password manager? https://www.crowdsupply.com/nth-dimension/signet
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.
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.
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)
Edit: didn't see your edit before writing the post.
Have you see stm32wb?
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 😕
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 can you elaborate what you mean?
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:
- Comply to u2f AND fido2 (complaint to which parts?)
- Do optional feature X.
- Cost X$
- have more than 1 version of the board possible using the same base microprocessor. ( optional parts left blank for soldering or whatever)
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.
- FIDO2 + U2F + space for easily adding stuff if wanted
- Simple GNU based build system and PC based development option for contributors.
- USB
- passive NFC option
- Potential for Bluetooth option
- Easy to embed in 3D printed enclosure.
- <$10 in parts
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.
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.
Preferably key-gen can be done solely on-key too but that's going to make backups difficult...
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.
Any thoughts on the ATECC508A? It's also a pretty popular chip.
@jans23 True, but of the ones with 128KB+ available memory and ARM M3 or M4, there aren't any USB options.
@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
@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.
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
@Immortalin I’m not sure why the focus is on the ATECC508, when the 608a is out.
@gonzopancho annoying that it still doesn't support AES 256 and above
@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
@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 :)
@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?
@Zjemm Or even Gitter / Discord?
@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.
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.