Escrow Validation

Fundamentally, two client-side processes are running: the checkin functionality written in python (versions after 4.1 use golang) and the main login window 'plugin' written in Swift (which is also referred to as an authentication mechanism/Security Agent Plugin). To clarify what is possible when configured correctly in the preferences, the login window code at its most basic checks if FileVault is on by 'shelling out' to /usr/bin/fdesetup status to know if it should take action. The checkin code can do all handling thereafter, including initiating rotation based on if the server has granted approval access to the stored key.

Same as when you initiate FileVault via MDM and store it elsewhere, neither of the two client-side processes take a stored key, on the server or local, to confirm that fdesetup or (for example) macOS Recovery would accept it as valid working authentication.

The Crypt Server does provide an (unauthenticated by default) API endpoint that can at a minimum return a boolean as confirmation that a secret of the type 'recovery_key' was escrowed, along with the timestamp when it was initially stored on the server. (Subsequent escrows of the same key create a logged "Last Checked In" 'heartbeat', but does not increment that returned timestamp.) While it remains important (depending on your hosting) to use network boundaries or in order to prevent resource exhaustion of the server, one could validate a computer by sending a GET curl request to the server with this example path:

curl -fsSL "https://crypt.url/verify/<SERIALNUMBER>/recovery_key"

To which it should reply with a response like this:

{"escrowed": true, "date_escrowed": "2024-04-14T17:00:46.941Z"}