You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
Reacted by Adrian Lucrèce Céleste, Mohamad Ismail, David Adam Coffey, Bobby Gammill, Arnaud Durand, Lin, Harrison Powers, Nicolai Søborg, Carlo Alberto Ferraris, Yasuhiro SHIMIZU and 2 more
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
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.
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.
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.
Reacted by Conor Patrick, Ryan Hurst, Dmitry Cheryasov and Wim Lewis
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.
@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.
@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
@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 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 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.
Activity
al177 commentedon Mar 19, 2018
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 commentedon Mar 19, 2018
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 commentedon Apr 27, 2018
The Nordic Semiconductor nRF52840 datasheet claims that it embeds a ARM-CryptoCell-310 which should support ECC
conorpp commentedon Apr 28, 2018
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 commentedon Apr 28, 2018
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 commentedon Apr 28, 2018
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.
conorpp commentedon Apr 28, 2018
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 commentedon May 4, 2018
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 commentedon May 5, 2018
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 commentedon May 5, 2018
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 commentedon May 5, 2018
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 commentedon May 10, 2018
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 commentedon May 10, 2018
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 commentedon May 11, 2018
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 commentedon May 11, 2018
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.
20 remaining items
Immortalin commentedon Jul 31, 2018
Any thoughts on the ATECC508A? It's also a pretty popular chip.
conorpp commentedon Jul 31, 2018
@jans23 True, but of the ones with 128KB+ available memory and ARM M3 or M4, there aren't any USB options.
al177 commentedon Jul 31, 2018
@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 commentedon Jul 31, 2018
@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 commentedon Jul 31, 2018
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 commentedon Jul 31, 2018
@NovaaRF I am not affiliated with @conorpp, but I feel like a public forum is not the best place to discuss such matters.
gonzopancho commentedon Aug 17, 2018
@Immortalin I’m not sure why the focus is on the ATECC508, when the 608a is out.
Immortalin commentedon Aug 17, 2018
@gonzopancho annoying that it still doesn't support AES 256 and above
Zjemm commentedon Sep 4, 2018
@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 commentedon Sep 4, 2018
@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 commentedon Sep 12, 2018
@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 commentedon Sep 12, 2018
@Zjemm Or even Gitter / Discord?
Zjemm commentedon Sep 13, 2018
@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 commentedon Sep 13, 2018
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 commentedon Oct 7, 2024
I don't know if people have said it, but NRF 52840 dongle is a good choice.