Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Every time a file on the data partition is created, Data Protection creates a new 256-bit key (the “per-file” key) and gives it to the hardware AES engine, which uses the key to encrypt the file as it is written to flash memory using AES CBC mode. The initialization vector (IV) is the output of a linear feedback shift register (LFSR) calculated with the block offset into the file, encrypted with the SHA-1 hash of the per-file key.

Regarding the iOS-Security whitepaper (excerpt from pg. 8) when a file is written to the data partition a AES-Key is created which is used by the AES engine to encrypt the file using the AES-CBC mode. AES-CBC does need an initialization vector which is the output of a linear feedback shift register.

  • What is the exact input of the LFSR?

  • What exactly does "block offset" mean?

Does it work like this:

encrypt(LFSR(block-offset),SHA-1(perfile-key)) ---> result stored inside the files meta data

share|improve this question

migrated from Aug 4 '13 at 17:36

This question came from our site for information security professionals.

According to this source, which looked at it in detail, and they also implemented tools to do it, it works as follows (roughly):

Every protected file has a metadata entry that contains its encrypted per-file key, and this per-file key is encrypted with its corresponding class key; the metadata also contains information about the protection class of the file. The metadata field itself is also encrypted, with the EMF-key. The file data itself is encrypted only with the per-file key, and the IV is implicit, i.e. not part of that data (quoting from this followup on iOS 5):

To compute the IV for a block in a file data fork, the input to the IV generator is now the block offset in the file fork (instead of the block LBA on iOS 4), and the resulting IV is then encrypted (AES128) with the "IV-key" to give the actual IV. The "IV-key" is unique per-file and computed using the following formula:

IV-key = SHA1(filekey)[:16]

This is probably to ensure that if different file-system blocks in a file are identical (maybe blocks of 0) the IV's used for those blocks are entirely different (they used to be just the block LBA on iOS 4 fed through an LSFR). The IV generator (from the block offset) is still the same LSFR though (and its source can be found among the mentioned tools).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.