Creating machine identifier to be used by daemon based app

Question

Created 1w

Replies 1

Boosts 0

Participants 2

I am developing a daemon-based product that needs a cryptographic, non-spoofable proof of machine identity so a remote management server can grant permissions based on the physical machine.

I was thinking to create a signing key in the Secure Enclave and use a certificate signed by that key as the machine identity. The problem is that the Secure Enclave key I can create is only accessible from user context, while my product runs as a system daemon and must not rely on user processes or launchAgents.

Could you please advise on the recommended Apple-supported approaches for this use case ?

Specifically, Is there a supported way for a system daemon to generate and use an unremovable Secure Enclave key during phases like the pre-logon, that doesn't have non user context (only the my application which created this key/certificate will have permission to use/delete it)

If Secure Enclave access from a daemon is not supported, what Apple-recommended alternatives exist for providing a hardware-backed machine identity for system daemons? I'd rather avoid using system keychain, as its contents may be removed or used by root privileged users.

The ideal solution would be that each Apple product, would come out with a non removable signing certificate, that represent the machine itself (lets say that the cetificate name use to represent the machine ID), and can be validated by verify that the root signer is "Apple Root CA"

Boost

Answer 1

DTS Engineer OP

Apple

5d

First up, let me correct a common misconception: The Secure Enclave doesn’t store keys [1]. Rather, it wraps the key in such a way that only it can unwrap it and use it. It’s then up to you as to where you want to store the wrapped key. A common choice is the keychain, but you could just as easily write the wrapped key to a file.

As to whether you can access the SE from a daemon, my understanding is that this isn’t supported, although I’m working to confirm that in a different context.

But before we start down the SE path, I want to clarify this:

non-spoofable proof of machine identity so a remote management server

What do you mean by “non-spoofable”? Specifically, who are you trying to protect against? Bad actors on the network? Bad actors on that specific Mac? Or users on the Mac?

This is important because, in my experience, trying to protect yourself from the user is a mug’s game [2], while trying to protect yourself from bad actors on the network does not require any SE shenanigans.

Also, does the presence of this “remote management server” indicate that the Mac is managed? Or do you want to support both managed and unmanaged Macs?

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

[1] Well, your keys. There are internal keys stored in the SE.

[2] It’s basically creating a DRM system, which all the negative consequences that entails.

0