5 ms·

Question for HN in general: Is it possible in principle (for Apple or someone else) to construct a smartphone that can accept software/firmware updates, but tha

• nefitty 11y ago
  This could be possible if at setup time the user was asked to create their own key, which any update would have to be signed with. This would then unburden Apple of having the "master key" needed to sign software updates, but would create an extra hoop for users to jump through to update their phone. I'm sure we've all experienced putting off a necessary update to software because of the inconvenience it would cause. Imagine millions of iPhones becoming vulnerable overnight because of mass user laziness.
  • abecedarius 11y ago
    Presumably you could set up to automatically sign anything signed by Apple, if that tradeoff suits you.
    • nefitty 11y ago
      The security issue of Apple being vulnerable to being compelled to create signed backdoors would still remain, in that case.
      • abecedarius 11y ago
        Yes, for the people who chose to be, when they chose. This choice would be decoupled from the OS choice.
  • nindalf 11y ago
    How about a simpler rule like "no updates will install unless the phone is unlocked"? Such a rule would make discussion in the San Bernardino case moot. In response, the government would have to outlaw this practice and force device makers to retain the ability to push updates to a locked phone.
    • cesarb 11y ago
      From what I understand, the discussion is about an update being installed through the low-level bootloader, while the phone being locked is a function of the higher-level operating system (which probably already has the "no updates will install unless the phone is unlocked" rule). The relevant rule would instead be something like "installing any update through the low-level bootloader always wipes the encryption keys and the data partition". Normal updates wouldn't be through the low-level bootloader, so this rule isn't too restrictive. Not that it makes any difference. The attackers in this case don't have to install the update in any normal way, be it through the normal operating system or the bootloader; they can instead desolder the NAND chips and write the update directly to them. What I believe the attackers actually need is a signature from Apple. If the bootloader chain checks the operating system's signature, it won't boot unless it's signed by Apple.
• abecedarius 11y ago
  http://mjg59.dreamwidth.org/39999.html http://mjg59.dreamwidth.org/39999.html -- lock to the owner's signing key, not the manufacturer's.
• RaleyField 11y ago
  They could involve third parties in signing updates and if a device receives an update that isn't disseminated to all third parties it doesn't accept it. That way apple couldn't dispatch custom/backdoored updates to individual devices without revealing that they did it.
  • vog 11y ago
    This would be a good step forward, but maybe not enough. For example, they could be forced to first publish an update to all devices (through the third parties) which disables the third-party-checks. Then, they could be forced to put the backdoor on individual devices.
    • RaleyField 11y ago
      > For example, they could be forced to first publish an update to all devices (through the third parties) which disables the third-party-checks. And the device wouldn't accept it. If I subscribed to an organisation over which USG has no sway, say Computer Chaos Club from Germany, then my update wouldn't be accepted unless additional signatures were provided from them. Unless USG forced Apple to abandon such scheme for everyone then they would be powerless to backdoor individuals. I'm also not sure how relevant this is here, but in US it's been established that software is speech and is protected by the first amendment so there are limitations to ways in which US can influence Apple.
      • vog 11y ago
        So you expect other communities to review all code changes? No way. This would be a huge time sink, and so far has never worked in the past. This only works for very narrow-scoped projects, where the reviewers are also part of the project. Thinking or OpenBSD, Qt or other projects where peer-review is part of their internal structure. So if other communities were to sign the releases, this would have to be automatic or semi-automatic. It would not be a review, but it would be still helpful, since those external observers then can see all releases in hindsight. So maybe years later some people are finding stuff and can trace it back to the point in time and the exact update by which it was introduced.
• darawk 11y ago
  It should be completely possible for them to not accept any software updates unless the phone is unlocked. They may not wish to do this for various reasons, but it is definitely technically possible.
  • thisisdave 11y ago
    Or to wipe the phone if it's updated without being unlocked.
• jimrandomh 11y ago
  It is possible, with caveats. The user has to be able to decide whether to accept an update or not, and signal their assent or rejection with their password. And the software has to be open source, so that the user can inspect a proposed software update and decide whether it is malware or not (or let others inspect it and know they have the same thing). In practice this is imperfect, because trustworthy volunteers willing to audit software are scarce.
