I’m not going to mince words, this is going to be a rant and it’s going to get messy. There’s going to be diagrams and everything.

The Flipper Zero is amazing. It has an amazing capability set that is growing weekly, and is a great entry-level (Or perhaps not even entry-level depending on how hardcore you get) tool for exploring signals, networks, and computing. Kissing the ring aside, the addition of U2F capabilities feels like a mixed bag for a few key reasons. To get there though I’m going to have to create the universe first. To start…

This isn’t Perfect

I am certain I am going to miss a bunch of little things here around FIDO, U2F, authentication and authorization, best practices, and the larger context. I’m going to do my best, but I’m fallible. You know where to find me if I mess up, I’m but an email away.

That said there’s a bunch of points that need to be discussed to get us to why U2F on the Flipper Zero is a mixed bag.

Where we’re going to go on this journey to be an old man yelling at a cloud is as follows:

  • An overview of FIDO and why it matters
  • An overview of U2F
  • An overview of authentication under U2F
  • What this means to a Yubikey
  • What this means to a Flipper Zero

And with that we’re out of the gate, let’s go.

Terms and stuff

Honestly I was going to type up a whole mess of terms here you should vaguely understand. Instead, I’m going to throw the The IDPro Terminology Reference at you and hope something sticks. I use other terms here outside of that, and DuckDuckGo will probably be your friend. Stay strong.

Okay so what is FIDO?

Not FIDOFIDO
Not FIDOFIDO

FIDO, or the Fast Identity Online Alliance, is an industry group that contains a whole mess of companies. As a group they at least pretend to care about securing the authentication process. The general idea is to use public key cryptography to support authentication processes, as opposed to a username or password. This same pattern has been used in US government operations for a long time with Common Access Cards and Personal Identity Verification as well as other high-security environments, but FIDO’s goal is to bring this pattern to common folks. I don’t want to dive in too deep here on established design patterns but there are basically two ways forward here- software-driven and hardware-driven. Software-driven examples are Passkeys , while hardware-driven examples might be a Yubikey. Each of these might work across different protocols within what FIDO has built (For instance a software passkey won’t work under old specs), and I won’t get into the range of specs FIDO has built, except one. U2F.

U2F for Dumdums

U2F stands for “Universal Second Factor”, where the factors of authentication are typically “What you have” (In this case the U2F device) and “What you know” (Typically a password/PIN), so for the sake of discussion we’ll pretend that is the case moving forward. The flow for using U2F is pretty straightforward.

  • A user wants to access a given system (Local or remote, doesn’t matter).
  • System requests credentials; their username/password.
  • User presents their first set of credentials.
  • System verifies first set of credentials.
    • If they aren’t valid, kick the user out, make them try again.
    • If the credentials are valid, great!
  • System sends a challenge back to the user (Their browser, terminal, whatever).
  • User presses button on U2F device, which sends a response.
  • System verifies the response.
    • If the returned response is not valid for whatever reason, kick them out, make them try again.
    • If the returned response is valid, great!
  • System lets the user in.

Makerdiary created the following flow, which is pretty spot on:

Makerdiary-flow

