YubiKey comes to the iPhone with Mobile SDK for iOS and LastPass support | Hacker News Reader

YubiKey comes to the iPhone with Mobile SDK for iOS and LastPass support

yubico.com

113 pointsthrowwwafgk57 comments

If I’m authenticating with “something I have” then why not use the iPhone itself which also happens to add a layer of “something I am” (FaceID) as well as easily supporting entry of something I know (PIN or password).

Using a hardware token to authenticate to an app on an iPhone makes about as much sense as.... sorry, it makes absolutely no sense at all.

I trust the secure element on the iPhone a lot more than I trust the hardware on the Yubikey.

The days are numbered for this whole idea of a separate piece of hardware USB/NFC to do authentication. If I’m adding a “something I have” factor to my authentication flow (or even making it the only factor) it’s going to be the phone hardware itself, not an extra dongle thing I have to carry around.

FIDO’s upcoming CTAP unfortunately is going about it the wrong way, IMO. I don’t want to have to establish NFC or Bluetooth from my iPhone to my desktop to enable me to use my iPhone to authenticate on my desktop. It’s entirely unnecessary since both devices are already online. They are designing for a corner case which makes the primary case too complicated.

Do iPhones allow access to the underlying TPM devices?

I personally don't believe things like Google Authenticator are a good "something you have" second factor as the "something you have" is just a string stored in a sqlite database. Much easier to covertly copy that than a hardware key where the string is burned into the key.

I don't think theres much value in "something you have" so much as there's value in "approving this authentication via another device". Adding an additional device to compromise running an entirely different platform makes attacks much more difficult, even if we're talking about a poorly secured Windows machine and outdated Android phone. Enough to make you effectively invulnerable to almost all non-targeted attacks which will only breach one side or the other.

Yes, iPhones allow storing data that can’t leave the device. Otherwise OTP apps would be pointless.

I don’t know the details, but some apps use it to store OTP secrets. Eg. if you use the DUO app, your secrets will be backed up, but they can only be restored on your phone. (was quite a hassle to reset 2FA on all the websites after my phone was replaced in warranty repair)

Not sure what Google authenticator does.

Are iOS Authenticator apps actually calculating OTPs on the Secure Element? Is there a way to execute arbitrary code on it? If not, they have to pull the keys off to the main CPU where they're open to attack like anything else. Still secured as private app data, still mostly protected, but an attacker with a jailbreak could still dump them.

I know for a fact I can dump Google Authenticator keys from my Android device with root as I'm able to back it up and move it to another device. Theoretically on most Android devices even there's a secure enclave available that could do it, yet I haven't seen any apps use it.

Most of the benefit of OTPs really comes from approving on a secondary device rather than protecting the keys to an absolute degree though, so this is probably of little concern to most users. In fact it may provide a convenience benefit, I like being able to backup and move my keys, without that I probably wouldn't use 2FA at all.

Using the secure enclave, you (as a developer) can have it generate a private key you'll never be able to get and then ask it to sign / encrypt (symmetrically) arbitrary things for you.

https://developer.apple.com/documentation/security/certifica...

AFAIK that means it'll take more than a jailbreak to get to them, although I don't know if OTP apps are using that capability or not.

Given that TOTP (one of the more common phone OTP methods, used by Google Authenticator) uses a symmetric key, it seems unlikely it’s being stored in the Secure Enclave

It may just require an extra step. My understanding of TOTP is that it's the key data (typically a string represented by a QR code) and a time offset that is used to generate the OTP. If the only thing stored on disk is the code encrypted by the secure enclave's key, and the only way the decrypted code is in memory at runtime is if it's decrypted by the secure enclave's key, then that still offers protection against some attack vectors.

You (as an attacker) could then recover the key if you had full control of the OS and could trick the user into authenticating so the secure enclave decrypts the key, but would presumably have more trouble if you (as as attacker) simply stole the device.

