Skip to content
  • About Me
  • Books
  • Photography
  • Papers
  • Security
  • Forensics
  • Essays
  • Christianity

Calendar

January 2023
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
« Dec    

Archives

  • December 2022
  • November 2022
  • July 2022
  • March 2022
  • January 2022
  • December 2021
  • November 2021
  • September 2021
  • July 2021
  • December 2020
  • November 2020
  • March 2020
  • September 2019
  • August 2019
  • November 2018
  • August 2018
  • March 2018
  • March 2017
  • February 2017
  • January 2017
  • November 2016
  • October 2016
  • July 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • June 2015
  • March 2015
  • February 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • January 2014
  • October 2013
  • September 2013
  • June 2013
  • May 2013
  • April 2013
  • December 2012
  • May 2012
  • September 2011
  • June 2011
  • August 2010
  • July 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • July 2009
  • May 2008
  • March 2008
  • January 2008
  • June 2007
  • August 2006
  • February 2006

Categories

  • Apple
  • Christianity
  • Essays
  • Forensics
  • General
  • Machine Learning
  • Music
  • Opinion
  • Photography
  • Politics
  • Security











ZdziarskiDFIR, security, reverse engineering, photography, theology, funky bass guitar. All opinions are my own.
  • About Me
  • Books
  • Photography
  • Papers
  • Security
  • Forensics
  • Essays
  • Christianity
Apple . Politics . Security

How Apple Can Make Their FBI Problems Go Away

On March 31, 2016 by Jonathan Zdziarski

An adversary has an unknown exploit, and it could be used on a large scale to attack your platform. Your threat isn’t just your adversary, but also anyone who developed or sold the exploit to the adversary. The entire chain of information from conception to final product could be compromised anywhere along the way, and sold to a nation state on the side, blackmailed or bribed out of someone, or just used maliciously by anyone with knowledge or access. How can Apple make this problem go away?

The easiest technical solution is a boot password. The trusted boot chain has been impressively solid for the past several years, since Apple minimized its attack surface after the 24kpwn exploit in the early days. Apple’s trusted boot chain consists of a multi-stage boot loader, with each phase of boot checking the integrity of the next. Having been stripped down, it is now a shell of the hacker’s smorgasbord it used to be. It’s also a very direct and visible execution path for Apple, and so if there ever is an alleged exploit of it, it will be much easier to audit the code and pin down points of vulnerability.

Apple’s trusted boot process sits in front of the operating system, and can keep the OS dark until proper authentication has been completed. It can also prevent ram disks (containing firmware updates, backdoors, or forensics tools) from booting until the device has been authenticated by the user. If the user were given an optional setting to add a boot password to their device, they could set this boot password to be longer and more complex than their day-to-day screen password. Without first unlocking the boot loader with this password, a device would not be able to boot any firmware – even that signed by Apple (in the event of a successful AWA order some day).

Something like this could be accomplished by encrypting part of the boot chain. Perhaps encrypt the device tree or even part of iBoot itself and keep the key in the Secure Enclave, encrypted with a key derived from the boot password xor’d with the uid, using a pbkdf2 iteration of around 80ms like always. This should prevent brute forcing from being possible, and also prevent direct manipulation of the boot sequence. Ideally, having an extra phase between the low level boot loader and iBoot that would prompt for the boot password, decrypt the boot key, decrypt iBoot, then check signing, load, and execute iBoot would be ideal.

Of course the question is what is the cost to the user experience. Here, it is virtually none. The user is already out of luck if they forget their device passcode; they have to restore the device. The same would be true for a boot password. Users who can navigate the menus to set it up must have at least half a brain to use it in the first place. Should the user forget their boot password, they can be given the option of wiping the device and restoring it back to an unlocked state (this could be done by simply wiping the key from the Secure Enclave, as well as effaceable storage on the device). There would be no bricking of devices here, only a wipe and restore if you forgot your boot password.

Unlike the device’s operating system – which has proven to be vulnerable to dozens of attacks every release cycle, the device’s boot loader has such a stripped down code base that it’s attack surface is the head of a pin compared to the operating system. This would essentially render FBI’s new forensics toy obsolete – no matter what exploit they’re using – because the operating system itself would not even be loaded. With the OS dark, there’s no way of attacking the firmware, or even the Secure Enclave, without first exploiting this trusted boot chain. Did I mention it hasn’t been successfully compromised in years?

Apple could make their FBI problems go away without even needing to know what they’re doing to compromise iOS. It won’t be easy cramming all that extra code into the boot loader, so don’t expect to see something like this tomorrow. It should definitely get onto their list of important things to do, though.

Apple has always been highly protective of the user experience, but having been out for almost ten years, we’re no longer school children with iOS. With adversaries including nation state actors, the balance between a simplistic and pretty user interface must slightly shift toward protecting user data. Especially on devices with such a large footprint of forensic artifacts.

 

 

Archives

  • December 2022
  • November 2022
  • July 2022
  • March 2022
  • January 2022
  • December 2021
  • November 2021
  • September 2021
  • July 2021
  • December 2020
  • November 2020
  • March 2020
  • September 2019
  • August 2019
  • November 2018
  • August 2018
  • March 2018
  • March 2017
  • February 2017
  • January 2017
  • November 2016
  • October 2016
  • July 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • June 2015
  • March 2015
  • February 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • January 2014
  • October 2013
  • September 2013
  • June 2013
  • May 2013
  • April 2013
  • December 2012
  • May 2012
  • September 2011
  • June 2011
  • August 2010
  • July 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • July 2009
  • May 2008
  • March 2008
  • January 2008
  • June 2007
  • August 2006
  • February 2006

Calendar

January 2023
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
« Dec    

Categories

  • Apple
  • Christianity
  • Essays
  • Forensics
  • General
  • Machine Learning
  • Music
  • Opinion
  • Photography
  • Politics
  • Security

All Content Copyright (c) 2000-2022 by Jonathan Zdziarski, All Rights Reserved