BetterKey is built around a simple rule: access to your car should be protected with the same care as access to your home.
That care shows up in the small moments. Signing in. Saving your session. Sending a lock or unlock request. Handling problems when something does not work the first time.
These are standard protections: Apple sign-in, Keychain storage, HTTPS, OAuth consent, encrypted tokens, verified webhooks, and careful logging. Here is how BetterKey puts them to work.
If you’d rather skim the consumer-friendly version first, the BetterKey security overview covers the same ground in plain English.
You sign in with Apple#
BetterKey uses Sign in with Apple, so you do not create another password just for your car key app.
When you sign in, Apple gives BetterKey a short, signed token that proves who you are. The backend verifies that token against Apple’s public keys, checks that it was issued for the BetterKey app, and checks that it really came from Apple. If any of those checks fail, sign-in fails.
The app session that follows does not last forever. If it expires, looks wrong, or cannot be refreshed, BetterKey asks you to sign in again. That may be a little less convenient in rare cases, but it is the right tradeoff. If BetterKey is unsure, it stops and asks you to prove it is really you.
Your session is stored in the iOS Keychain#
On iPhone and Apple Watch, BetterKey stores your app session in the iOS Keychain, the same protected system store Apple uses for passwords and passkeys. Items are released only after the device has been unlocked at least once since boot.
BetterKey also handles reinstalling carefully. The iOS Keychain can outlive an app uninstall. To avoid quietly reusing an old session on a fresh install, BetterKey pairs each Keychain item with an install marker in ordinary app settings. App settings are wiped by iOS on uninstall, so when the marker is missing on first launch, BetterKey treats the install as fresh and clears the matching Keychain entry before using it.
In plain English:
- Your phone’s built-in protections help guard the session
- Signing out removes the local session
- Reinstalling the app does not quietly reuse an old session
App traffic is private in production#
Production and beta versions of BetterKey use HTTPS for every request to our servers. App Transport Security, Apple’s network security policy, is left at its strict defaults so the system refuses any plain HTTP request the app might accidentally make.
Developers can use local connections while testing on their own machines, but real app builds use encrypted network traffic.
Smartcar handles automaker sign-in#
For production vehicle connections, BetterKey uses Smartcar. BetterKey does not ask for or store your automaker username or password.
Instead, you connect your vehicle through Smartcar’s OAuth 2.0 consent flow. You choose your vehicle brand, sign in with the automaker through Smartcar, review the requested permissions, and approve the connection.
BetterKey receives the authorization needed to send the commands you approve, not your automaker password. You stay in control of that connection, and vehicle owners can revoke consent.
Smartcar is a vehicle API platform built for connected-car access. Smartcar states that it requires HTTPS, encrypts stored data, and is SOC 2 Type 2, ISO 27001, ISO 27701, and GDPR compliant. Smartcar also says it is not a vehicle data marketplace, does not sell identifiable or anonymized vehicle data, does not build historical vehicle records, and runs annual penetration testing and a vulnerability disclosure program.
Vehicle authorization is encrypted at rest#
To keep your vehicle connected, BetterKey stores the authorization tokens Smartcar provides after you approve access. Those tokens are not your automaker password, but they are still sensitive, so BetterKey treats them that way.
Each token set is encrypted with AES-256-GCM, a widely used authenticated encryption standard. Every encryption uses a fresh random nonce. Each encrypted record is tagged with the key version it was sealed with, so keys can be rotated over time without losing access to anything written under an older key.
If the encryption setup is missing or wrong, BetterKey does not fall back to storing or reading plain text authorization. It fails closed.
The app does not get secrets it does not need#
Once your vehicle connection is set up, the mobile app does not need sensitive authorization data just to show your vehicles. The backend keeps those tokens and uses them only to talk to Smartcar on your behalf.
The vehicle list the app receives leaves the authorization fields empty, so there is less to leak from a phone or a network trace.
Webhook events are verified before they are trusted#
When Smartcar sends BetterKey an event about your vehicle, that event is signed with a shared secret using HMAC-SHA256. BetterKey computes the expected signature itself and compares it to the one Smartcar sent using a constant-time comparison, which avoids leaking information through timing.
If the signatures do not match, the event is rejected before BetterKey processes it.
One vehicle command at a time#
Phones and cell networks occasionally retry, and tapping a button twice should not turn into two trips out to the car. The backend derives an operation key from the authenticated user and the target vehicle, and a transactional guard allows only one command per vehicle to be in flight at a time.
If a duplicate request arrives while the first one is still working, the backend rejects it with a conflict response and a hint about when to try again. Repeated taps and flaky connections do not turn into surprise commands at the car.
Logs are kept boring on purpose#
Logs are useful when diagnosing a failed sign-in or vehicle command. They are also a place where sensitive data should not end up.
BetterKey logs the kind of information needed to diagnose problems, things like token lengths, success and failure states, and step names, without writing token contents, passwords, or authorization details into logs.
Testing-only tools are also kept out of production. The shortcut that skips token verification during simulator development is off by default and is not enabled in the production or staging environments.
The shape of it#
None of these protections do everything on their own. They are layered so that any one of them failing still leaves the others in place.
In the places that matter, BetterKey uses well-known building blocks: Sign in with Apple verified against Apple’s published keys, sessions stored in the iOS Keychain with install-scoped clearing, HTTPS-only production traffic under App Transport Security, Smartcar’s OAuth 2.0 consent flow, AES-256-GCM encryption with key versioning for stored authorization, HMAC-SHA256 verification for incoming webhook events, one-command-at-a-time vehicle control, and logs that avoid carrying secrets.
These are the things BetterKey does today. We expect to keep refining them.
For the consumer-friendly summary, head over to the BetterKey security overview.
Try BetterKey free for 1 week.