Unexpected Core Foundation attribute types when inspecting an existing Secure Enclave-associated Keychain key on macOS

Privacy & Security General
babaolon OP
Created
Replies 2
Boosts 0
Views 56
Participants 2

Hello Apple Developer community,

I'm investigating an unexpected metadata representation returned by Apple's Security framework while inspecting an existing Secure Enclave-associated Keychain item on macOS.

A read-only inspection using SecItemCopyMatching returns one matching key record with a successful status, a Secure Enclave token identifier (com.apple.setoken), and a 256-bit key size.

However, direct Core Foundation type inspection reports:

  • kSecAttrKeyType: CFNumber
  • kSecAttrKeyClass: CFNumber
  • kSecAttrSynchronizable: CFNumber

The raw Core Foundation observations and bridged observations agree.

Our current validator rejects these unexpected types and returns UNSUPPORTED_OR_INCOMPLETE_METADATA.

We have deliberately stopped further key operations pending clarification.

Questions:

  1. Can these CFNumber values legitimately appear in a dictionary returned by SecItemCopyMatching for Secure Enclave-associated key items on macOS?
  2. What returned value types should be expected for these three attributes, and are they dependent on the query or Keychain implementation?
  3. Is there an Apple-recommended way to normalize or validate these attributes without incorrectly accepting incompatible metadata?
  4. How should an application distinguish an existing Secure Enclave-backed key from an incomplete or unsupported Keychain record without performing a private-key operation?
  5. Are there relevant Security framework documentation references or known implementation differences we should consult?

Our aim is to validate the existing record safely without regenerating, deleting, or using the private key.

Thank you for your guidance.

Answered by DTS Engineer in 914775022

I’m sorry but I don’t understand what you’re asking for here. It seems like you’ve got the attributes of a keychain item and some of the properties are numbers. That’s not unexpected. If you look in <Security/SecItem.h> you’ll see a doc comment like this:

    @constant kSecAttrKeyType Specifies a dictionary key whose value is a
        CFNumberRef indicating the algorithm associated with this key
        …

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Replies  2
Boosts 0
Views  56
Participants  2
DTS Engineer OP
Apple
Recommended

I’m sorry but I don’t understand what you’re asking for here. It seems like you’ve got the attributes of a keychain item and some of the properties are numbers. That’s not unexpected. If you look in <Security/SecItem.h> you’ll see a doc comment like this:

    @constant kSecAttrKeyType Specifies a dictionary key whose value is a
        CFNumberRef indicating the algorithm associated with this key
        …

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
babaolon OP

Thank you, Quinn. Your clarification is helpful.

I understand now that a numeric value for kSecAttrKeyType is not necessarily unexpected, and that I should distinguish the attribute dictionary key's type from its corresponding value's type.

To clarify the original question: during a read-only inspection of an existing Secure Enclave-related Keychain item, the returned attributes included:

  • kSecAttrKeyType: CFNumber
  • kSecAttrKeyClass: CFNumber
  • kSecAttrSynchronizable: CFNumber

My concern is not simply that numeric attributes exist. I am trying to determine whether these specific returned types are expected, particularly kSecAttrSynchronizable, whose documented value type is CFBoolean.

Could you clarify whether these representations may legitimately differ depending on the Security API or Keychain implementation used, and whether they are sufficient to validate the item's key metadata?

I can provide the exact read-only API call and Core Foundation type IDs for additional context.

Thank you for your guidance.