U2F (Universal 2nd Factor) support possible in mooltipass?

[Bjørn Elias Hesthamar]

I'm reading up on the new USB HID based U2F protocol by the "FIDO Alliance", and it struck me that this kind of functionality would be rather fitting for the mooltipass.

Basically, trough USB HID or NFC a driverless device can receive a challenge from a server and respond with the answer. There are some information here: https://sites.google.com/site/oauthgoog/gnubby

I'm in no way affiliated with Google, Chrome or FIDO. I'm just curious if the mooltipass would be able to talk this protocol or if there are any hardware limitations or other obstacles in the way of implementing this.

[George Trevill]

I agree with this. I recently became interested with the Fido U2F as it solves a lot of the same problems as the mooltipass, however it only helps with co-operating websites/services. There is definitely room for a device that uses U2F where possible and falls back to the mooltipass solution for others. Having everything in one device would be the best of both worlds.

--
You received this message because you are subscribed to the Google Groups "mooltipass" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mooltipass+...@googlegroups.com.
To post to this group, send email to moolt...@googlegroups.com.
Visit this group at http://groups.google.com/group/mooltipass.
For more options, visit https://groups.google.com/d/optout.

[mathieu...@gmail.com]

Hey Bjorn,

Funny you should mention it, half of the links in this page are in purple for me. I therefore hope that this thread will become popular...

I'll first answer your question the short way : 

I don't think we have the space left to implement NIST P256 / SHA256 / 3DES, but we should implement it on a possible mooltipass v2 (smaller, non arduino compatible, arm based).

the long answer/discussion start:

If I'm not mistaken, the main problem with a screen-free U2F (like yubikey) is that there's no way to prevent impersonation.

Imagine the follow scenario:

- you want to login to your bank

- a malicious program (that knows your gmail password) detects it, emits a request to the yubikey (sniffing the DH browser key for example)

- you think you're approving the bank request but are in fact approving the gmail login (by touching your yubikey)

- an attacker gets a session on your gmail account while your bank login process doesn't work

While all the documents are about second factor authentication, Google slides mention a "Register for passwordless experience". I don't understand why this actually isn't the main interesting topic (please enlighten me here).

[mathieu...@gmail.com]

ps: I should emphasize that I hope this will be implemented on all websites / services / computers in the future.

[Andrew]

That's pretty awesome!

--

[Henryk Plötz]

Moin,

Am Tue, 4 Nov 2014 23:36:42 +0100 schrieb "mathieu...@gmail.com"
<mathieu...@gmail.com>:

> I don't think we have the space left to implement NIST P256 / SHA256 /
> 3DES, but we should implement it on a possible mooltipass v2
> (smaller, non arduino compatible, arm based).

Thank you! This arduino-fixation has been really irritating to me for
the longest time. Anybody who wants an arduino can get one already, for
a quarter of the price of the mooltipass, while the core functionality
of the mooltipass is needlessly restricted by the inanities of the 8-bit
AVRs (where everybody outside the arduino community has been basking in
the comfortable embrace of 32-bit ARMs for years).

--
Henryk Plötz
Grüße aus Berlin
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[mathieu...@gmail.com]

Hey Henryk!

Long time no speak :).

You're a bit over-simplifying, it's an Arduino with oled / touch interface / flash in a nice case....

Cheers,

Mathieu

[Warren Besore]

My overall impression of the Mooltipass (v.1) from a user perspective is that it is slow. A v.2 with a better processor would be welcome.

--

[Christopher Hultin]

With that, we might also want to consider additional storage.  I'm not sure if the current amount will be sufficient if we are already running into issues with storage capacity.  If we cannot add features to the device itself in the future, that might be a turnoff for some people.

--
Christopher Hultin

757-742-3141

chris....@gmail.com

[mathieu...@gmail.com]

Hey Warren,

Most of the "delays" you notice are actually manually specified for "smooth" operation (screen flipping, information screen, see userViewDelay(void)...).

Could you tell me which are the ones that makes you feel the device is slow?

Christopher,

I agree that MCU Flash storage would indeed be a bottleneck if we wanted to implement more advanced features like U2F... though I'm quite sure we could implement it now if we decided to remove the bootloader inside the MCU.

[Josh Watts]

Like Mathieu says, the slowness isn't directly the AVR's fault, but rather a side affect of how it was implemented. Everything is done in single threaded fashion: check usb, check inputs, perform action, update screen, repeat.

The real problem, IMHO, is that of program space: we're using just about about every byte if flash, and relying on compiler optimizations to fit the desired functionality. With external, addressable memory or a chip with more space, we could design things in a nicer multi threaded fashion.

[mathieu...@gmail.com]

Hey Josh,