Some things to note about U2F that aren’t really talked about:

  • The challenge-response is in SHA-256 (A hashing algorithm). In fact SHA256 does a lot of heavy lifting in U2F, hashing not only challenges but application information and the like. More info here. Yubikey uses HMAC-SHA256, FIDO spec calls for HMAC to be used as well.
    • To dig in just a little more here, HMAC-SHA256 is a type of Hash-based Message Authentication code. a Message Authentication Code provides a mechanism of authentication itself- it allows a recipent to take the message and verify it by performing analysis using the underlying MAC algorithm to determine veracity. An HMAC is a unique sort of MAC because it relies on a shared secret (And a bunch of other stuff but we won’t go there).
  • U2F relies on the secp256r1 curve for key pairs. This is a different curve than most cryptocurrency bros are used to (secp256k1). There is a lot of discussion around secp256r1 out there in crytpo circles if you go digging and it can eat a few days.
  • U2F gets really weird about supporting N services with unique key pairs. U2F uses what is called a “Key handle” to identify a user’s private key. This key handle is actually wild and I need you to read what the definition is straight from the spec because this sounds insane:
    • “A key container created by a FIDO Authenticator, containing a private key and (optionally) other data (such as Username). A key handle may be wrapped (encrypted with a key known only to the authenticator) or unwrapped. In the unwrapped form it is referred to as a raw key handle. Second-factor authenticators must retrieve their key handles from the relying party to function. First-factor authenticators manage the storage of their own key handles, either internally (for roaming authenticators) or via the associated ASM (for bound authenticators)”.
    • Now if this is done securely (Wrapped using a secret only known to the U2F device etc) this isn’t terrible but it means the private key leaves the U2F device you’re using. There are novel approaches to this issue to keep the private key from being transported off of the U2F device.
  • U2F takes great pains to perform origin-binding, such that it makes it extremely hard to peform a MITM attack. Part of this magic relies on U2F being sent over TLS (Which offers a degree of message authentication already, as well as message integrity). What this means is to MITM a U2F response you’d need to not only have proper certs, you’d need to disable Channel Binding at the system performing the responses.
  • The U2F standard describes mechanisms to determine whether or not a device has been cloned or “valid”- shared attestation key pairs across large batches of U2F devices is an example they drive home. Another practice they mention is usage counters- U2F devices should remember the number of operations it has performed, and this counter is sent back to the server as well as used in other places in the process. This is akin to sequence numbers in TLS, but unlike TLS this counter isn’t mandatory to be checked and as I’m sure you can guess, it ends in tears.
  • The way U2F is supposed to be implemented, you should be able to use a U2F device with a different user account in a a given system, and the system will not be able to differentiate. However, depending on how the U2F device does what it does, this isn’t always the case. There are issues both at U2F device level as well as receiving system level that can make this not actually happen.

Anyway the full spec can be found on the FIDO alliance website if you decide you hate yourself.

What Does This Mean for Yubikeys?

To many, Yubikeys are considered the gold standard of U2F / FIDO physical keys. Let’s talk about why without getting too friendly with them, because they have absolutely have their issues and detractors.

  1. Modern Yubikey guts (The Neo5 for instance) are surrounded by a plastic that do not dissolve in most household solvents, see the teardown at Hexview. This means it’s pretty evident if the insides are tampered with, as you basically need to melt off the outside. To a determined attacker this isn’t a huge deal, but someone looking to be covert has substantial issues from the start.
  2. Modern Yubikeys rely on a fairly advanced security chipset (The Infineon SLE 78CLUFX5000PH) to do the heavy crypto lifting. It has some built-in security features from everything I can find on it, but frankly I can’t find much because Infineon (As well as Yubikey) keep production firmware and security mechanisms out of public view This proprietary and walled-off nature of Yubikeys is generally a bad thing, but Yubikey if anything have proven they’re pretty serious about keeping on top of found issues.
  3. Older Yubikeys that relied on NXP chipsets had attacks that could be done to reconstruct private keys, but this requires an extreme amount of effort. In fact this is a broader attack against NXP chips.
  4. Yubikeys are entirely powered by NFC (If they have an NFC component) or by USB. They require no battery, and as such will last as long as the contacts on the USB side don’t break. One complaint about Yubikeys is the relative fragility of the contacts, but over the several years I have used them I haven’t had issues.
  5. Yubikeys are relatively cheap as a hardware token / certificate solution. Consider that the Department of Defense’s Common Access Card (CAC) costs over $100 USD per CAC, and this doesn’t include the extra cost per reader required- this figure appears to be the full cost of credentialing. PIV cards are cheaper, costing $30 USD per card but prices add on top of that- for a year of access you’re looking at approximately that as well. That is approximately the price of two Yubikeys.

