Kevin Beaumont
Going to be interesting to see if this happens:
1) Google and Apple integrate Passkeys in a way which is recoverable for device swaps, ie keys are backed up centrally and it is required - both US companies
2) services like WhatsApp etc require all accounts to use Passkeys
3) National Security letters or the like https://en.wikipedia.org/wiki/National_security_letter
feld
Marcin Cieślak
@vpz @GossiTheDog @kravietz @PlaneSailingGames
(i)Cloud accounts have been targeted for hijack for quite a long time.
what is the point of cloud-based passkeys?
so I am going to protect myself against hijacking, say, my Github account, but my Apple account stays less protected?
But if I go ahead and buy a real hardware fido key, I can use it for all services, including Github and (probably) Apple, so why bother with the cloud-based solution?
Marcin Cieślak
@GossiTheDog @kravietz @PlaneSailingGames
got it! in short: FIDO good, passkey bad
vpz
@saper @GossiTheDog @kravietz @PlaneSailingGames What it sounds like is that how a user configures the security around passkeys is important. Using the Apple example mentioned previously, iCloud Keychain security1 is what protects passkeys, if I'm reading this stuff correctly. So a user who cares more about security than convenience is going to take extra steps to secure iCloud Keychain like using two-factor with Yubikeys. And by NOT doing that, the security of Keychain isn't that great. [1] https://support.apple.com/guide/security/icloud-keychain-security-overview-sec1c89c6f3b/1/web/1
Kevin Beaumont
@kravietz @saper @PlaneSailingGames yeah.. you might want to look at how Passkeys has been implemented compared to FIDO.
kravietz 🦇
Under FIDO, to which Google declares compliance for passkeys[^1], the private key should never leave the client device so they shouldn’t be stored on the server… but that applies to the service provider (e.g. Shopify website). Identity provider, in this case Google or Apple, of course do store private keys on their servers for backup purposes, only they declare them to be encrypted by the sync passphrase.
I guess there are two workflows here: one under normal usage scenarios, one under TAO[^2] or other “law enforcement love letter” scenarios.
Granted that identity like Google provider controls all data flows for any software keys, from storage (Android), sync passphrase entry (Android) to operating system and application updates (especially after hosted developer keys were introduced to Android[^3]), it would be naive to have any illusions that under TAO scenario they won’t retrieve that one way or another.
This shouldn’t be the case with hardware authenticators, of course, which are also allowed by Passkeys. Or at least building a side channel for private key retrieval will be much more difficult even in TAO scenario.
[^1]: https://developers.google.com/identity/passkeys
[^2]: https://en.wikipedia.org/wiki/Tailored_Access_Operations
[^3]: https://www.theregister.com/2021/07/01/android_app_bundle/
Marcin Cieślak
@PlaneSailingGames @GossiTheDog
I am no expert on #Webauthn but maybe some "pure-device-based-no-backup" attestation type could be added. But then, in turn, the relying party would need to require that and only that. Unlikely to happen.
Does this mean that relying parties might need to maintain "trusted" lists of attestation CAs in the future?
Here it would be unlikely that Google, Apple and Microsoft certificates will not be included on those lists by default.
pls help @kravietz :)
Alex White
I think he is saying that if the passkeys leave the device and are stored centrally, then the government could gain access to them and thus all your stuff
Marcin Cieślak
@GossiTheDog can you provide some context? I am not sure I get this...
feld
Marcin Cieślak
@feld @kravietz @PlaneSailingGames @GossiTheDog @vpz
ok, now I got to understand that the Keychain is an encrypted data structure stored somewhere (it could be Apple's key-value store). Reading this story I gather that a whole thing is encrypted with a symmetric wrapping key. This wrapping key can be either obtained by the syncing identity or derived from the recovery code.
So devices exchange the key exchange key among themselves during pairing? Could recovery code be seen as a #SPOF?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.