I'm quite surprised that they use a secure exclave to control the physical camera LED - this is absolutely massive overengineering to do something very simple.
A tiny bit of hardwired dedicated logic integrated into the camera module would be more than adequate to do this - just gating of either the digital I/O or the power to the camera, and a pulse-stretcher so the LED goes on for at least a few seconds each time to prevent an attack by rapidly flicking the camera logic on and off.
A similar circuit for the microphone with a different-coloured physical LED - not just a software-controlled dot on the screen - would be a good idea too.
It gets complicated. “The camera” is a bunch of parts. You’d probably want to key off of the CMOS sensor power, but that has several power levels for standby, sleep, idle. So your hardware circuit would likely to know current, not just voltage. Or maybe go upstream and parse the I2C (or whatever) messages signaling power mode changes?
And then your LED driver would need to know screen brightness (or connect to the ambient light sensor) because you want to be bright enough to see in direct sunlight, but that level of brightness would be unpleasant (and maybe screw up legit camera use) in low light.
So if you believe your SK is secure, you can do a better job more simply by using it. And if you don’t think SK is secure, all bets are off anyway.
All of which is fantastic, until you can't trust Apple because they are under a secret obligation to disable that feature. Non-programmable hardware gating the I/O lines or power isn't hackable in the same way.
You have to wonder if it is over engineering, or a resolution for something they've discovered from shipping so many phones. I wouldn't think of the camera as a security vector, but maybe Apple thinks it is?
The camera and mic are generally regarded as security sensitive because of the possibility that they can be used to surveil. That’s why it’s a selling point to have physical hardware or hardware-bound controls or indicators that can’t be bypassed by the OS.
I think it’s not just the camera LED, but the indicators that appear on screen, like the amber, green, or blue dots that appear in the menu bar when the microphone, camera, or screen recording are accessed by apps.
> just gating of either the digital I/O or the power to the camera, and a pulse-stretcher so the LED goes on for at least a few seconds each time to prevent an attack by rapidly flicking the camera logic on and off.
They'd be unable to roll out the feature to older iPhones if they did this.
I guess for newer iPhones this is not as big of a deal since they have a big-ass notch anyway, however Apple also has a large customer base that only buys their older products (like me), and saying that their older products have worse security than their newer ones is probably not the kind of message they want to send, even if it might potentially get them some new sales.
What if they want to add Face ID to the Mac but have the camera light not illuminate for that internal function, since that can also be developed securely so that nothing in user space can access the camera during that query.
It’s (for example) similar to the Kinect. It projects a pattern of structured light in IR then looks at that with an IR camera to be able to determine depth.
A tiny bit of hardwired dedicated logic integrated into the camera module would be more than adequate to do this - just gating of either the digital I/O or the power to the camera, and a pulse-stretcher so the LED goes on for at least a few seconds each time to prevent an attack by rapidly flicking the camera logic on and off.
A similar circuit for the microphone with a different-coloured physical LED - not just a software-controlled dot on the screen - would be a good idea too.