You as an attacker would arguably have just as much trouble simply unlocking the device, you'd be left with the same amount of protection approximately. As long as you have disk encryption, the security margin would be about the same. A marginal improvement at best.

Yes, that's great for asymmetric stuff, but we're talking about TOTP, which uses a fixed symmetric key and a hashing algorithm. Unless you can run arbitrary code on the secure element, like you can with Intel and Qualcomm stuff it can't be done and even if it can be, it'd be a significant effort investment for what's probably a negligible secure it gain in practice. Still, I'd be pretty impressed if any apps did so.

Sadly, the Secure Enclave doesn't support HMAC-SHA-1 or importing keys [1] so it's not compatible with the industry standard TOTP 2fa mechanism.

[1] https://developer.apple.com/documentation/security/certifica...

I think we can do a lot better than the industry standard TOTP 2fa system anyway. TOTP involves sending plaintext private keys around during setup.

Fortunately, we have WebAuthn now. Hopefully Apple will jump on board soon.

>AFAIK that means it'll take more than a jailbreak to get to them, although I don't know if OTP apps are using that capability or not.

sure, you wouldn't be able to extract the keys, but what's preventing you from generating thousands of codes and extracting those instead? since they're time based, you could easily generate lots of them for a long time into the future (eg. 10 per day for the next 5 years). that should afford you plenty of opportunities to do a login attempt.

This can't be used directly for generating OTP tokens (see the other comments), but what would stop you with a normal key on the secure enclave is that you can require the enclave itself requires a higher level of authentication (facial scan match, fingerprint scan) to perform those key operations.

Duo recently added a feature (haven’t tested it yet) that allows you to transfer to another phone.

Quote from email:

In late August we will release an updated version of the Duo Mobile app that includes a new feature called Duo Restore. This functionality enables Android and iOS Duo Mobile users to recover their Duo-protected accounts when they get a new device.

Duo Restore is an opt-in feature that can be enabled or disabled by Duo Administrators in the Duo Admin Panel. It is not enabled by default.

Microsoft added this feature also recently https://docs.microsoft.com/en-us/azure/multi-factor-authenti...

>was quite a hassle to reset 2FA on all the websites after my phone was replaced in warranty repair

Next time print out all the QR codes and save them in a secure place. Now you can easily add them to a new device, although you need to be more careful to make sure they're fully removed from an old device before you get rid of it.

Google Authenticator is not a password storage app. It produces time-based hashes that expire every 60 seconds.

https://en.wikipedia.org/wiki/Time-based_One-time_Password_a...

OP never claimed that it was. They were discussing the second factor in two-factor authentication workflows. Google Authenticator is exactly that, as you pointed out.

Google authenticator generates those hashes from a plaintext key stored on device in a SQLite database. If you can read /data, then you can generate any hashes that Google Authenticator can.

Another neat solution: https://krypt.co/

Or if you have a Touch Bar MacBook: https://github.com/ntrippar/sekey

It is neat, but only for SSH. Plus, they're a new company I never heard of. Why would I trust them with my SSH keys?

Iirc their clients are all opensource, go audit the source code and build your own binaries.

I've been playing with this, and it's mostly good. It solves the key forwarding problem in nested Linux VMs (-A forwarding is kind of bad).

I do find it a bit silly that they don't support any iOS or android ssh clients, so they only way to authenticate ssh from an iphone is to connect to a VM first where the linux client is installed.

Yes, AgentForwarding is a bad idea... but thanks to ProxyCommand (and now the simpler) ProxyJump, I haven't needed to use it in years.

For the purposes of 2FA, your physical machine typically doesn't count as 'something you have' and your phone is really no different.

Why not? The iPhone is a personal computer (PC) after all, ironic as it may sound.

Your iPhone is a second factor to all devices except itself.

Regardless of what screen you are authenticating on, a key stored on the iPhone secure element can always be considered to be a factor in the authentication process.

If are logging into a site on your mobile device, and part of the authentication verifies your password and another part verifies that you are in fact on your mobile (e.g. verifying a signature of a private key stored on the device) I would still call that multi-factor authentication.

