ACLU Shows How the Apple-FBI Fight Was About Much More Than One Phone (theverge.com)
Russell Brandom reports for The Verge: Apple's San Bernardino fight may be over, but the government is still seeking both Apple and Google's help in unlocking phones. New research from the American Civil Liberties Union shows 63 different cases in which the government compelled help from Apple or Google in unlocking a handset. It's unclear how many of the orders were filled, although companies often complied with such orders where possible before last year. The bulk of the cases target Apple, but nine of the orders also look to compel Google's help, typically to reset the password on a given device. The devices include phones from Alcatel, Kyocera, and Samsung, many of which shipped without the default device encryption that blocked the use of traditional forensic tools in the San Bernardino case.
"FBI Admits It Urged Change Of Apple ID Password For Terrorist’s iPhone"
http://www.buzzfeed.com/johnpa...
If I have been able to see further than others, it is because I bought a pair of binoculars.
The revelation that Apple and Google are both receiving many of these requests and have complied on some of them, reversing course only recently, is an important artifact in the narrative.
Note that this may not have been a choice by the companies. As I understand it (IANAL), if the company can comply and can't show any egregious harm that would be caused by compliance, they have to comply or be in contempt of court, and judges have extremely wide latitude in the penalties they can apply for contempt. So the change may have been that security improvements made it impossible for them to comply, or -- as Apple was arguing -- impossible to comply without egregious harm.
On the Google side, for example, one thing that changed was that Google removed the device admin and Android device manager features that allowed the password to be remotely reset. IIRC, the remote reset features were removed in Lollipop. In Marshmallow my team moved password verification into the trusted execution environment. The TEE app (called Gatekeeper) that manages password authentication does allow a "forcible" password change, where the old password is not provided, but higher layers don't offer any way to do this, and doing it will cause the TEE-based crypto keystore to permanently and irrevocably invalidate all authentication-bound keys. Such as the one used for device encryption. So a forcible reset doesn't let you in, it bricks the device (until factory reset).
Previously, device admins could remotely reset passwords so that enterprises could let users into their managed devices when they'd locked themselves out. No more. Now all the admin can do is wipe the device. Android device manager will still allow you to change the password remotely, but you have to provide the old one (and you have to have configured Android device manager on the device, and you have to be able to log into the Google account associated with the phone).
These changes were made to eliminate the potential for abuse by Google, rogue employees, etc. But they had the side effect of making it impossible for Google to comply with password reset requests.
(Disclosure/disclaimer: I'm a Google Android engineer. I work on the TEE-based password manager and crypto keystore. All of the above is publicly available information, however. I tried to avoid expressing any opinions, sticking only to facts. If you find an opinion, however, it's mine and not Google's.)