Apple v FBI: To what degree is encryption actually involved

In forming an informed opinion about this mater it is important to understand some of the technical matters involved particularly as they relate to encryption.

Locking and encryption on the phone

Briefly user data on the phone is encrypted with a key that is unique to the phone. The encryption technique used is strong and Apple does not have this key nor can it be accessed without unlocking the phone.

As a convenience to users Apple's design provides that once the phone is unlocked the key used to encrypt the user data is automatically available and users may conveniently access their data without encryption interference.  Note that this is a conscious explicit design choice made by Apple.

To protect the phone locking scheme Apple uses two features. One imposes an increasingly long delay between successive failed login attempts. This is a common technique to thwart brute-force attacks by making them take so long as to be impracticable. Another, if enabled (I believe this is optional and am unsure of the default setting), provides that user data on the device is destroyed if there are excessive successive login failures. This is another common technique to insure that even if someone is willing to take the time to execute a brute-force attack, the data will be destroyed before the attack can succeed.

The San Bernardino order

The San Bernardino order requires Apple to disable the delay and destruction features so that the FBI can execute a brute-force attack, unlock the phone, and access the encrypted user data on the phone. Technically, it is an exploit of the consumer convenience feature designed into the phone.

The specifics of this order are very important.  The order itself can be found here.  In summary it requires the following:

• the creation of software that bypasses the delay and destruction features,
• keying the software to this specific phone,
• providing mechanisms that allow the FBI to access the phone to conduct a brute-force unlock

The order further provides:

• the phone may be in Apple's possession during the unlock process,
• Apple need not provide the software to the FBI,
• Apple is free to dispose of the software as it wishes,
• Apple is compensated for their work supporting the FBI.

Does this work involve encryption?

The short answer, contrary to what many believe, have said, and argued is NO.  

To understand this consider a slightly different phone.  This phone is such that the only way to access the data is to unlock the phone and the underlying storage mechanism does not involve encryption and is immune to physical attack. The unlock features remain the same.

Would the users data protection on this imagined phone be more, less, or unchanged?

I believe that the answer is unchanged.  Any attempt to unlock this phone would almost certainly result in destruction of the data in just the same way as the actual San Bernardino phone.  Once the phone is unlocked the data would be available in precisely the same degree as the San Bernardino phone.  There is simply no effective difference in the data protection.

That illustrates an import element of the San Bernardino case in that encryption of the user data is not actually at issue with respect to the work required by the judge's order.  Rather it is a side effect of the work being ordered that exploits a designed in feature, many would argue weakness, of the phone.

However, there is an element related to encryption that is involved.  The design of the actual San Bernardino phone requires that the software to disable the login delay and delete features that protect unlocking be signed with Apple's authorization key.  This is not strictly an encryption key but is, in some ways, related.  It prevents some software not authorized by Apple from being loaded onto the phone.  Without this key the phone will reject the modified software and the login delay and delete features may not be subverted.

To what degree is encryption actually involved?

Actually none.  Security is certainly involved but not encryption proper.