Optionally, there may be a user prompt on the device before allowing the signature.

Optionally, the user prompt could also require a local biometric authentication (3rd factor).

Or there could be no prompt at all — just a automatic handshake proving it is the same device being used that was originally enrolled.

In any case you are constraining the authentication process to only work with access to a specific private key, hence a second factor.

If I install a TOTP generator on a machine and setup 2FA on a 3rd party service, and I then later login with a password and a 6 digit TOTP code, that is definitely 2FA.

You can argue my TOTP shared secret may or may not be secure enough from malware. But it’s definitely 2FA and it successfully protects against the attack vectors that adding a “something you have” factor is designed to protect against. Better than SMS codes, for sure.

Could the TOTP shared secret be stolen if it’s kept in a file on my desktop? Of course! But that fundamentally changes the attack vector from the typical password spraying attack because now an attacker needs to directly target me and compromise my machine.

If the TOTP shared secret is in the iPhone secure element and protected by the iOS sandbox, no consumer application could reasonably ask for anything better than that. That’s $1B of security R&D on your side.

Another way to think about it is that on-device TOTP is “something you have” just like a saved password is something you have.

2FA protects against "password spraying" but that is not really the scariest threat model.

The scariest threat model is phishing, and the disadvantage of a TOTP app on your phone is that you type in the one-time code by hand. Anything you type in by hand can be phished.

The advantage of a token for 2FA is that you don't type it in. It takes human judgment out of the equation. Using NFC to supply the one-time code on an iPhone preserves that advantage.

Now, you might not think a phishing threat model is relevant to you, and that's fine. My point is simply that there is a difference between a 2FA code you type in, and a 2FA code that is supplied directly from hardware.

> The scariest threat model is phishing, and the disadvantage of a TOTP app on your phone is that you type in the one-time code by hand. Anything you type in by hand can be phished.

I can be fooled into reading a 6-digit PIN to Evil Mallory, a MITM attack.

I can be fooled into tapping my NFC auth token on Mallory's Evil Website, and the auth handshake would fail. Or not. It depends on the protocol, I suppose.

Is that what you mean?

I would posit that set of people able to be phished and the set of people willing & able to use a Yubikey are disjoint, or nearly indistinguishably so.

I'm not sure which of these is more scariest. It also depends on the user, or their past choices. E.g. I reused passwords before I had a password manager else I couldn't remember all of them.

> the disadvantage of a TOTP app on your phone is that you type in the one-time code by hand

The main disadvantage is the cost of time.

Another disadvantage is that the code can be read by anyone around you. With something physical you got more control over where you keep it, though that also has its disadvantages.

The only issue with this sort of setup is when you lose your phone and need to set up a new device. Or if you for some reason need to authenticate to a non-personal device. Smart cards have traditionally been used in this way but they haven't really been updated for the mobile world.

I could see using a yubikey stored securely in your house for just this reason and relying on the secure element in your phone for everything else. If course if you have two phones, or a computer with a secure element (like the new MacBook Pro) you could just use your other device to authenticate.

>I trust the secure element on the iPhone a lot more than I trust the hardware on the Yubikey.

Why?

I don't know about the OP, but for me the reason is that it's made by a company with a much bigger profile than yubico

This means that it's under much higher scrutiny by the public. Due to that big profile I also expect security issues to be fixed quickly as Apple has much more reputation (and money) to lose than Yubico.

Finding exploits in the iPhone's secure element gains you much more fame than finding exploits in the Yubikey.

And finally, Apple has come out very publicly against aiding law enforcement and has a much bigger war chest to fight requests by law enforcement.

Yubico has neither.

But an Yubikey is a passive and isolated device: it doesn't turn itself on, it doesn't run any apps, it doesn't connect to the internet. And if it gets compromised (stolen or exploited), it's cheap enough to throw it away and to replace it with a new and improved version without any hassle.