I didn’t Know you Were a Yubico Salesman, now Tell me About the Flipper’s U2F

Okay so let’s compare the Yubikey against the Flipper.

Obviously the Flipper Zero is going to require battery power to do what it needs to do. This isn’t a downside; the Flipper Zero isn’t built to be an end-all be-all hardware token, by plugging it in to do U2F you can get it powered. Speaking to cost, the Flipper Zero is weirdly not too much more expensive than a CAC card. The Flipper Zero doesn’t currently support U2F over NFC, but to be fair here it could in time. That leaves us with two real places to go to then- physical access to the guts, and then what we can do with the guts afterwards.

Ripping into the Flipper is easy (RU Link, translate if you want). Aside from that there are U2F available over the SD Card that could be exfiltrated. So what does this look like? Well… The file structure for the Flipper looks something like this. As we can see in the example:

u2f_filesystem_tree

We’re left with four real files to worry about. These files are all listed as specific and separate filetypes, E.G…

/u2f/cnt.u2f: cnt_u2f

/u2f/key.u2f: key_u2f

/u2f/assets/cert.der: cert_der

/u2f/assets/cert_key.u2f: cert_key

(All snippets courtesy from the above flipperdevices repo that we got the file structure from)

These files, while they look unencrypted are (thankfully) ultimately generated on first time setup of the Flipper and are encrypted by a device unique AES-256 key (32 bytes) that is stored in the Flipper Zero’s STM32WB55RG (In the secure enclave, the flash memory on the MCU). Which, fair! If we look back at the way U2F is supposed to manage certs and encryption this is a fair take- we are decrypting relevant U2F information at runtime and processing accordingly.

As a quick aside on AES… AES is a block cipher, and by the nature of being an encryption method you can both encrypt and decrypt a message- it is not one-way like a hash. It generally relies on a key, an IV (Initialization Vector), a mode (The algo used to encrypt within AES), and some input. This input is padded when necessary (Because block cipher) in order to cleanly perform encryption. A great overview on AES can be found here. If you know all of these components it’s trivial to encrypt and decrypt- if you have some time you can play around with this on CyberChef.

I say all of that to say that it’s crucial to understand the key becomes the linchpin of encryption; without protecting the key, the encryption isn’t much better than a glorified encoding scheme. A great deal of effort across both private and public sector goes into how to properly manage private keys and other such secrets.

What this means is if we have physical access to the Flipper Zero, we can attack the STM32 through a number of ways to get a hold of that AES-256 private key; reverse engineering among them. Indeed from the Flipper Zero Discord that I feel encapsulates the core issue here:

Flipper_zero_commentary

Does This Even Matter?

We need to understand that concepts like “Tamper resistance”, the strength of a given chip’s secure enclave, and so on matter to an extremely small degree for a vast majority of consumers. The average person looking to make access to their bank accounts more secure aren’t going to need to worry about a threat actor taking their unguarded Flipper Zero, disassembling it, getting at the STM32 chip, and so on. The average person isn’t being persued by antagonists that have nation-state capabilities, or even advanced capabilities. These concerns are absolutely valid and we should build capabilities that are sound from a security perspective, but they don’t speak to the reality of the masses.

Consider that many, many, many more data compromises are caused by human failures than technological ones, by and large because humans are easy to exploit whereas relatively secure systems are not. This isn’t to disregard aiming for best practices, but we must not let perfect get in the way of good. If the Flipper Zero exposes people new to security to U2F (Or FIDO2, which the Flipper Zero team is looking to implement), that is a beautiful thing and we should encourage that.

Also consider that with the advent of FIDO2, WebAuthn, and CTAP that U2F is being deprecated, with some browsers and authentication services already doing so in favor of WebAuthn. U2F is dying the slow death of all authentication mechanisms, continually supplanted. Maybe one day we’ll get it right.

A final note

Yubico has a great site that you can use to play around with U2F, and I would be remiss not to mention it here.