6 ms·
> moving a message over BLE to untrusted hardware and worse accepting them back into iMessage is a massive, massive change in the security boundary Is it? My
by the_mitsuhiko 2y ago
> moving a message over BLE to untrusted hardware and worse accepting them back into iMessage is a massive, massive change in the security boundary
Is it? My iPhone replicates messages to my mac from where a process can extract that data, it can capture the screen etc. I can use a mac today to set up a relay that would then send those messages to a smart watch if one would do that.
- browningstreet 2y agoSame with Phone Link on Windows.
- judofyr 2y agoYes? Imagine a bug where iMessages are leaked over Bluetooth when a user has installed an application that integrates with some watch brand. Bring this to an airport and you can steal hundreds/thousands of messages from a wide range of people. That’s widely different attack vector than targeting macOS. That said, I don’t see why Apple can’t provide toolkit/certification that will make it safe to communicate over Bluetooth. They already have it in-place for Apple Watch.
- lern_too_spel 2y agoBluetooth is encrypted.
- Avamander 2y agoShould be, but BT stacks are super crap and it's hard to truly guarantee that. Pretty sure they do not currently require the highest (actually proper) security level from everyone.
- mystified5016 2y ago[flagged]
- Avamander 2y agoDo you actually have anything conducive to say, anything specific you'd like to argue against? Encryption is optional, there are four security levels for BLE, multiple pairing methods, privacy extensions, there are so many ways to mess things up.
- refulgentis 2y agoThis whole thread is chockful of thought-terminating cliches, and I say that as someone who grew from a waiter to a developer thanks to Apple and made a lot of these arguments. I also worked on Android Wear's iOS app for working with iPhones. The major problem I see now with these excuses, that I'd like to claim wasn't an issue when I was making them circa 2015-2017, is they're cargo cult (a la Apple likes making things that just work) or boogeymen (if they did anything different, a bluetooth connection would be used, unencrypted, sending all your data into the ether). The watch has been out for 10 years. Software is software. Where there's a will, there's a way. It's very, very, very, hard to believe there's 0 way for Apple to ensure an encrypted connection. Put another way, avoiding the global observations: If it's impossible, why allow watches to be paired at all?
- Avamander 2y ago> that I'd like to claim wasn't an issue when I was making them circa 2015-2017, Well, I wouldn't say that the standards for (software) security were anywhere near as high as they are now. It makes sense that our requirements for things change. > It's very, very, very, hard to believe there's 0 way for Apple to ensure an encrypted connection. Sure there are ways, but without regulation I struggle to see why should/would Apple ever bother. Nor do I think that a forced way would be held to the same standards as the rest. > Put another way, avoiding the global observations: If it's impossible, why allow watches to be paired at all? Because they can't do much, if anything at all?
- Phrodo_00 2y ago> Because they can't do much, if anything at all? But the Apple Watch can, and a lot of the same arguments apply to it as much as any third party watch.
- Avamander 2y agoYes, but they can actually know it fulfils some security criteria of theirs. Doesn't have fundamentally broken cryptography hidden somewhere, doesn't leak its keys, all that bare minimum is really difficult to guarantee with external unknown implementations.
- nijave 2y agoGiven that Apple controls the entire hardware and software stack, can't they guarantee messages are encrypted and refuse to send them if they aren't? It seems like they're refusing unconditionally and claiming security instead of actually requiring security.
- Avamander 2y agoWell they could require a security level for starters and require only secure pairing (the fact that we even have something besides secure pairing should make a few bells ring), but that still leaves a bunch of avenues for an external vendor to fuck up their side of the implementation. It's a whole another system outside of Apple's control and some mutually agreed upon Bluetooth LE elliptic key does nothing to protect it in its entirety. It still leaves cryptographic mistakes, side-channels and all other vulnerabilities. Like, what does https:// https:// or transport encryption in general really say about the website's security to you? Not much besides transport, does it? Now we want to expose more than notification contents over Bluetooth (LE)? Are we sure? It has to be carefully designed.
- nijave 2y agoYou have to trust 3rd parties at some point. Apple can make it reasonably secure and let the user decide if 3rd party accessories are worth the potential risk but that option is never exposed. Really Apple allows HTTPS connections but the same implementation concerns apply there. The web server could publish it's private and session keys to a "status" page and leak enough to make decryption trivial I think it'd be more honest if they say "we don't want to give users options" (for better or worse) instead of claiming it's security
- rezonant 2y agoSo Apple's BT stack is crap? Because that's the one that is in control here...
- ketzo 2y agoNo, the vendor's BT stack would be responsible for broadcasting any responses back to the device -- like, in the article, "send text messages, or perform actions on notifications (like dismissing, muting, replying)"
- Dylan16807 2y agoAnd Apple's BT stack would be responsible for receiving those responses. If it rejects messages with improper encryption, the watch won't get programmed to send them.
- Avamander 2y agoMight be, but I meant the wearables' stacks. Fundamentally Apple can't ensure much more than a vaguely transport encrypted connection to such a peripheral. Apple can't (trivially) detect if there's a fatal flaw in the way the other side derives their secrets for example. They can't know if the device doesn't have a backdoor characteristic/API that gives access to the key material. They can't know if that proprietary stack can't be exploited in n+1 ways because it has been written by an underpaid intern. But if Apple gave access to everything over BLE they would be expected to. At least by most Apple users. Be it a good or a bad thing. It's a rather enormous access vector, if they'd provide feature parity(-ish) with Watch. Much more sensible would be to make such features available to apps (and by proxy, wearables) with entitlements. But even then it can be just as insecure, just by proxy.
- hnburnsy 2y agoImagine a bug where the Apple Passwords app leaks over HTTP. Bring this to an airport and you can steal hundreds/thousands of Passwords from a wide range of people. https://www.theverge.com/news/632108/apple-ios-passwords-app-bug-vulnerability-phishing-attacks https://www.theverge.com/news/632108/apple-ios-passwords-app... >The lack of encryption meant an attacker on the same Wi-Fi network as you, like at an airport or coffee shop, could redirect your browser to a look-a-like phishing site to steal your login credentials.
- eddieroger 2y agoI agree with you, but your iPhone forwards SMS messages, but not iMessages, and there's a trust relationship between the devices through Keychain. Still, doing it blindly over BLE is a scary proposition.
- littlecosmic 2y agoWhat is ‘blind’ about sending it to a paired device whitelisted by the user?
- greggsy 2y agoYour phone and Mac have strong trust at the OS, hardware, and manufacturing level.
- saagarjha 2y agoOk but that strong trust lets them do exactly what was mentioned above.