Stealing a Yubikey gives you immediate access to the 2nd factor, and I might not notice right away.

Stealing my iPhone gives you almost zero chance of accessing the second factor, I would notice a lot quicker, and I could revoke access (remote wipe) with a single click versus having to re-enroll a new 2FA at every single site individually.

You can password protect the Yubikey. That's how mine is setup. Adds an extra step, but I don't worry about losing it.

In my eyes, the Yubikey is a bespoke toy compared to the latest-gen iPhone Secure Element.

Apple just has a lot more riding on their chip, and since they first introduced a secure element back in 2014 have spent perhaps 2 orders of magnitude more dollars on security R&D than Yubico ($4mm angel round in 2007, $30mm raised in 2017)

Apple’s secure element is in, what, more than a billion devices, and powers how many billions in Apple Pay? Yubikey by comparison ships devices that mostly nerds pile in their sock drawer with those old USB sticks they don’t use anymore.

But are there fundamental reasons why yubikey isn’t good? The amount of money spent doesn’t mean yubikey isn’t good, and they’re trying to accomplish different things (yubikey doesn’t have an OS running Facebook on it that could be used to attack itself, nor does it try to authenticate its secrets beyond a button press).

Note Google uses Yubikey to authenticate it’s employees into their laptops — hardly just nerds piling in their sock drawer.

You're thinking about authenticating your desktop, but what about authenticating the phone?

The phone itself has access to a bunch of sensitive information, and is probably much more likely to get stolen or go in for repair. Perhaps the yubikey can serve as "something I have" to supplement the iphone's pin code.

Your phone that is visible and accessible to every WiFi network is not what I would consider a secure device.

A small smart dongle on the other hand, an island unto itself, I do consider more secure.

Does the iPhone's secure element implement smart card functionality? Does it allow generating and storing PGP keys in secure tamper-resistant memory?

Yubikey OTP is much weaker than a good challenge-response protocol like U2F. I assume that Yubico is supporting OTP because iOS only exposes NDEF data, and NDEF is effectively a one-way protocol.

Allowing two way communication would permit innovation in connecting devices that are not subject to Apple's direct control.

Yeah, it's so annoying having to buy Apple brand Wi-Fi routers and Apple brand Bluetooth headphones.

Wait, your non-Apple bluetooth speakerphone allow you to speak, not only listen?!

I kinda hope they'll make a newer version of the Yubikey that supports NFC and PGP keys bigger than 2048 bits.

Agreed on NFC but they support 4096 bit RSA in the current generation hardware:

https://www.yubico.com/product/yubikey-4-series/#tab-specs

It suffers the usual PGP-world usability problems so I ended up not using it very much but it was definitely working and takes noticeably longer to generate the key than a 2048-bit key does.

I wonder if there is a method to detect NFC at a greater distance than you can read it - could be used to 'find any yubikeys hidden in office desks'

I’d like to see Safari support... does anyone know if it’ll have it (perhaps thru a sharing extension?)

Ok, this is dumb. Real dumb. I would trust (the leaked) secure enclave OS than Yubico's offerings. And the Secure Enclave is already built in, versus this 3rd party hardware.

Also, using something like andOTP is perfectly fine to run, which is also a U2F TOTP solution. It integrates perfectly with LinOTP, Google Authenticatior, or other 2fa solutions.

In essence, if you're using Linux anywhere, 2fa is free to implement, free to manage serverside, and just works. There's no reason for Yubi-anything.

Also, within the next few weeks/months, NIST will be stating that phone calls, Texts, and emails are no longer an acceptable 2fa for secure stuff.

> Also, using something like andOTP is perfectly fine to run, which is also a U2F TOTP solution. It integrates perfectly with LinOTP, Google Authenticatior, or other 2fa solutions.

It also has a massive attack surface since you need to secure an Android device. The big win for a dedicated hardware token is that there's so little to attack, along with lesser things like not running out of battery at inconvenient moments.

Reply on news.ycombinator.com