Comment by throwaway52022 | Hacker News Reader

Comment by throwaway52022 | Hacker News Reader

Parent Full thread

For web apps/services, the browser needs to be involved here too, right? (And maybe the OS?) How can I tell Chrome on my desktop to use my "software token" instead of Chrome looking for a hardware token over USB or finding it via NFC, so the remote service can ultimately interact with my (virtual) token?

(I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key)

EDIT: My ideal setup, I think, is an app on my phone that I can use as my token - somehow signaling to my desktop/laptop that it's nearby and can be used as a token and ideally popping up a notice on the phone lock screen when there's an authentication request so I can quickly get to it. Then in my app, I'm free to export and backup my keys for all of the sites I'm enrolled with as I see fit. I know, I know, maybe being able to export the keys makes the setup less secure, but I will trust myself not to accidentally give the backup to a phishing site. (And I do worry that I'll accidentally get phished using a TOTP app, so I'd like to switch to FIDO, but I don't want the pain of multiple keys)

I do NOT want to use my phone. It cannot be considered to be a secure device given the 'network' baseband control chipset will never be owned by the phone's buyer and has full access to the device.

Storing your keys in secure hardware on a phone is almost certainly more secure than storing a key in software on your desktop hard drive.

If you don't trust your hardware, it's almost always game over. Desktops have devices running dubious firwmare as well, but at least with a hardware key store, the window of compromise ends at the time you update – a stolen key stays stolen forever.

For me the biggest anti-phone argument is that they break and that is very common. They also run out of power. Hardware keys offload this to something that can go through the washing machine or ride in monsoon rains on my motorbike's keychain.

This is an urban legend. It ticks all the boxes of people who are inclined to be paranoid about these sort of things (I realize saying that may come across as a value judgment: it isn't), so it remains a popular meme. But the "baseband controls the main phone" is a meme that was maybe true for mid 00s dumbphones but not modern smartphones.

That's not to say that you should trust modern smartphones. That's up to you. It's just that in whatever "trust" means to you, the baseband urban legend shouldn't come into the equation.

While I can't find the reference, I remember reading about how Apple set up their connection to the modem in a very particular way to where it has its own co-processor for any code it needs to run, and the bridge between it and the main SOC is just IO for rpc and network access.

Well, the baseband always was its own processor - that's why it's a separate thing called a baseband. What you're thinking of is an IOMMU, it's like a firewall that prevents coprocessors from reading all of RAM.

If there are vulnerabilities on the AP (main processor) then you can hack it from the baseband, but also from the bluetooth or WiFi chips.

Your phone is a whole lot more secure than your PC. It has to be, because you carry it around with you all day and it's easier to steal, so it has to be resistant to a lot more things.

Caveat emptor on cheaper/older phones or ones you enabled developer modes on.

The baseband CPU doesn't have full access on any decent phone.

How do you know for sure it's isolated? Every phone has tons of blobs running in background and hardware itself is very much blackbox.

Got a list of decent phones?

The baseband on an iPhone is connected via USB and has no DMA, for example. I believe Google's Pixel phones are similar.

https://news.ycombinator.com/item?id=31275560

Yes, either the Browser or the OS will need to be involved. For example, for Webauthn on Chrome on Windows: chrome receives the request, then it calls the Windows Hello APIs. Then, that Windows Hello API shows a popup to read a physical security key or authenticate a virtual security key via face/PIN (this is protected by a TPM, but it's "virtual" since Windows generates it via the TPM but stores it encrypted on-disk).

To support a syncing fido keyvault, Chrome could very well redirect the calls to its own popup for choosing to 'use Chrome', or 'use another key', which would then call the Windows Hello API. In fact, Chrome already supports this[0], with 'Add a new Android phone' is simply how they're presenting Webauthn over BLE, and it works with iOS when passkeys are enabled in the iOS developer menu[1].

0: https://i.judge.sh/Qq93C/v_GG5R7LyM.png

1: https://developer.apple.com/documentation/authenticationserv...

Reply on news.ycombinator.com