In this case, the key is derived from the chip serial number alone. This is dangerous, because that is not typically private information!

@Manumit Basically anything that shows on the lock screen must be accessible AfterFirstUnlock. Additionally, apps can request up to 10 seconds of background execution time (or unlimited time for audio, voip, or gps apps) after they are backgrounded, and that includes when the phone is locked. Apps can't generally handle having data suddenly become suddenly inaccessible, so AfterFirstUnlock it is again. There is another protection class that I don't think is in that source, called CompleteUnlessOpen, that's made specifically for those sorts of situations, but it requires the app support it.

@Manumit Also note that the "big" changes that have happened since then, like Apple announcing that everything would be encrypted by default and pissing off the FBI, just involve changing the default protection class from Always to AfterFirstUnlock. It's super easy to get access to the Always stuff because you don't have to preserve the RAM contents.

@Manumit Connection to the attacker's network just means a larger attack surface. Consider a app that phones home over HTTP; MITM it and you might be able to exploit a buffer overflow or something and get some ROP going. You'd still need to break out of the sandbox, elevate to root, and patch the kernel though.

@Manumit The source is up to date as of iOS 7; I had an Apple engineer who was squeamish answering my questions about Data Protection pull me into an empty bathroom and tell me that research was all precisely correct but he wasn't actually allowed to go into that much detail.

The PKCS #12 standard allows both encrypted archives containing cleartext certificates and cleartext private keys as well as cleartext archives containing cleartext certificates and encrypted private keys. Depending on what system created your p12 file, you might have either; only in the second case can you get what you want.