• Someone 11y ago
  "can we implement all security functionality in hardware/burn it into the silicon? Or accomplish the same ends by some other means?" Yes. The software could be burnt into PROM (which is unchangeable) or one could even create a custom ROM chip, and if necessary contain hardware or code that checksums the ROM. However, a company doing that must be willing to run the risk that there is a bug in that unchangeable software/hardware and then either tell their customers that they are screwed, or that they can get a free replacement phone. It also may lengthen development cycles, as you cannot, at last minute, order your factory to open a million boxes and update that part of the firmware anymore. Alternatively, a fully open phone would allow customers to inspect updates and reject them or perhaps even to partially reject them (partial rejection would prevent the case where users want a feature, but only can get it by accepting weaker security). That requires a 100% open phone (hard- and software) and enough knowledgeable people willing to invest time in looking at the code.
  • zimpenfish 11y ago
    > That requires a 100% open phone (hard- and software) and enough knowledgeable people willing to invest time in looking at the code. Which, sadly, seem to not exist (cf the long term bugs in OpenSSL et al)
  • chadzawistowski 11y ago
    > That requires a 100% open phone (hard- and software) I am eagerly awaiting the http://neo900.org/ http://neo900.org/ Unfortunately the baseband modem is still unfree, but at least it's isolated over the USB bus, versus having direct memory access as many phones do. Unfortunately no phone has a free, legal modem. Anyways, I'm more excited about the prospect of the phone itself being completely free. In their own words: > Not a single line of closed code will have to run on the main CPU to be able to use the Neo900. Using free telephony stacks like FSO or one from QtMoko, FLOSS Linux drivers will be available for every single component. In order to get 3D acceleration working, which is not necessary to operate the device, closed drivers would be needed.
    • SturgeonsLaw 11y ago
• SomeCallMeTim 11y ago
  Security and usability are always going to be on a spectrum. Even in the San Bernadino case, if the FBI hadn't changed the user's iCloud password, just bringing the phone to a trusted WiFi network would have caused it to automatically back itself up to the cloud. Even assuming the phone were completely 100% locked down perfectly, as long as you're sending backups to Apple that aren't encrypted, you're putting the data one subpoena away from the FBI (or from a hacker who breaks into Apple). So say you don't use iCloud, or Apple starts a service where the backup is encrypted by your password. Your password needs to be really strong for this to work, and Apple needs to use something like bcrypt or better to hash it, but say they do that as well, and you have an long random password. Then you can put a chip on the phone that refuses to ever be updated, and that implements the password lockout logic (try 10 bad PINs and it wipes the key). What they're asking Apple to do now would simple be impossible. But you're allowing iOS itself to be updated, right? So if, for instance, you're discovered to be a terrorist, Apple could push a patch to the main OS that simply grabs the key after you've unlocked the phone and sends it to them. No more need for the secure chip; just decrypt the flash directly. Or easier, the patched OS could just slowly upload all the data on the phone to a backup server whether or not the user opted in to such a backup plan. If there's a lot of data (tons of photographs, for instance), they could even have the phone wait until it detects a known wireless access point to trigger the backup. The FBI could then arrange for that access point to be active near you and your device, and it could connect and upload to a server sitting in the FBI van nearby. Also keep in mind that just about every release of iOS was designed to be impossible to jailbreak. And it seems that iOS 9 can still be jailbroken. This is typically done using an OS vulnerability that's exploited; the FBI/NSA could easily use those approaches to hack your phone (though all would require an already unlocked device, so they'd probably need to get you to run something via social engineering, but some of the hacks only require you to click on a specially crafted link on a web site...). Finally, remember what I said about security and usability? Yeah, now if you forget your password and need it to be reset, you no only lose the data on your phone, but all of your backups. Oops. All of that and you're still not protected from a coordinated attack. It's great for Apple to do whatever they can to resist giving the government the keys to everyone's privacy, because that can be abused. But it's safest to consider anything you typed into a computer or phone to be something that might get posted publicly.
• the8472 11y ago
  That's not necessary. Simply tying the encryption to a strong password instead of a 4-digit PIN would have been sufficient to prevent a firmware update to a locked device from weakening security, at least in this particular case. Throw in a memory-hard key derivation function to make parallel brute-force more expensive.
  • rtpg 11y ago
    But making updates require password input would close the backdoor entirely
• tallanvor 11y ago
  You could certainly reduce some of the attack surface, but you couldn't eliminate it entirely. I think a more reasonable option is to design phone in such a way that attempting to load software on the phone when it's locked bricks it and causes the encryption keys to be destroyed.
• cesarb 11y ago
  > Question for HN in general: Is it possible in principle (for Apple or someone else) to construct a smartphone that can accept software/firmware updates, but that Apple cannot push malware to at some later time? I've been thinking about a related question: how to construct an update system so the updater cannot push malware to a specific phone, without making it visible and available to everyone else? My answer would be something like Certificate Transparency (https://en.wikipedia.org/wiki/Certificate_Transparency https://en.wikipedia.org/wiki/Certificate_Transparency). The update system would only accept an update if it's signed by several independent entities, spread all over the world (in many independent jurisdictions), and the signing system in these entities would be designed in such a way that every signature is written to an append-only log which is published to everyone to see, and these entities would also publish a copy of every update they signed. That way, Apple could still push malware to a phone, but they couldn't push malware to a phone without making that fact public, at least to security researchers who can reverse-engineer firmware updates.
  • jacquesm 11y ago
    If the US can get a presidential plane diverted and forced to land where it did not want to I don't think it is beyond imagination to see that 'independent entities spread out all over the world in many independent jurisdictions' could be coerced as well.