I always wondered why FaceTime Audio has almost zero call establishment time on iOS, as opposed to WhatsApp or FB Messenger where you need to wait half a second before the audio feed kicks in after answering. Guess this is the reason!
This sound horrifying. If I use a hacked/modified FaceTime client, does this mean I'll be able to hear and see the other end before they pick up, even after the fix?
I wouldn't call it E2E encryption if only one party in the world has the key. E2E generally means both sides have the encryption key. But lolc points out the real problem with that scheme.
I think it is fair to say all applications must be written to assume the source code is opensource / can be modified / recompiled. A recompiled app should, in theory, only sacrifice the security of the person who did it, not the remote.
If FaceTime is implemented the way the parent comment mentions (which it very well may not) I don't see why you could make a client that performs a proper key exchange to set up an end-to-end call and simply pretend grab the video instead of hiding it behind the "dailing" screen?
"The initial FaceTime connection is made through Apple server infrastructure that relays data packets between the users’ registered devices. Using APNs notifications and Session Traversal Utilities for NAT (STUN) messages over the relayed connection, the devices verify their identity certificates and establish a shared secret for each session. The shared secret is used to derive session keys for media channels streamed via the Secure Real-time Transport Protocol (SRTP). SRTP packets are encrypted using AES-256 in Counter Mode and HMAC-SHA1. Subsequent to the initial connection and security setup, FaceTime uses STUN and Internet Connectivity Establishment (ICE) to establish a peer-to-peer connection between devices, if possible."
I'm not doubting whether FaceTime is end-to-end encrypted, I'm not sure whether FaceTime sends data before the call is accepted for speculation reasons.
Yeah, if you have a hacked iMessage client you probably could retire from bug bounties. At any rate the bug in question would pale in comparison to a rogue iMessage client.
Modified clients are definitely possible - review the recent Project Zero research into webRTC vulnerabilities, which included a look at FaceTime and discovered several exploitable bugs
> Similar to how Nextels cellular "push to talk" fake walkie talkies worked.
Not really. The reason the PTT was virtually instant connect has nothing to do with optimization tricks, but rather is a purpose built design of the network tech it was using.
Nextel PTT didn't go over a normal cellular network, it went over something called iDEN[0]. iDEN provides a trunked radio service[1] which has a similarish feature to a conventional two-way radio. Sprint acquired Nextel and as iDEN wasn't as relevant anymore with the advances in cellular networks (despite those who actually used the PTT functionality), in 2013 Sprint shutdown the network to use it for additional LTE bandwidth in the 800mhz band[2].
No, PTT would send audio from the caller without the receiver accepting anything, but it wouldn't send anything from the receiver without action on the receiver end.
It was obnoxious at times, but very different than the kind of privacy invasion that the receiver's sending data without active involvement is.
