What it actually takes to send a signed command to a Tesla
A from-the-implementation look at Tesla's Vehicle Command Protocol — the ECDH handshake, HMAC-SHA256 signing, and replay-protection counter that stand between an API call and your car's windows actually moving.
Tesla stopped trusting bearer tokens for vehicle control
Older Tesla integrations could send a command with nothing more than a valid OAuth access token — if you had the token, the car would do what you asked. Tesla's Vehicle Command Protocol replaced that model for anything that actually moves the car (locks, windows, climate, trunk) with cryptographic signing: every command has to be signed by a private key the car has separately verified belongs to you, not just authorized by a token that proves you logged in once.
The practical effect is that a leaked access token alone can no longer be used to move a Tesla. An attacker would also need the private signing key, which — done correctly — never leaves the server that generates commands.
The handshake: ECDH before anything else
Before the first signed command, the client and vehicle perform an Elliptic-Curve Diffie-Hellman key exchange. Each side has a key pair; they exchange public keys and each independently derives the same shared secret without ever transmitting it. That shared secret seeds a session — every command signed under that session uses key material derived from it, not the long-term private key directly.
This is also the step most integrations get wrong in production: sessions expire and can be invalidated by the vehicle (a firmware update, a long idle period, the car simply forgetting). A correct implementation treats 'no session' or 'stale session' as an expected state, not an error — it re-establishes the handshake automatically and retries the command once, rather than surfacing a confusing failure to the end user.
Signing: HMAC-SHA256 over the actual command
Once a session exists, each command is signed with HMAC-SHA256 using key material from that session. The signature covers the command payload itself, so a signed 'vent windows' message can't be silently altered in transit into a different command — the vehicle would reject a tampered payload because the signature no longer matches.
Replay protection: a counter, not a timestamp
The protocol includes a per-command, monotonically incrementing counter tied to the session. The vehicle tracks the last counter value it accepted and rejects anything at or below it. That means a captured, valid, correctly-signed command can't simply be replayed later to repeat the action — the counter it was signed with is already spent. This is a stronger guarantee than a timestamp-based scheme, which has to account for clock skew and replay windows; a counter has neither.
Why this matters if you're building on the Fleet API
If you're implementing this yourself: budget real engineering time for session lifecycle management, not just the happy-path signing code. The signing math (ECDH + HMAC) is a solved problem with libraries to help. The part that actually breaks in production is session state — knowing when to re-handshake, doing it without user-visible failures, and making sure your counter bookkeeping survives a server restart. VentMode's implementation re-establishes the handshake and retries once on session errors specifically because 'the session just went stale' turned out to be the single most common transient failure in practice, not an edge case worth ignoring.