Live data from Hacker News

iMessage Key Verification

support.apple.com

121–127 of 127 posts

Re: iMessage Key Verification

#121

Earlier quoted context omitted.

Ow. Okay, I take it back, unless there's something I'm missing then Matrix's system is better than this. I'm sorry, I just can not imagine asking a non-technical person to copy and paste that into a messenger and then needing to help them debug which letter they left off. It's hard enough to get them to validate "I see a cat, a dog, a horse, a pizza, and a basketball." I guess I'll wait and see what happens with it,…

Is it any different from copying an url? That said it might be formatted as an url like totp url.

In theory no, but in practice, wow do people seem to struggle with keys. Matrix's current system went emoji only because even numbers seem to be too much for people. And arguably, even emoji are too much for people.

There's larger UX problems surrounding when/where to copy and what the caveats are, but even ignoring them, people do seem to struggle with copy paste, especially cross-device stuff. I'm not sure what the solution is.

Re: iMessage Key Verification

#122
post #87

Earlier quoted context omitted.

Ow. Okay, I take it back, unless there's something I'm missing then Matrix's system is better than this. I'm sorry, I just can not imagine asking a non-technical person to copy and paste that into a messenger and then needing to help them debug which letter they left off. It's hard enough to get them to validate "I see a cat, a dog, a horse, a pizza, and a basketball." I guess I'll wait and see what happens with it,…

They both suck, TOFU is bad. Apple should apply their central pki to certify that contact with their icloud id. TOFU is a good idea when you don't want a central party arbitraring identities like with federated matrix. Makes little sense with apple.

You know, that is a good point. Far be it from me to encourage Apple to do more attestation -- to be clear, UX problems aside I don't want a centralized identity management service.

However, from Apple's perspective, this does kind of feel like the worst of both worlds. People have to update their devices to the most recent iOS version, apparently being signed in on an old device just turns off verification, apparently it's not even per-device?

So if that's the case, Apple has all of the downsides of attestation right now. Why also have the downsides for keys and in-band verification as well. It does seem like it would be simpler for them to try and have this be something that's tied into iCloud that gets set up only by the person who wants to be verified. Again, I'm not saying I want that, I don't want Apple arbitrating identities, but... why wouldn't they? Why have a system with both downsides?

I'm sure there are caveats I'm not thinking of, but it does seem like they could probably do this in a less federated/decentralized manner?

Re: iMessage Key Verification

#123
post #95

Earlier quoted context omitted.

Ow. Okay, I take it back, unless there's something I'm missing then Matrix's system is better than this. I'm sorry, I just can not imagine asking a non-technical person to copy and paste that into a messenger and then needing to help them debug which letter they left off. It's hard enough to get them to validate "I see a cat, a dog, a horse, a pizza, and a basketball." I guess I'll wait and see what happens with it,…

To be clear, that code is only for offline verification. For live verification (akin to Matrix's emojis) Apple has you compare an 8 digit code.

Okay, fair, that's a lot better then. Still not ideal, but... yeah, my guess would be then that maybe people mostly do live verification.

I don't know, we'll see what happens. Maybe I'll be wrong and the system will take off.

Re: iMessage Key Verification

#124

Why does Apple couple iMessage with rest of iCloud? Why is iCloud and iCloud Keychain being on a requirement for secure iMessage to function? That seems like a poor design choice to me. For someone who cares about their communication security deeply enough to do contact public key verification, they would likely want to turn off iCloud syncing iMessage across multiple devices. They are likely to not have same iCloud…

iMessage Key Verification does not require that you use 'iCloud for iMessage' (aka iCloud message syncing), it just requires that you're signed into iCloud and have iCloud Keychain enabled. Your critique is still valid but I think it's important to note that you're not required to store all your actual encrypted iMessage content in iCloud.

Re: iMessage Key Verification

#125
post #96

Earlier quoted context omitted.

According to https://security.apple.com/blog/imessage-contact-key-verific... , the actual verified hash of the account key is stored in an end-to-end encrypted CloudKit container and merely linked to from the contact card.

Oh interesting, that is not at all clear based on the Contacts UI which shows it like any other field

The iOS Contact APIs shouldn't allow modifying this.

You can also try exporting the contact to a vCard .vcf file using the Share Contact button. I believe the iMessage key verification info won't be included. (But as you noted the most important thing is that it can't be modified)

Re: iMessage Key Verification

#126
post #22

Seems like Apple is tacitly acknowledging that sophisticated actors have successfully been man-in-the-middling iMessage users. I wonder if they have clear evidence of that since I haven’t seen any coverage on this.

The attack is that anyone can make an iMessage account and pretend to be your friend ("new phone who this"); this feature is how you prevent that.

Agreed with the sibling comment. To quote Apple, this feature can "detect sophisticated threats against iMessage servers". Essentially it's to protect against state-sponsored attacks MITMing you. Doing that also probably requires the attackers also have access to some root CA private keys so it's a very small pool.

Re: iMessage Key Verification

#127
post #76

Earlier quoted context omitted.

Only for mass attacks. A targeted attack will encounter the risk of the attacker being exposed. Think journalists, politicians, public figures

> A targeted attack will encounter the risk of the attacker being exposed. What "risk" is there? I'm not aware of illegal spying by intelligence or law enforcement agencies having ever had any adverse consequences for them, in any country, at any point in history.

There were several instances when a person of interest suspected something's wrong with their phone and knowing they can be a target of a government surveillance they promptly submitted their devices to security companies. That's how some zero-days were uncovered by Apple.
Post reply on HN