I tend to (slightly-not-so-much) disagree with you: we currently have 3KB+ of flash free while keeping the bootloader, and our beta testers (I guess except you? though you haven't mentioned it yet ;) ) are happy with the core features of the Mooltipass while not requiring others to fully migrate to it. These free 3KB have actually been there for quite a while now.

Let's say we now have 30Kb free to implement all the functionalities we could imagine. From our shared experience (and seeing the U2F specs aha) we can be quite sure that it would take many months (if not years) on a contributor based model to get these coded, implemented and tested by the contributors... and as you know, contributors may have unpredictable events that may reduce their spare time/availability.

I guess that my main point here is that we're starting to reach the limits of our contributor-based model (well, for our scale at least). If we'd scale up to a full-time employees & contributor based model (while staying open source of course), this other strategy would make sense:

- migrate to an ARM based platform to implement all functionalities we can think of: U2F / TOTP / file encryption / public/private key protected firmware upgrades (so users could upgrade their MP v2 at will)

- therefore implementing harder-to-check stuff and having an important user pool test them

- have persons always there for support, development and (things that we're currently not the best on) marketing to keep attracting interest in our product

Feel free to react on this last point, as (as you can guess) I'm a bit biased and speak from experience from our Mooltipass adventure :). Perhaps this could materialize if our campaign is very successful? Though we'd have some serious competition..

Cheers,

Mathieu

[Charles Engen]

I won't get into the enough/not enough memory discussion allowing others with more knowledge speak to that....

But echo support for Mathieu's clear understanding of contributors time availability, additional design expertise and the expertise and time needed marketing everyone's efforts....  These points can't be forgotten or overlooked as they are crucial to getting any project absolutely 100% done.

Essentially I think the first MooltiPass might generate interest and knowledge to enhance with a MooltiPass EXTREME or some other follow up second generation product with more features.  Seems that separating them might allow for more focus to keep our eye on the prize of completion and funding that is needed to get the javascript expertise.  Don't get distracted by adding a screw driver to your Swiss Army knife/can opener ....  (Sorry for that last comment - Mathieu!!)

- Charlie

[Mike Neiderhauser]

--I won't get into the enough/not enough memory discussion allowing

others with more knowledge speak to that....

I remember discussing this topic back when the project first began.

[Henryk Plötz]

Moin,

Am Tue, 4 Nov 2014 14:10:12 -0800 (PST) schrieb Bjørn Elias Hesthamar
<hest...@gmail.com>:

> I'm in no way affiliated with Google, Chrome or FIDO. I'm just
> curious if the mooltipass would be able to talk this protocol or if
> there are any hardware limitations or other obstacles in the way of
> implementing this.

I highly doubt it[*]. As I understand it the underpowered and
undersized microcontroller in the mooltipass is barely scraping by
as-is, even though it's just doing as little AES as possible, but U2F
would require speaking an actual cryptographic protocol with asymmetric
cryptography (the link you provided fixes the algorithms as
ECDSA-with-SHA256, NIST P-256 curve, 3DES-CBC).

https://github.com/limpkin/mooltipass/tree/master/source_code/src/AES
lists the AES performance as ~1.2ms per AES encryption. Order of
magnitude calculation: OpenSSL takes 0.23µs per AES on my laptop, so
it's ~5200 faster. ECDSA NIST P-256 signing takes 0.13ms on this
laptop, thus, using the same factor, would take ~0.7s on the
mooltipass. Verification on my laptop is slower by a factor of about
2.5 (e.g. 1.75 seconds on the mooltipass).
I'm not exactly sure how the protocol looks like, but if it's one
verification (of the server) and one signature (to authenticate) we're
on the order of 2.5 seconds on the mooltipass, plus some overhead. That
might just be acceptable though.

Factors in favour: The AES implementation in the mooltipass is very
inefficient and unoptimized. A clever AES implementation (and by
extension: a clever ECDSA implementation) might be faster, maybe by an
order of magnitude.
Factors against: The microcontroller flash memory will likely not be
enough to store the additional code (more optimized implementations
tend to be bigger).


That being said: Most problems can be worked around by removing the
logic from the poor mooltipass and putting it into an actual, you know,
smart card. This will raise the price per card from ~1€ to ~3-5€, while
dramatically increasing security and convenience. In extension: A
BasicCard could be used to implement U2F with most of the heavy lifting
done in the card (it has cryptographic coprocessors). It's something I
want to look into in the future.


[*] Caveat: "If an elderly but distinguished scientist says that
something is possible, he is almost certainly right; but if he says
that it is impossible, he is very probably wrong." -- Arthur C.
Clarke :)

[Josh Watts]

Yup, definitely the active-ness and breadth of contributors is the major gating factor for MP features.  No argument there ;-)

I just spent a couple minutes looking into existing task/threading systems for AVR, and I found several decent options, one of which is even designed for the ATtiny. If I have time over the next few weekends I'll see if I can get one integrated (probably tinyAcorn) and see how much program space it ends up using. If it seems feasible, retrofitting the logic flow shouldn't be all that hard I think (hardest part might be maintaining timing related issues with the SPI port)

[mathieu...@gmail.com]

Hey Henryk,

Sorry, for some reason your message was filtered by Google...

As for our AES implementation, you're correct even though 1.2ms is more than enough for what we need. We actually switched to our current library from a faster ASM based one because of licensing issues.

As for using a BasicCard, from the discussion we already had, we won't know for sure until someone actually tries it. I think the cost will be more around 3 or 5 euros from the prices I remember. Moreover, the last messages we had (about limited human resources) would also apply and raise other problems.

Mathieu

[Lyle]

Another alternative to consider, if the costs are lower than using a more sophisticated processor, is using another general purpose microcontroller that is relatively cheap, like an Attiny85. This can act as a cryptographic co-processor and the main processor can offload some other additional tasks if sufficient space is available. The Attiny85 costs around 2 euro if I recall. That being said, I might be way of base on this one since I have little experience with implementing consumer grade hardware and the costs of development involved.

This message and attachments are subject to a disclaimer. Please refer to http://www.it.up.ac.za/documentation/governance/disclaimer/ for full details.

[M.Borrego]

Hey Mathieu, the time of AES you have posted here is using precomputed s-box in Flash memory ?

--