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

Calendar

July 2022
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031
« Jun    

Archives

  • June 2022
  • May 2022
  • March 2022
  • January 2022
  • December 2021
  • November 2021
  • September 2021
  • July 2021
  • January 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

Code is Law

On February 17, 2016 by Jonathan Zdziarski

For the first time in Apple’s history, they’ve been forced to think about the reality that an overreaching government can make Apple their own adversary. When we think about computer security, our threat models are almost always without, but rarely ever within. This ultimately reflects through our design, and Apple is no exception. Engineers working on encryption projects are at a particular disadvantage, as the use (or abuse) of their software is becoming gradually more at the mercy of legislation. The functionality of encryption based software boils down to its design: is its privacy enforced through legislation, or is it enforced through code?

My philosophy is that code is law. Code should be the angry curmudgeon that doesn’t even trust its creator, without the end user’s consent. Even at the top, there may be outside factors affecting how code is compromised, and at the end of the day you can’t trust yourself when someone’s got  a gun to your head. When the courts can press the creator of code into becoming an adversary against it, there is only ultimately one design conclusion that can be drawn: once the device is provisioned, it should trust no-one; not even its creator, without direct authentication from the end user.

Apple has done well to maintain control at the top, which gives Apple a certain advantage in being able to assure product consistency, customer service, and provide a very low risk of putting customer data at risk during issues. This has one tragic flaw, however, in that Apple’s devices are too trusting of Apple themselves (and anyone with their signing keys). The latest charade with the FBI’s AWA order is an example of how private industry can be made to swallow its own tail, and when devices are inherently designed to trust their creator, this presents some major concerns for privacy. The third law of robotics, as Asimov put it, dictates that a robot (or machine) must protect its own existence. We rarely ever see this in computer science, but we should.

The only way to ensure that privacy cannot be legislated out by the courts is to consider yourself a threat model in your design. Rather than maintain the power structure at the top, security of the device’s core components should be a two-factor power between both Apple and the device’s owner; this ensures that Apple can’t do anything to your device without the user’s permission. We’ve started to see traces of this begin to surface. For example, Apple’s anti-theft feature tries to prevent a device from being restored until you enter your iCloud password. Firmware updates, as of recent, request the user’s passcode in order to install. But this design needs to go much deeper than that, and the thinking behind these needs to shift from device theft to compromise by the manufacturer.

If code truly is law, the device itself should be autonomous, and only take its cues from Apple with the user’s authentication… on a much deeper level than we see it implemented today. Apple is starting to head in this direction, however much of this is still managed in the software (that can be executed by Apple on the device), where it should be managed deep down within the secure enclave, or even at a chip level. A device’s boot loader should not even be willing to load without the SEP being unlocked by a user boot password. Mission critical security components, such as a passcode delay, wipe on fail mechanism, etc., should be hard-coded into the chip’s microcode so that they can never be disabled or even updated. Encrypting the operating system partition itself with a user key can help prevent trojan or backdoor installations. There are many other great ideas people have for design that I’m sure will trickle into Apple over time.

Whether you’re building a mobile operating system, or an electronic health records system, code should be self-enforcing, and the consequences of losing credentials should be stressed, rather than have mechanisms to compensate. The walled garden approach only gets you so far; you have to build a wall around yourself too if you want to have effective security in your design. Do you want to change the law? Do you want to legislate how your privacy tools are used? Then legislate it into your code.

 

Archives

  • June 2022
  • May 2022
  • March 2022
  • January 2022
  • December 2021
  • November 2021
  • September 2021
  • July 2021
  • January 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

July 2022
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031
« Jun    

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