Skip to main content
The palyra-identity crate provides the security foundation for the Palyra ecosystem. It manages a private Certificate Authority (CA) for the daemon, handles the device pairing handshake (PIN/QR), and enforces mutual TLS (mTLS) for all transport layers, including gRPC and QUIC.

Certificate Authority (CA) Management

Every Palyra daemon instance initializes its own internal Root CA upon first boot. This CA is used to issue short-lived leaf certificates to the daemon itself (server-side) and to paired devices (client-side).

Implementation Details

Sources: crates/palyra-identity/src/ca.rs#1-173, crates/palyra-identity/src/lib.rs#1-50

Device Pairing Handshake

Palyra uses a multi-step cryptographic handshake to pair new devices (CLI, Web, or Mobile) without pre-shared long-lived keys.

The Handshake Process

  1. Start Session: The daemon creates an ActivePairingSession containing a challenge and an ephemeral X25519 public key crates/palyra-identity/src/pairing/handshake.rs#27-52.
  2. Device Hello: The client generates its own DeviceIdentity (Ed25519) and responds with a DevicePairingHello crates/palyra-identity/src/pairing/handshake.rs#111-118.
  3. Proof Validation: The daemon verifies the proof (e.g., a 6-digit PIN or QR secret) in constant time crates/palyra-identity/src/pairing/handshake.rs#180-183.
  4. Signature Verification: The client must sign the transcript (including the session challenge and its own public key) to prove possession of the private key crates/palyra-identity/src/pairing/handshake.rs#190-205.

Pairing Flow Diagram

The following diagram maps the logical handshake to the internal IdentityManager methods. Title: Device Pairing Sequence Sources: crates/palyra-identity/src/pairing/handshake.rs#83-148, crates/palyra-cli/src/commands/pairing.rs#159-185

Transport Security (mTLS & QUIC)

Palyra enforces mTLS across all non-public interfaces. This ensures that only devices with a certificate signed by the daemon’s internal CA can communicate with the gRPC or QUIC gateways.

mTLS Configuration

QUIC Transport

The quic_runtime handles low-latency, encrypted streams using the palyra-transport-quic crate. Title: QUIC Transport Identity Mapping Sources: crates/palyra-daemon/src/quic_runtime.rs#1-80, crates/palyra-transport-quic/src/lib.rs#1-40

Persistence & Revocation

The IdentityManager manages the lifecycle of paired devices, including certificate rotation and revocation.

Secret Storage

Identity materials are stored in a SecretStore. The FilesystemSecretStore implements encryption-at-rest:

Revocation

When a device is removed or a certificate is rotated:
  1. The device ID is added to revoked_devices crates/palyra-identity/src/pairing/handshake.rs#158-160.
  2. The certificate fingerprint is added to the revoked_certificate_fingerprints list crates/palyra-identity/tests/mtls_pairing_flow.rs#161-163.
  3. The MemoryRevocationIndex is updated, causing existing mTLS connections to be rejected upon reconnection crates/palyra-identity/tests/mtls_pairing_flow.rs#137-143.
EntityCode ReferenceResponsibility
IdentityManagercrates/palyra-identity/src/lib.rsOrchestrates CA, pairing, and store.
SecretStorecrates/palyra-identity/src/store.rsAbstract interface for encrypted persistence.
DeviceIdentitycrates/palyra-identity/src/device.rsRepresentation of a client’s public/private keys.
PairingCommandcrates/palyra-cli/src/commands/pairing.rsCLI interface for managing pairing codes.
Sources: crates/palyra-identity/src/store.rs#87-115, crates/palyra-identity/src/pairing/handshake.rs#150-185, crates/palyra-cli/src/commands/pairing.rs#7-145