0

I want to focus on technical aspects, not on the fact that they wanted to make a precedence.

i assume the smartphone security architecture is following:

  1. cryptography chip. it's read only and stateless. it contains physical cryptography key. it offers some transformations of user input. it doesn't expose the key. it doesn't remember number of retries

  2. NAND disk. contains encrypted data

  3. OS. get input from user, talks to the chip, changes the content of the NAND

  4. retries counter. no idea where is it? is it stored on NAND disk or some other dedicated long term memory?

from what i know the FBI wanted apple to make for them less secure iOS version that doesn't erase the disk after a few failed retries. but why do the need it? can't they just:

  • make a copy the NAND disk (in case it has some killswitch)
  • get the chip's spec and just send to it a few millions decrypt request (testing every possible user pin / password)
  • if the chip stores retires counter in some dedicated memory, they can always plug in a tweaked memory that always replies with the same value when read

why do they even need an OS? it's just a simple program that can communicate with a chip. what am i missing?

  • "it's just a simple program that can communicate with a chip" and that's your assumption that needs examining ... – schroeder May 14 at 13:52
  • As you can imagine, this has been a popular question for years. Please use the search bar to look for similar questions. I found the duplicates by using the search term fbi ios – schroeder May 14 at 13:56
  • To the OP's point: See ipadrehab.com/article.cfm?ArticleNumber=33. "The NAND acts like the hard drive of the phone and contains all of the user data. It isn't a huge deal to desolder the NAND chip and there are many inexpensive NAND readers out there that you can plug the chip into and read it... Your data is stored on the NAND as gibberish--it's encrypted..." – mti2935 May 14 at 14:56
  • Thanks @schroeder for posing these links. security.stackexchange.com/questions/118399/… seems especially relevant. OP's suggestion of 'get the chip's spec and just send to it a few millions decrypt request' won't work, because the encryption key is derived from the PIN and a unique key that is stored on the encryption chip which is not known. – mti2935 May 14 at 15:34
  • @mti2935 the chip has the key and use it to generate another the encryption key based on user password. so we can use the chip to generate all the possible encryption keys from user password – piotrek May 14 at 19:17