This document outlines how the hub manages its signing key.
.env is loaded automatically at startup using python-dotenv.CAMMY_SECRET_KEY is missing, a new random key is generated and written to .env and cammy.secret.cammy.secret persists the key across restarts.CAMMY_SECRET_KEY via environment variables once a key has been persisted causes the hub to exit with an error..env and cammy.secret out of version control.For local testing the hub uses self-signed certificates generated with
mkcert and advertises itself over mDNS using avahi-publish. The
hostname comes from the CAMMY_NAME environment variable and defaults to a
unique value derived from the secret key. These files reside in the
certs/ directory as <CAMMY_NAME>.pem and <CAMMY_NAME>-key.pem. They should
not be committed.
CammyCam secures video streams by performing an ECDH key exchange when a camera
connects. Each stream is encrypted with AES in CTR mode, keeping frames private
between camera and viewer. Authentication relies on signed tokens and supports
distinct viewer, admin, and super roles so that only authorized users may
manage cameras or settings.
Wi-Fi credentials on the camera are also encrypted using AES‑CTR and protected by an HMAC tag to detect tampering. A secondary network or optional fallback access point ensures cameras remain reachable even if the primary connection fails.
Production deployments must provide CAMMY_ADMIN_USER and
CAMMY_ADMIN_PASSWORD. Default credentials require the explicit development
flag CAMMY_ALLOW_DEFAULT_ADMIN=true. Passwords are stored with bcrypt; legacy
SHA-256 hashes migrate after a successful login.
Password-reset requests use identical responses for existing and unknown users.
Short-lived tokens are written only to the configured CAMMY_RESET_TOKEN_FILE
handoff for out-of-band delivery and expire after 15 minutes.