Re:Apple files final response in San Bernardino iPhone case
by comex on Wednesday March 16, 2016 @01:11AM
(#11295182)
> Why would this process have any higher risk of being compromised than Apple's normal release process for signing new iOS versions?
It wouldn't. In fact, since every iOS restore contacts an Apple server to re-sign the firmware with a device-specific chip ID and unique nonce[1], all Apple would have to do is configure the signing server to sign the government firmware only for approved ECIDs (which might require some engineering effort to ensure that the internal process for adding images/ECIDs is secure and well-documented, but nothing unreasonable). Because the signing server is already connected to the Internet rather than, say, airgapped and brought out only when a new firmware needs to be signed, signing additional/alternate images wouldn't increase the risk of key compromise.
I support Apple's moral stance but hell if the "hacker risk" part of their argument isn't bullshit.
It wouldn't. In fact, since every iOS restore contacts an Apple server to re-sign the firmware with a device-specific chip ID and unique nonce[1], all Apple would have to do is configure the signing server to sign the government firmware only for approved ECIDs (which might require some engineering effort to ensure that the internal process for adding images/ECIDs is secure and well-documented, but nothing unreasonable). Because the signing server is already connected to the Internet rather than, say, airgapped and brought out only when a new firmware needs to be signed, signing additional/alternate images wouldn't increase the risk of key compromise.
I support Apple's moral stance but hell if the "hacker risk" part of their argument isn't bullshit.
[1] https://en.wikipedia.org/wiki/SHSH_blob