SecPKCS12Import returns different results on iOS 11 than on iOS 10

Question

This function takes as an argument Base64 encoded PKCS#12 certificate string which is then decoded and passed to SecPKCS12Import function. After update to iOS 11 the SecPKCS12Import, yields different results. The securityError returns 0 on both OS versions.

let securityError: OSStatus = SecPKCS12Import(decodedData!, options, &items)

Returns list of 0 items. Whereas on iOS 10 I get 1 item in the array.

func certificateFromCertificate(certP12: String, psswd: String) -> SecCertificate {
    let decodedData = NSData(base64Encoded: certP12, options:NSData.Base64DecodingOptions(rawValue: 0))

    let keytmp : NSString = kSecImportExportPassphrase as NSString
    let options : NSDictionary = [keytmp : psswd]

    var certificateRef: SecCertificate? = nil

    var items : CFArray?

    let securityError: OSStatus = SecPKCS12Import(decodedData!, options, &items)

    let theArray: CFArray = items!
    if securityError == noErr && CFArrayGetCount(theArray) > 0 {
        let newArray = theArray as [AnyObject] as NSArray
        let dictionary = newArray.object(at: 0)
        let secIdentity = (dictionary as AnyObject)[kSecImportItemIdentity as String] as! SecIdentity
        let securityError = SecIdentityCopyCertificate(secIdentity , &certificateRef)
        if securityError != noErr {
            certificateRef = nil
        }
    }

    certificate = certificateRef

    return certificateRef!
}

The is a post on Apple Developer forum saying that SecPKCS12Import implemented automatic conversion from Base64. This would mean I should decode plain certificate prior passing it to the function. Can this be the issue?

I have submitted post to Apple Forum and also Technical Support incident.

Development environment:

Programming language: Swift 3

Debug device: Apple iPad mini Retina Wi-Fi 32GB ME280SL/A

Development device: iMAC mini Xcode version 9.0 9A235

Answer 1

Using Xcode Version 9.0.1 (9A1004) and Apple Swift version 4.0 (swiftlang-900.0.65.2 clang-900.0.37), I am able to get normal results from your function. Also works with Swift language set to 3.2.

In the post you referenced, @eskimo said (bolding mine):

Your options here are:

• File a compatibility bug against iOS 11 beta and hope that it gets fixed before GM
• Change your app to use SecPKCS12Import in the documented way, that is, undo the Base64 decoding

It appears that someone filed a bug, and the problem has been fixed (made to work as originally documented). There is no automatic decoding from Base64. You're right to provide the decoding.

Answer 2

Apple Developer Support has investigated this issue and came to conclusion that the specific .p12 file has DER encoding not with security requirements of iOS 11.

Below posting Quinn's email from Apple DTS:

To understand what’s going on you must set a breakpoint on the function SecKeyCreateRSAPrivateKey. This is a private function within the Security framework, so you’ll need to use a symbolic breakpoint (in the Breakpoints navigator, click the + button and choose Symbolic Breakpoint from the menu. Once you’ve done that, tap the “Test 1” button and you’ll stop at the breakpoint.

This function takes 4 arguments, but the two relevant ones are the second and third arguments, which are a pointer to the RSA private key

data to decode and the length of that data. Once you hit the breakpoint you can dump the data as follows:

(lldb) # Confirm the length in the third argument.
(lldb) p $arg3
(unsigned long) $0 = 1192
(lldb) # Dump the data pointed to be the second argument.
(lldb) memory read -f x -s 1 -c 1192 --force $arg2
… elided …

The result is too long to include here so I undid the hex encoding and attached the result as a file, RSAPrivateKey.asn1.

If you dump this with dumpasn1 you’ll see the problem:

$ dumpasn1 -p -a RSAPrivateKey.asn1 
SEQUENCE {
  INTEGER 0
  INTEGER
    …
  INTEGER 65537
  INTEGER
    00 0B 67 67 29 0A 38 38 7A 7E 17 39 E7 84 FB 7D
    02 D1 AB AD 21 27 4D CD 2C 09 C1 1F CB 73 5C 18
    37 D4 CE E2 98 61 19 3B 70 6C 1A 1B 33 E8 69 8C
    65 5B 77 B8 24 9C 90 8A 79 A7 4A 77 26 38 7C 3E
    70 3C 80 24 BD 73 DA 97 5A F3 90 0F 79 2D 45 F8
    2A 5A 37 03 4D 0C 80 DB 8F 99 67 55 D3 F3 70 CA
    2D F0 B6 48 6A D8 9A 95 CE AA C8 F1 96 24 04 61
    38 A1 7C CD 56 70 5E F9 13 D4 1B E2 F2 5D 28 67
    9A 30 E0 ED 71 84 4C EC 86 44 18 5F 64 70 46 D8
    6B 3A 52 2C D7 DE AF E5 E2 35 41 0D 1E FF E7 DE
    AC 43 83 5C A6 F2 2E C8 79 1A 30 87 7A 78 9B 42
    3E D9 2D AA C0 9D A6 7C E9 5C E3 6C 1E 8D 87 DF
    EB 05 DF CA F5 B9 2D BA B6 01 71 18 22 4D 25 4E
    D5 77 CB B8 9B 95 F9 C6 39 1C 0D D2 46 E4 4A 45
    D8 26 6F B4 25 03 E7 BE 91 02 43 7D DC B0 1E C8
    67 E8 2E 5F EA 3A 8D 1C 69 43 80 F9 60 69 BF BA
    01
    Error: Integer has non-DER encoding.
  INTEGER
    …
  INTEGER
    …
  INTEGER
    …
  INTEGER
    …
  INTEGER
    …
  }

Note the “Integer has non-DER encoding” error raised flagged in the fourth INTEGER element. This arises because the INTEGER data is not canonical. In ASN.1 DER, INTEGERs are signed, which introduces an ambiguity. A value like 80 00 could be interpreted as -32768 or 32768. To resolve this ASN.1 DER requires that the positive form is encoded as 00 80 00 (there’s a similar case that requires a leading ff). Furthermore, DER specifically requires that this leading byte only be added when necessary. In the case shown above the second byte, 0b, doesn’t have the top bit set, and thus mustn’t have that leading 00.

Earlier versions of iOS did not enforce this requirement. iOS 11 includes a number of security hardening changes, and rejecting invalidly encoded ASN.1 DER INTEGERs is one of those changes.

I’ve seen other developers get bitten by this security change but those cases were easier to debug because the keys weren’t embedded within a PKCS#12. For example, consider the following DevForums thread. https://forums.developer.apple.com/message/262593#262593 Furthermore, this problem was tricky to debug because, when you unpack the .p12 with openssl, it ignores this error on input and, on output, emits a fixed version of the private key!

Quin recommended me to resolve this issue by fixing whatever code is generating this PKCS#12 data. If that’s not possible you’ll need to write (or acquire) your own code to parse the PKCS#12. iOS 11 is correctly rejecting an erroneously formatted private key, and that’s unlikely to change.