On mobile terminal devices, device encryptions for access protection have recently been introduced similar to the classic hard disk encryptions with Pre-Boot Authentication (PBA). Apples IOS has taken the lead in this and integrates a comprehensive device and file encryption including Secureboot protection for the boot chain (but without password entry). However, Apple's encryption was recently discussed after an investigation by Cirosec.

Apple has built a hardware-based encryption into its IOS terminal devices (Idevices) since the introduction of Iphone 3GS (and Ipad). Between the working memory and the flash drive is a hardware encryption unit that ensures that the flash memory is fully encrypted with a 256-bit AES (Figure 1). The file system key is not readable stored in hardware and is automatically available for decryption as soon as the device starts. The purpose and purpose of this file system encryption is not (!) the access protection, rather it serves to quickly delete the devices. To delete the flash memory, the key for encrypting the flash memory is simply overwritten by a newly generated key. In order to access "old" data, an attacker would have to either guess the key or break AES.

Encryption of files In addition to encrypting the Flash memory, Apple has introduced file data protection with IOS 4. Individual files are encrypted with individual keys (File Keys, similar to a Session Key) and the key is encrypted with a type of group key (Class Key) for the file system. The basic concept is similar to that of Microsoft's Encrypted Filesystem (EFS) or Utimacos Lancrypt (now Sophos). Figure 2 shows the organizational structure of flash and file encryption in IOS. The advantage of such multi-step encryption is the simplification of some processes: if the user changes his password, only the Class Key can be re-encrypted. If a file is encrypted with another Class Key, only the File Key must be encrypted instead of the complete file. In the production of an idevices, two keys are burned solid "in silicon": the UID and GID keys (Unique ID, Group ID). The UID key is different for each device and can only be used on this device. According to Apple documentation, it is neither saved by Apple nor readable. It plays a central role in protecting the File System Key as well as the Class Keys and allows data to be specifically linked to a device. This is used, for example, when backing up parts of the IOS Keychain so that data can only be recovered on the source device. However, the UID key could also be useful in copying protection to bind content to a specific device. In addition, if Apple provided the UID key with a password, IOS would have a strong PBA. In turn, the GID key is common to all CPUs of one class (for example, all A7-CPUs) and Apple is known to provide additional protection for updates. Also the GID key cannot be read on the device itself. All other keys used on IOS devices are generated with a random number generator based on Yarrow. The interrupted timing during the boot process and the values of various sensors are used as entropy as soon as the system is started. Since Apple has not disclosed any further details, the quality of the random numbers cannot be assessed. However, the "quality" of random numbers has a massive impact on the security of cryptographic keys. Until IOS 6, an application was able to decide for itself which key to encrypt a file created by the application. These are files that are created in the directories Documents/andLibrary/. Each file is encrypted there with an individual key (File Key). This File Key is encrypted with a Class Key and then stored in the metadata of the respective file. IOS distinguishes the following four class keys:NSFileProtectionComplete: The key is only available if the user has entered his password on the screen.NSFileProtectionCompleteUnlessOpen: The key is only available, if the device is locked.NSFileProtectionCompleteUntilFirstUserAuthentication: This key is available as soon as the user has entered his password for the first time after restarting the device.NSFileProtectionNone: This was the default key up to IOS 6. It is always available when the device is switched on.

With the introduction of IOS 7The process of file encryption has been changed with the introduction of IOS 7. Since IOS 7, all files are encrypted by default using the NSFileProtectionCompleteUntilFirstUserAuthentication key. However, it seems possible that an application still selects one of the other keys. According to Cirosec's research, Apple does not use encryption for its own address book, calendar, bookmarks, notes and SMS/Imessage, i.e. probably the NSfileProtectionNone bowl. According to Apple's IOS encryption descriptions, the data are encrypted, but they are directly accessible after the device is started. If you reintroduce a file encryption or revise its concept, updating existing systems on which there is already unencrypted data, you will place the question of how to deal with them. There are several possibilities:All existing data will be automatically encrypted or encoded (initial encryption). All data will remain unencrypted/encrypted using the "old" method, but will be automatically encrypted or encoded during the first editing when rewritten. Uncrypted/encrypted using the "old" method, only new data follow the new standard. Apple has probably chosen this path for the time being when changing the encryption concept. It remains to be seen whether the manufacturer will revise this decision. In the event of an update to IOS 7.0.4, all application data previously protected with the NSfileProtectionNone key will remain accessible immediately after the device starts. An encoding according to the new IOS 7-Policy on the NSFileProtectionCompleteUntilFirstUserAuthentication key does not occur automatically. An app that has previously used the NSfileProtectionNone key therefore needs to be uninstalled and then reinstalled in order to encrypt its data. However, uninstallation implies the loss of all app data, so that all data must be reinterpreted afterwards. From the point of view of the company, therefore, some effort is required in order to make efficient use of the current protection standard of IOS 7. Depending on how IOS devices are integrated into the company, a new installation with IOS 7 is probably not only the cleanest but also the fastest solution.

Figure 2. File Data Protection (File Data Protection). Image: Rainer and Sebastian Gerling

Figure 1. Flash memory hardware encryption (Device Encryption). Image: Rainer and Sebastian Gerling

Rainer W. Gerling, IT Security Officer of the Max Planck Society and Honorary Professor of IT Security at Munich University. Sebastian Gerling, Head of the Centre for IT Security, Privacy and Accountability (CISPA) and academic staff at the Chair of Information Security and Cryptography at the University of Saarland.