feat(openclaw): Ed25519 device auth for full scoped gateway access

[Steven17D]

Summary

• Adds Ed25519 device identity and pairing flow for OpenClaw gateway authentication
• New agent-deck openclaw pair command for device registration
• Replaces simple password auth with scoped token-based auth using device keypairs
• Stores device tokens locally for persistent authentication

Test plan

• Run agent-deck openclaw pair, verify device identity is created
• Test agent-deck openclaw pair --id shows device ID
• Verify gateway connection with device auth after pairing
• Test re-pairing and token refresh flows

🤖 Generated with Claude Code

[asheshgoplani]

The Ed25519 device auth concept is sound, but there are security issues that need attention before this can ship.

Critical:

1. Password in both Token AND Password fields. sendConnect() sets Auth.Token = c.password and Auth.Password = c.password. This doubles the credential surface in the wire payload. The Token field is semantically different (JWT-style); sending the raw password there may cause the server to attempt two auth paths and leaks the password into a field that may be logged differently server-side. Remove one.

2. Device token never becomes the primary credential. The signed payload in BuildDeviceConnect() is bound to the shared gateway secret (authToken = c.password). Even after pairing and receiving a deviceToken, the handshake is still authenticated by the long-lived shared password. Revoking/rotating the device token doesn't de-privilege the client. For "Ed25519 device auth," the device key should be the primary credential after pairing, not a supplement to the shared secret.

3. LoadOrCreateIdentity fails open on corrupt state. If deriveDeviceID fails, derived is the zero value, but the code writes id.DeviceID = derived and continues. Corruption/tampering of device.json should stop the flow and return an error, not silently "heal" into an invalid identity.

Important:

4. Private key stored as plaintext JSON. PrivateKeyPEM is written directly to ~/.agent-deck/openclaw/device.json with no encryption. Consider OS keychain integration or at minimum document this prominently.

5. Non-atomic file writes. os.WriteFile truncates and rewrites in place. If killed mid-write, the identity file is corrupted. Use write-to-temp + os.Rename() for atomic writes.

6. Server nonce not validated. waitForChallenge() passes the nonce directly to BuildDeviceConnect() with no length/format check. A malicious gateway could supply an empty nonce enabling signature replay. Reject nonces shorter than 16 bytes.

7. No token expiry. DeviceTokenRef has UpdatedAtMs but no ExpiresAtMs. Tokens are stored indefinitely.

8. No test coverage for device auth paths. Existing tests only cover password auth.

The cryptographic primitives are correctly chosen (Ed25519, SHA256, PKCS8/PKIX PEM). The issues are in credential handling and state management.

[asheshgoplani]

Checking back on this, @Steven17D. The 8 security and quality issues from the previous review remain unaddressed, and no follow-up commits have been pushed.

Please revisit the earlier review comments and push updates. Happy to re-review once those items are addressed.

[asheshgoplani]

Closing: 8 security/quality issues remain unaddressed (plaintext keys, missing nonce validation, no tests, etc). The OpenClaw device auth concept needs upstream coordination. Feel free to resubmit when the gateway side is ready. Thanks @Steven17D!