News for hackers. Stuff that matters.
Re:Apple, Google and Microsoft Commit to Expanded Support fo... by throwaway52022 on Thursday May 05, 2022 @12:40PM (#31275560)
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)

Re:Apple, Google and Microsoft Commit to Expanded Support fo... by mjevans on Thursday May 05, 2022 @02:51PM (#31277109)
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.
Re:Apple, Google and Microsoft Commit to Expanded Support fo... by lxgr on Thursday May 05, 2022 @03:10PM (#31277302)
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.

Re:Apple, Google and Microsoft Commit to Expanded Support fo... by toastal on Thursday May 05, 2022 @11:39PM (#31281048)
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.
Re:Apple, Google and Microsoft Commit to Expanded Support fo... by DCKing on Thursday May 05, 2022 @08:41PM (#31279880)
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.

Re:Apple, Google and Microsoft Commit to Expanded Support fo... by judge2020 on Thursday May 05, 2022 @09:01PM (#31280030)
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.
Re:Apple, Google and Microsoft Commit to Expanded Support fo... by astrange on Thursday May 05, 2022 @09:24PM (#31280172)
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.

Re:Apple, Google and Microsoft Commit to Expanded Support fo... by astrange on Thursday May 05, 2022 @09:26PM (#31280183)
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.

Re:Apple, Google and Microsoft Commit to Expanded Support fo... by tpush on Thursday May 05, 2022 @05:12PM (#31278470)
The baseband CPU doesn't have full access on any decent phone.
Re:Apple, Google and Microsoft Commit to Expanded Support fo... by SXX on Friday May 06, 2022 @01:32AM (#31281652)
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.
Re:Apple, Google and Microsoft Commit to Expanded Support fo... by t-3 on Thursday May 05, 2022 @07:20PM (#31279435)
Got a list of decent phones?
Re:Apple, Google and Microsoft Commit to Expanded Support fo... by tpush on Thursday May 05, 2022 @08:15PM (#31279710)
The baseband on an iPhone is connected via USB and has no DMA, for example. I believe Google's Pixel phones are similar.
Re:Apple, Google and Microsoft Commit to Expanded Support fo... by judge2020 on Thursday May 05, 2022 @09:11PM (#31280083)
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...