NFD » ndn-cxx

Davide Pesavento wrote:

Sadly, macOS doesn't seem to support anything other than HMAC-SHA1, so it fails to import a private key encrypted by a recent openssl with default settings.

I just realized that Apple's Security library is open source, so I looked directly at the code, which confirmed my previous analysis.

From https://opensource.apple.com/source/Security/Security-58286.41.2/OSX/libsecurity_keychain/lib/SecImportExportPkcs8.cpp.auto.html

    /* prf optional, but if it's there it better be CSSMOID_PKCS5_HMAC_SHA1 */
    if(pbkdf2Params.prf.Data) {
        if(!nssCompareCssmData(&pbkdf2Params.prf, &CSSMOID_PKCS5_HMAC_SHA1)) {
            SecPkcs8Dbg("PKCS8: PKCS5 v2 unexpected prf OID");
            return errSecUnknownFormat;
        }
    }
    prf = CSSM_PKCS5_PBKDF2_PRF_HMAC_SHA1;

Later in the same function, we can also see that Apple support only DES, DES_EDE3, RC2, and RC5 as encryption algorithms for the key :(

I see two ways to resolve this:

1. In transform::PrivateKey::toPkcs8, force the usage of HMAC-SHA1 as PRF, restoring compatibility with macOS's SecItemImport. This can be done by using a combination of 3 low(er)-level (and undocumented) openssl functions instead of i2d_PKCS8PrivateKey_bio.
2. Keep using the (more secure) openssl default, but change tpm::BackEndOsx::doImportKey to unwrap and decrypt the key using openssl functions before importing it into macOS keychain.

I'm not sure which way is best. I've tried (1) and it seems to work. On the other hand, (2) would give us more flexibility in the long run, because we're not constrained by what macOS does or does not support, and would also allow us to switch key encryption to AES (which isn't supported by macOS) from the current 3DES.

I am leaning towards option 2, if it is feasible to implement and implementation complexity is reasonable.