User guide

NeversKey comes as two applications, built from the same sources:

Each application has one main window: the object it is about, its state, and the actions of that state. Each action opens its own wizard; its Next button does the action, and the main window then shows the new state. The command line does the same things. Both run as a standard user: the few steps that change the administrator workstation ask for elevation themselves.

NeversKey Vault

The window draws the door of the vault. Its state decides what can be done.

Only the certificate of the vault is remembered, with the folder of its backups. The key itself is only ever in memory, while the vault is open. The status line says how long ago the backups were last tested (in amber after 90 days or when never) and how many NeversKeys were issued.

Create a vault

Name, key (RSA 3072 or 4096) and validity. The root key is generated and stays in memory: the vault is open, not backed up yet, and the window says so until it is.

Back up

• A page to print (QR code): one QR code that alone restores the key and its certificate, reloaded and checked before anything is written. Passphrase: 12 characters or more, asked again whenever the vault is opened. It can be left empty: the page is then the key itself, protected only by the safe it is kept in. Also keep it as files: an encrypted key file and the text of the QR code, for offline media.
• Shares among custodians: Shamir shares, one page per custodian: any k of them rebuild the key, fewer reveal nothing. Each custodian may protect their share with their own passphrase.

The folder also receives the certificate of the vault (.cer, public) and the issuance log. Backing up again does not revoke the earlier backups: it is one more copy to keep safe.

Open the vault, test the backups, check my share

The vault opens from the printed page (photo, scan, or the camera), enough shares, the key file or the QR text. Test the backups opens a backup, checks it and erases the key again; the test goes to the issuance log. With Check my share a custodian checks their own share alone: it opens with their passphrase and belongs to this vault, without rebuilding the key.

Issue a NeversKey, answer a request

A NeversKey is a certificate of the vault for a local account (default Administrator), valid a few hours (8 by default, 72 at most). Every one issued goes to the issuance log.

• A USB key plugged in here: it becomes an EIDVirtual smart card, its key generated on the card and used without PIN. Until it expires, the USB key is a bearer token, to be kept like the key to the server room.
• The request of a workstation, and the code its administrator reads out by phone. A request for a USB key gets the card sealed for that workstation and account. A request for a key of a TPM or a PIV card gets its certificate: nothing secret travels.

Export the certificate writes the .cer the administrator workstations work with.

NeversKey, on the administrator workstation

The top line names the vault this workstation works with. A certificate loaded is shown before it is used: trust it only if its thumbprint is the one printed on the backup page of the vault. When this PC does not trust the vault yet, an amber band says so and Fix (admin) makes only those changes, elevated.

The window draws what carries the NeversKey, found by itself: a key inserted (YubiKey or other PIV card, USB key) comes first, else the TPM of this PC. Its badge gives the state: key generated, request waiting, valid, expired.

Prepare the machines

• Deployment script, run once per machine as SYSTEM with your usual tool (Intune remediation or platform script, GPO startup script, ConfigMgr). It puts the root in Local Cert Issuer (not in the trusted roots: it is only trusted for PKU2U logons), enables the local identity provider, PKU2U online identities and Restricted Admin mode, and creates the certificate of the machine, without CA rights, pinned in Local Cert Issuer. It is idempotent and renews the certificate 30 days before it expires. Nothing needs to come back: there is no machine list.
• Machine audit: run the audit script on the machines (it changes nothing and prints one line), then point NeversKey at the lines you get back for an HTML report, the machines that cannot be recovered first. Any other certificate in Local Cert Issuer is a security finding: every CA there can issue logons.
• Check this PC: the audit script on this PC.
• Export the settings as .reg: the deployment settings alone, for a GPO registry preference.

The NeversKey on a USB key: EIDVirtual

The card arrives sealed for this workstation and this Windows account, once. Install EIDVirtual first when its reader is missing (it includes the PIV mode and the minidriver that lets Windows use the card key without PIN, as PKU2U requires). Then Request a NeversKey, read the code out by phone, and Install the response.

The NeversKey in a TPM or on a PIV card (YubiKey)

1. Generate the key: in the TPM (not exportable, no PIN), or in slot 9E of the PIV card.
2. Request the certificate: the request holds the public key only. Send it to the vault and read its code out by phone: the code is the fingerprint of the request, so the vault signs this key and no other.
3. Install the certificate the vault sends back: it is checked against the vault and against the key, then bound to it.

Once the NeversKey is valid

• Add a machine, once per machine: NeversKey starts a PKU2U exchange with it over Remote Desktop (or WinRM), reads the certificate the machine presents and checks that it signed the reply. It shows the certificate and pins it only once you trust it, compared with the audit report: the same SHA-256 thumbprint says it is the certificate of the machine; a different one is refused, a machine in the middle may be answering.
• Connect: NeversKey checks that the key signs without PIN, saves it as the Windows credential for the machine, checks that PKU2U can start an exchange, and opens mstsc /restrictedadmin.
• End the crisis: the NeversKey is deleted (the TPM key, slot 9E emptied, or the card of the USB key), and every change of the connections is undone.

PowerShell remoting during a crisis

A machine added and connected once holds a saved credential, which a remote command uses too: the machines must accept WinRM, the workstation must trust their names (WSMan:\localhost\Client\TrustedHosts, there is no Kerberos), and the break-glass account should be the built-in Administrator (managed by Windows LAPS), as other local accounts get a filtered token over the network. Then Invoke-Command -ComputerName <machine> -FilePath .\fix.ps1, without -Credential.

Elevation

Everything else (the vault, backups, scripts, audit report, the NeversKey, the credentials of Connect) runs as a standard user.

Command line

# NeversKey Vault: the vault, offline
NeversKeyVault init --name "Contoso Rescue Root" --out E:\ceremony
NeversKeyVault split --qr-image photo.jpg --threshold 3 --count 5 --out shares --passphrases
NeversKeyVault verify-backup --qr-image photo.jpg --out root.cer
NeversKeyVault issue --qr --drive E: --account nkrescue --hours 8
NeversKeyVault issue --qr --request card.nkreq --code 1A2B-3C4D-5E6F-7081 --out card.nkcard

# NeversKey: deployment and audit
NeversKey export-scripts --cert root.cer --out scripts --account nkrescue
NeversKey export-deploy --cert root.cer --out deploy.reg
NeversKey audit --cert root.cer --in reports --out audit.html

# NeversKey: crisis
NeversKey request --out card.nkreq
NeversKey install --response card.nkcard --cert root.cer --drive E:
NeversKey retrieve-server-cert --cert root.cer --target SRV01
NeversKey connect --cert root.cer --target SRV01
NeversKey connect --cleanup