|
Hello All, Has anyone tried using the FIPS provider on iOS and got it uploaded and successfully reviewed by Apple? Apple won't let you just put the 'fips.dylib' in your app's bundle so we've wrapped it in a iOS Framework Bundle, which solves some of the problems. But Apple are scanning the dylib's mach-o header and finding the type bit field set to
'bundle' rather than 'execute' and rejecting it. I think they might also be looking for particular load commands in the header and not finding them either. I guess changes to the FIPS build process are required to effect any change to the file header? The Framework Bundle must be signed, as every iOS executable must be, so this has to be done before the FIPS Configuration is created via FIPS Install. If you try to perform these operations in the reverse order, i.e. create configuration
and then sign, then the values within the configuration won't match the calculated values when the FIPS Provider subsequently loads and runs. I haven't examined the implementation of FIPS Install but I suspect it's not just examining the mach-o segment with
the executable code in it and is instead detecting any change, i.e. also header changes as a result of iOS signing. Currently we create configurations for all our signing scenarios and then ensure individual FIPS frameworks are not re-signed at any point subsequently.
Sign for App Store Distribution remains troublesome though and what if Apple re-sign the app and consequently the FIPS framework? Failure to load the FIPS Provider would then result. So we're unsure how OpenSSL 3 FIPS can be deployed within iOS apps from the Apple App Store. Would be great to hear whether anyone else has got this working and through an Apple app review. |
