Temporary RSA key pair creation

Question

Created Nov ’17

Replies 3

Boosts 0

Views 1.8k

Participants 2

Hi there,

I need to generate a temporary RSA key pair to be used internally in my application, then trashed. I.e., it should never be stored in Keychain.

Since I must support macOSen back at least to 10.10, I am using the SecKeyGeneratePair API (for

SecKeyCreateRandomKey

is 10.12+). My first attempt

SecKeyGeneratePair((__bridge CFDictionaryRef)@{
    (id)kSecAttrKeyType:(id)kSecAttrKeyTypeRSA,
    (id)kSecAttrKeySizeInBits:@2048,
    }, &pubkey, &privkey);

worked well, but in my login keychain, two anonymous keys occurred. Thus, I have tried very explicitly

SecKeyGeneratePair((__bridge CFDictionaryRef)@{
    (id)kSecAttrKeyType:(id)kSecAttrKeyTypeRSA,
    (id)kSecAttrKeySizeInBits:@2048,
    (id)kSecPublicKeyAttrs:@{(id)kSecAttrIsPermanent:(id)kCFBooleanFalse,(id)kSecAttrLabel:@"My test, Pub"},
    (id)kSecPrivateKeyAttrs:@{(id)kSecAttrIsPermanent:(id)kCFBooleanFalse,(id)kSecAttrLabel:@"My test, Priv"},
    }, &pubkey, &privkey);

(note permanent:NO's) — but alas, again, those two keys did occur in my keychain!

How do I create a temporary key pair, whose existence is limited to my application and which never makes it to Keychain? Thanks!

Answered by DTS Engineer in 276757022

I don’t think that’s possible on older versions of macOS. Support for

kSecAttrIsPermanent

in

SecKeyGeneratePair

has always been a bit inconsistent between macOS and iOS-based platforms, which is the main reason we introduced

SecKeyCreateRandomKey

back in 10.12. If you have to support older platforms you’ll need to find a place to put the keys.

One option is to create a temporary keychain (

SecKeychainCreate

) and store the keys there.

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

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

Boost

Answer 1

DTS Engineer OP

Apple

Nov ’17

Accepted Answer

I don’t think that’s possible on older versions of macOS. Support for

kSecAttrIsPermanent

in

SecKeyGeneratePair

has always been a bit inconsistent between macOS and iOS-based platforms, which is the main reason we introduced

SecKeyCreateRandomKey

back in 10.12. If you have to support older platforms you’ll need to find a place to put the keys.

One option is to create a temporary keychain (

SecKeychainCreate

) and store the keys there.

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

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

0

Answer 2

OCS1 OP

Nov ’17

Alas, the place should be “a memory buffer“ (my client actually knows zilch of security, but has heard somewhere that “what's not saved in any file is secure“ and wants that, poor bloke).

Is there a memory-only way supporting 10.10+, or are we completely SOL? Thanks!

0

Answer 3

DTS Engineer OP

Apple

Nov ’17

Alas, the place should be “a memory buffer“

I’d argue that a keychain with your app holding the only copy of the keychain password is equivalent to an in-memory buffer but, hey, I’m not offering to educate your client for you (-:

Is there a memory-only way supporting 10.10+ …?

Honestly, I’m not 100% sure. My understanding is that, prior to 10.12, macOS had no way of representing an in-memory key, that is, a key that’s not backed by some keychain-like thing (either a keychain or a cryptographic token). However, that restriction might only apply to the high-level Apple APIs. You might be able to do this with the low-level CDSA APIs. I don’t know those well enough to give you a definitive answer.

I have four options for you:

Bump your deployment target to 10.12.
Use a private keychain and educate your client as to its security characteristics.
Not use system APIs, but instead do these crypto operations using your own code (code you write, or a library you adopt).
Open a DTS tech support incident and talk to our CDSA expert as to whether that route is feasible.
And nice red uniforms!

IMPORTANT CDSA has been deprecated for a while now. Normally I recommend against writing new code that talks to a deprecated API, but in this case you already have a clear path to a recommended solution on 10.12 and later, and the deprecated code would only be filling in the gap prior to 10.12.

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

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

0