Security tradeoffs of private keys and access groups?

I was looking into ways to create a p12 locally and have it accessible, by Safari, but have come to the conclusion that this isn't possible on iOS.


The reason I was looking into this, was concern over the private key leaving the device.


I am able to create a CSR in iOS and send it out to the server to get signed. And it even seems possible to then use the created private key to match with returned .cer and have an identity, and even creating a .p12 blob.


But, at this point, there seems to be no feasible way to get the locally created .p12 out of my app's access group and into Apple's. Safari and SFSafariViewController don't allow access to locally stored files, so "file:///" file paths don't work.


Just curious as to why this isn't possbile? Whereas if I create a .p12 server-side and open it up using a web address in Safari, email it to myself or include it in a .mobileconfig sent from an MDM, I can get into into Apple's access group - but all of these methods have the .p12 going over the wire, is there not a security risk here with exposing the private key?


There seems to be a security tradeoff here, where Apple is ok having the private key go over the wire vs. installing .p12 or profiles out of the local filesystem, and I was wondering if there's more I can read up on to understand why these restrictions are in place?


Thanks.

Replies

I was looking into ways to create a p12 locally and have it accessible, by Safari, but have come to the conclusion that this isn't possible on iOS.

Indeed.

I was wondering if there's more I can read up on to understand why these restrictions are in place?

The best place to find official answers to questions of security policy is the iOS Security document (you can find a link to it in the Security Resources pinned post). I don’t think that covers this specific case, but the doc makes for good reading regardless.

In the absence of an official answer, all we have is speculation. The way I look at this is that iOS starts out with a ‘secure by default’ attitude, which means that apps live in their own sandbox, where any cross-sandbox communication has to be explicitly added. There’s no specific affordance for this particular problem, and hence we’re in the situation we’re in.

If you’d like to see this change your best option is to file an enhancement request describing your requirements. Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for the reply!


Filed a couple of enhancement requests:

50344263, and

50344074