> 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.
Yes? 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.
Imagine 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.
>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.
Should 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.
Well 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:// 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.
You 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
This 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?
extreme handwaving hand-me-down 6 year old iBook(?) circa 2005 => wow software can be beautiful => hacking on AppleScript => hacking on iPhone OS 1.1.4 decompiled SDK => iPhone 2 with the App Store(tm) => shit, I can make money off this? => dropout => startup => sold it => saw what an acquisition looks like => by the grace of god herself, somehow made it through Google interviews.
(happy to detail more, like everyone, I love talking about myself :P but figured I'd start with the TL;DR, i.e. the App Store + subsequent boom happened at such a time that made it seems reasonable, years later, to dropout, and having 0 responsibility outside restaurant shifts gave me a fulcrum)
> 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?
Yes, 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.
Might 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.
No, 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)"
Do 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.
I 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.
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.