Pairing security¶
RG pairs a device to a cluster with no pre-shared secret. Pairing combines a short-lived, operator-visible code with a fresh asymmetric key the device generates itself. The code is useless without an operator's explicit approval, the private key never leaves the device and becomes its permanent trust anchor, and per-serial lockouts and rate limits defeat brute force and enumeration.
Pairing without a pre-shared secret¶
Traditional onboarding ships a shared secret — a password, a token, a certificate — that must be provisioned, protected, and rotated, and that leaks trust the moment it is exposed. RG avoids pre-shared secrets entirely. When a device begins pairing, it generates a fresh asymmetric key pair on the device and presents a short-lived code for an operator to see. Identity is established by the operator approving that code and by the device proving control of its new private key — not by any secret configured in advance. Nothing that grants trust is transmitted to the device beforehand, so there is no provisioning secret to intercept or reuse.
The operator-visible code and explicit approval¶
The human step is a short-lived code that the operator sees and confirms during pairing. The code's only job is to bind a specific pairing attempt to a deliberate operator action; it grants nothing on its own. Without explicit operator approval, a valid-looking code produces no trust and no credential — approval is mandatory, not implied by possession of the code. Because the code is short-lived, a code observed or guessed later is already expired, and because approval is a separate deliberate act, an unattended pairing attempt cannot complete itself. This keeps the decision to admit a device with a person, at a known moment.
The device-generated key as trust anchor¶
The private key the device generates during pairing never leaves the device and becomes the permanent anchor of its identity. From then on, the device authenticates to its cluster by proving possession of that key, and the same identity is valid only on that one cluster. Because the key is generated locally and never transmitted, there is no moment at which it crosses the network to be intercepted, and no shared copy exists to be stolen from a server. Rotating or revoking a device's trust is a matter of acting on that identity at the cluster; the anchor itself stays sealed on the device that made it.
Defenses against brute force and enumeration¶
Pairing is rate-limited and protected by per-serial lockouts, so repeated failed attempts against a given device identity are throttled and then locked rather than allowed to continue indefinitely. This blunts brute-force attempts to guess a code and enumeration attempts to discover which device identities exist, since probing does not yield a fast or unlimited signal. Combined with short-lived codes and mandatory operator approval, the practical attack surface during onboarding is small: an attacker must defeat a timing window, a human approval, and a lockout simultaneously.
Atomic delivery of the credential bundle¶
Once an operator approves, the cluster delivers the device's credential bundle atomically — the device either receives a complete, usable set of credentials or it receives nothing and retries. There is no partial state in which a device holds half of what it needs and is stuck. Atomic delivery matters on the same intermittent links that shape the rest of the platform: a connection that drops mid-delivery leaves the device cleanly un-provisioned rather than half-provisioned, so a retry starts from a known state. The result is a pairing outcome that is either fully complete or safely absent.