I don't mean to be the devil's advocate, but I'm pretty sure that disabling Face ID when replacing the camera with a generic one is primarily a measure to thwart potential hardware-based attacks...
There are simple ways to allow hardware changes without losing security. One straightforward idea: Once the phone is unlocked (e.g. by pin code) allow the user to authorize the new hardware.
This is effectively what Apple does already. The usual difficulties with asking users to make security choices don't really apply here: Physical changes to the hardware are requires, so security fatigue isn't as big a deal. Maybe you get some protection from wrench attacks by not having the authority to pair new internal hardware, but that seems like a very specialized use case...
It's sad that that's not up to the user. maybe paternalistic comprising is what Apple's customers really want, but I'm convinced it's bad for the user and bad for society in the long run.
I think it's a natural consequence of miniaturization and other technology advancements. With today's technology you can hide a hardware backdoor inside a counterfeit version of a chip and the only way it could be detected would be to de-cap the chip and examine it under an electron microscope.
Hard disagree — there are plenty of things where human brains will take a shortcut no matter how smart the individual is. Security is especially a category where humans will fault, no matter what.
I'm not convinced that they need to. What threat model are you considering? In this case, the privilege that the user is granting the new hardware is the authority to unlock the phone.
Since the phone has to already be unlocked for this privilege to be granted, it can't be used to bypass authentication.
The hardware is already installed by this point, so if it's 'spying' it can do that. The user's choice has no impact on the hardware's ability to record and/or deliver information.
At best, the replacement hardware would be able to unlock the phone for the attacker at some later time. However, the cost of getting this customized unlocking device into the phone seems high given that the attacker needs physical access to the device to embed the hardware in the first place, and then again at a later time to get into the device.
For example, my dad used to use Androids. Without fail, he would get malware on them, he simply could not resist bypassing the security prompt to click on something he wanted to click on. Or maybe he does not understand English, or the concept of malware enough to properly heed the security warning pop up.
With iPhone, it’s not possible, so there is no worry, and no malware. Same with the hardware changes. People like my dad, or my wife, or even me who have very little interest in technology simply want to trust their device. And this device is literally the key to their life, their financials, their personal data.
All I know is my life has been made much easier by slinging Apple devices at people in my family that they simply do not have a way to mess up.
The topic seems have changed to sideloading here, for that they can bury the setting somewhere or require connecting a PC over USB (but hopefully without involving Apple’s servers or requiring a Mac) to enable it if that’s really their motivation
But their main motivation is likely control and profit more than safety
I don't think this is quite that simple, because one user's authority could potential trump everyone else's in a company or group, once a vulnerable device infiltrates the system. Having trusted authorities works well when everyone has to rely on the security of the device. Once you can bypass that authority you effectively have a cheap MITM attack.
You are describing a different class of attacks. If the company owns the device, they should be free to (try to) lock it down all they want. OP is about Apple locking down devices that someone else ostensibly owns.
Why? If this is really an attack-vector a company considers, it could streamline hardware-repairs into their internal processes.
If the device is enrolled in a corporate MDM, the confirmation of HW-changes could be delegated from the user to the admin, with the device working in "degraded" mode (i.e. no FaceID) until the admin approves the Repair.
Even more, large companies could contract with specific repair-companies to authorize them for their company devices and their repairs are synced into the corporate processes.
This would create a paradigm-shift in that market as repair-volume suddenly becomes more predictable ("I'll repair phones when they come in" --> "my company is the exclusive repair-center for a footprint of 10k corporate devices"), repair-companies will commit to certain performance, then drive smaller-volume contracts and individual repairs to offset the cost of such guaranteed turnaround-times, and so on...
Insisting on approved camera avoids making it easier for bad actors to stealthily capture's a victim's biometrics and then use a third party "camera" to replay that information and unlock the victim's phone without them being present.
Arguably if you anticipate someone targeting you who is capable of attacks this sophisticated, you are very far outside the norm and should probably have an entirely different relationship with your devices than most people.
"Couldn't just", might be, probably not. Face-ID is a pretty complex and very highly integrated system. The dot pattern can't be changed, because each dot in the pattern (~100 dots or so) is actually a VCSEL laser. The large constellation (>30k dots) is created by a diffractive beamsplitter. The sensor is probably custom, so I'd wager the CMOS IR sensor is actually physically the thing that's paired to the Secure Enclave. I doubt there's just an unencrypted MIPI link running from some random 1/6" OmniVision sensor to the CPU.
Because the camera represents the analog hole. If you can replace the camera, you can hook the phone up to a computer and feed it pictures of faces instead, until the phone unlocks.
If you find that attack vector so scary, I'm sorry to inform you that it is already possible to prop up an iphone against a pizza box and have it stare at a screen showing a feed of pictures.
Admittedly you might have to put the iphone on its side so you can get the charging cable in there, which means you might have to figure out how to rotate the pictures too.
> I'm pretty sure that disabling Face ID when replacing the camera with a generic one is primarily a measure to thwart potential hardware-based attacks.
I'm pretty sure it's not. The number of people which would be targeted by this is too small to justify the additional costs. The vast majority of people which would be targeted by this are pretty much screwed anyhow since the adversary already has physical access. It's much more likely a brand protection scheme to ensure there are fewer items out there with sub-par hardware.
If apple thinks it's an issue make it clear before letting me activate it that they no longer guarantee any safety (which they don't anyway, that's the joke, you already signed that way in the user agreement).
My ISP will provide me with a router and full support. If I change the settings or flash firmware they will no longer support it. However, if I let them restore the factory firmware and config they will again support it.
It's not hard and apple's motive here is clearly maximize stock value, nothing else.
I'm not sure I buy it. The sensor itself in the camera doesn't do mutual authentication with other components. If you have enough interest / access to mess with the hardware permanently, you'll be able to feed whatever image you want to the original camera chip.
The number of people who could be targets of an attack of such sophistication is so vanishingly small, that it seems irrelevant compared to the number of people who need repair work on their phones.
This is effectively what Apple does already. The usual difficulties with asking users to make security choices don't really apply here: Physical changes to the hardware are requires, so security fatigue isn't as big a deal. Maybe you get some protection from wrench attacks by not having the authority to pair new internal hardware, but that seems like a very specialized use case...