Can someone explain the relationship between a remote deactivation feature like the one in iOS and a hardware backdoor? In other words, is a mandate to do this a de facto attack on software freedoms (by mandating the phone run unmodifiable code)? Or is there a middle path where the device could be significantly degraded remotely but still allow for the owner to be root?
It will soon be mandatory that phones offer this feature. There’s no mandate to enable it or keep it enabled. If you want to seriously degrade the security of your phone, that is still an option.
Or maybe Steve Jobs was right - people really don’t want larger phones?
If enough people use the feature, then you get herd immunity from theft.
There’s no link for “you can check your Activation Lock Status here.”
Correct link is here:
Doesn’t appear to work from mobile browsers, FWIW.
If you want to seriously degrade the security of your phone, that is still an option.
I honestly thought you were agreeing with me. Here’s my point of view: Having an institution able to remotely execute software – perhaps a trusted institution, but clearly one you don’t control – is kind of the definition of insecure.
For a real world example, look at the shutdown of ISPs in Cairo during the Arab spring. Then look at the “stingray” cell interception devices in use in the United States. Once this kind of always-on backdoor exists, it’s entirely feasible to send a command to phones within a certain geofence to go dark for a few hours. Long enough to swap out a government, or keep one in place, or just clear out an annoying protest without it getting to Twitter in realtime.
As for “deactivation”, depending on how it’s implemented, that may not be really possible. Turning “off” the feature may a request to the host institution to not use it, not a technical limit. Institutions can be abused.
Here, FTFY…
Cell phones rely on cell phone towers. Even if all phones could not be remotely bricked, it is routine to knock out communications conventionally, and stifle protest that way.
Which makes less conventional methods of communication (meshed networks using close-range methods, for example) an interesting avenue of exploration for resistance to institutional control of communication. I am having fun speculating about a firmware that, in the event of remote bricking, activates a slim OS with zero normal hard drive access, but with WiFi/other close-range comms, mic/camera, separated HDD partition & a mesh protocol. When activated, device attempts to mesh with nearby devices. If mesh network succeeds, participants can message each other and mic/camera inputs are automatically distributed to partitions of nearby devices. If device has, in fact, just been bricked because it’s stolen, have fun with your downgraded walky-talky.
Maintain the benefits of remote bricking (ability for consumers to protect their data stored on stolen devices/reduce value of stolen devices) while allowing emergency communications in event of authoritarian killswitch activation.
And that’s where the major misunderstanding occurs. That’s not how activation locks work at all. They aren’t set up remotely. Here’s what actually happens. in the case of iOS:
- You sign into iCloud on the iPhone using the username and password you chose.
- You enable Find My iPhone with the username and password you chose.
- Locally, on the device, this creates a token that can only be cleared with the username and password you chose.
- The device is erased/wiped.
- Upon boot, locally, iOS checks to see if the token exists.
- If the token exists, locally, the username and password you chose in step 1 must be entered.
At no point can anyone remotely change the username and password used for the local token. If the username and password for the Apple ID used in step one is changed outside of the iPhone, an updated token will not be created until the new username/password combination is entered locally, on the device. Otherwise, the old username/password will be required.
You cannot remotely set up an activation lock. You cannot remotely trigger an activation lock. The only thing you can do remotely is a remote wipe, which requires step 2 to have occurred and which will trigger step 5.
Calling it a “remote kill switch” is a gross misinterpretation of how the process works. It’s an activation lock, that prevents a phone from being reactivated again after an erase unless the user’s credentials are entered. It’s not possible for someone to remotely say, “I want this phone destroyed”. That’s just not how it works.
Very helpful, thank you.
Curious how this part is implemented. Maybe something like “The only thing you can do remotely is to send an authenticated request to the device telling it that iCloud wants it to wipe itself.” Which, if my guess is right, is that middle ground I was hoping for – degrades the phone, but doesn’t require giving root to anyone other than the owner.
This topic was automatically closed after 5 days. New replies are no longer allowed.
