Setting up the policy engine
The policy engine is the whole point of TeslaKee. The official phone key answers your car whenever the car asks — which is why a relay attacker can stand next to your car, have an accomplice stand next to you, and drive away. TeslaKee’s key only answers when your own rules say the situation looks like you actually walking up to your car.
This page explains how those rules combine, what each one really measures, and which combinations work in daily life. Everything here is on the Policy screen in the Android app.
How a decision is made
Every time the car asks for authorization, the engine evaluates your configured rules and produces one answer: allowed or blocked.
Passive entry is allowed when:
all REQUIRED rules pass and at least N OPTIONAL rules pass, where N is the quorum you set.
If you have no optional rules configured, the quorum is ignored. If you have no rules configured at all, the engine blocks — an empty policy is not an open door.
A few things sit outside this evaluation and are checked first, in this order:
- Kill switch — blocks everything, always. See Kill switch.
- Reconnect grace — a briefly dropped, previously authorized link stays authorized. See Sticky connection.
- Sticky connection — once allowed during a connection, stays allowed until the link drops.
- Manual override — allows everything for a few minutes. See Manual override.
- Always-On — allows everything, permanently. See Always-On.
Rules are evaluated cheapest-first, and a rule whose result can no longer change the outcome is skipped. That is a battery optimisation only: the allow/block answer is identical to evaluating every rule.
REQUIRED, OPTIONAL and OFF
Each rule carries one of three levels. This is the mechanism worth understanding, because it is where security and convenience are traded against each other.
| Level | Meaning | Effect of failing |
|---|---|---|
| REQUIRED | A hard condition. | The car stays locked, no matter what else passes. |
| OPTIONAL | Evidence that counts towards the quorum. | Nothing on its own — other optional rules can make up for it. |
| OFF | Not evaluated at all. | — |
Think of it this way: REQUIRED rules are an AND, OPTIONAL rules are a vote.
- Use REQUIRED for conditions that are always true when you are genuinely walking up to your car — and never true for an attacker. Motion is the classic one: your phone is in your hand or pocket and it has moved recently.
- Use OPTIONAL for good evidence that is occasionally unavailable: GPS indoors, a barometer that drifts, a cell tower that hands over. Any single one failing should not lock you out.
- Use OFF for anything that does not apply to you.
A rule that is REQUIRED and cannot be evaluated (no sensor, no permission, no baseline) fails, and therefore blocks. That is deliberate — an unmeasurable condition is not a satisfied condition. It is also the single most common reason for “the app won’t unlock my car”: see Troubleshooting.
The quorum
The quorum is the number of optional rules that must pass — “at least 2 of these 4”.
- A low quorum (1) means any one piece of evidence is enough. Convenient, weak.
- A high quorum (equal to the number of optional rules) turns them all into REQUIRED rules in practice. Strong, brittle.
- The useful setting is usually 2 of 3 or 2 of 4: an attacker has to fake several independent things at once, while one flaky sensor never locks you out.
The quorum only ever applies to rules set to OPTIONAL. Raising it above the number of optional rules you actually have would block everything, so the app clamps it for you.
Security profiles
The three profiles at the top of the Policy screen configure every rule and threshold below them in one tap. They are a starting point, not a cage — change anything afterwards and the profile simply shows as custom.
| Casual | Balanced | Strict | |
|---|---|---|---|
| Motion | optional | required | required |
| BLE signal | off | optional | required |
| Phone unlocked | off | optional | required |
| Parking spot | off | optional | optional |
| Steps | off | off | optional |
| Altitude | off | off | optional |
| Quorum | 1 | 2 | 3 |
| Motion window | 15 min | 5 min | 2 min |
| Signal floor | −90 dBm | −80 dBm | −70 dBm |
| Steps | 5 in 15 min | 10 in 5 min | 25 in 2 min |
| Altitude tolerance | 30 m | 15 m | 5 m |
| Phone unlocked within | 10 min | 2 min | 1 min |
Balanced is the right choice for most people. Strict assumes you always have your phone unlocked recently and are close to the car; it is excellent protection and will occasionally make you pull the handle twice. Casual is barely more than the stock key — use it only if you park somewhere you consider safe.
Testing your policy
The Policy Test panel on the same screen evaluates every rule live, including the ones you have switched off, and shows what each one currently reports. It also lists which motion sensors your phone actually has and whether they are firing.
Use it like this: stand where you normally park, open the panel, and read the rules you are considering. A rule that already fails while you are standing next to your own car is a rule that will lock you out — make it OPTIONAL or leave it OFF.
The rules
Motion
Passes when the phone is moving, or moved within the last window (2 / 5 / 15 minutes, adjustable 1–60).
This is the anti-relay workhorse and the only rule that is REQUIRED by default. A relay attack happens while your phone is lying on a table, in a hallway, on a nightstand — motionless. A phone that has not moved in ten minutes is not walking up to a car.
- Shorter window = stronger. 2 minutes means “you were moving essentially now”.
- Longer window = friendlier if you sit in a café near your parked car.
- Needs the accelerometer, and on GrapheneOS/CalyxOS the Sensors permission. Without it the rule fails permanently and blocks everything.
Geofence
Passes when the phone is inside one of the zones you drew on the map. (Premium)
Use it to say “only allow entry near home, work, and the gym”. Because it needs a GPS fix, it is one of the two battery-expensive rules and can be slow or unavailable in underground garages. Excellent as OPTIONAL, risky as REQUIRED — an underground car park is exactly where GPS is worst and where you still want your door to open.
Parking spot
Passes when the phone is within a radius (default 50 m) of the place where the car was last locked. (Premium)
This is the sharpest of the location rules, because it needs no setup: TeslaKee records where you parked and only unlocks near that spot. A relay attacker standing at your car while you are at home fails it instantly — and so does a thief who has towed the car away.
Like the geofence, it needs GPS and inherits GPS’s weaknesses indoors. OPTIONAL is the right level for most people.
Trusted Wi-Fi
Passes when the phone is connected to one of your trusted networks.
Cheap, instant and reliable — but it only proves you are at home or at the office, not that you are at the car. Good as one voice in the quorum: “phone is on the home network and has moved recently” is much stronger than either alone. Never make it REQUIRED unless your car is always parked within Wi-Fi range.
Time of day
Passes when the current time falls inside an active window you define.
Most useful for the reverse case: blocking the night hours, when the majority of relay thefts happen and you are certainly not driving. If you work irregular shifts, keep this OPTIONAL or OFF.
BLE signal strength
Passes when the vehicle’s radio signal is at or above the floor you set (−70 / −80 / −90 dBm, adjustable −100…−40).
Relayed signals are re-broadcast, so they often arrive weaker than a real one — and a real approach gets steadily stronger as you close the last few metres. Setting a floor turns “the car can hear me” into “the car can hear me from close by”.
- −70 dBm ≈ standing at the car. Strong, and occasionally strict enough to need a second try with the phone in a back pocket.
- −80 dBm ≈ a few metres away. The default and a good compromise.
- −90 dBm ≈ anywhere in the parking area.
Once the rule passes, the signal has to sag a full 8 dB below the floor before it flips back to failing. That hysteresis stops the decision from flapping while you walk up.
Steps
Passes when the step counter registers at least N steps in the last M minutes (5/15, 10/5, 25/2 presets).
Stronger than plain motion: a phone on a moving train or on a vibrating desk registers motion, but not steps. This is genuinely “a human carried this phone here”. It needs the step-detector sensor and, on Android, the Physical activity permission. Verify it in Policy Test before making it REQUIRED — some phones report steps with a delay of a minute or more.
Altitude
Passes when the barometric altitude is within a tolerance (5 / 15 / 30 m) of the altitude recorded when the car was last locked.
The rule that catches the multi-storey attack: your car is in the underground garage, you are on the 14th floor, and every other signal — cell, Wi-Fi, even GPS — says you are “at home”. Air pressure does not agree.
Needs a barometer (many mid-range phones have none; the app tells you) and a parking-spot baseline. Weather changes air pressure over hours, so a very tight tolerance can drift out overnight. 15 m is a good compromise; keep it OPTIONAL.
Phone unlocked
Passes when the phone screen was unlocked just now, or within the last N minutes (1 / 2 / 10; 0 = “must be unlocked right now”).
Very strong evidence, because a relay attack works on a phone in your pocket and a thief has no way to make you unlock it. The cost is that you must touch your phone before touching the car door — which is what many people do anyway.
Set it to 0 only if you are willing to reach for your phone every single time.
Cell towers
Passes when the phone currently sees one of the cell IDs you added to the allow-list.
The “am I in the right part of town” rule, with none of GPS’s power draw and much better indoor coverage. Build the list with the Add current button while standing where you park. Coarse by nature — a cell covers a lot of ground — so it is a supporting voice, not a proof of proximity.
Parking-spot cell towers
Passes when at least one of the cells visible now was also visible when the car was last locked.
Same idea as the parking spot rule, but using the cellular radio instead of GPS: it works underground, needs no setup, and re-baselines itself every time you park. The snapshot usually holds several serving and neighbouring cells, so it survives a handover. A very good OPTIONAL rule — arguably the best value of all of them for people who park in garages.
Overrides and safety valves
Manual override
Grants entry for a set number of minutes (default 5, up to 120), regardless of every rule. It exists for the moments the policy is right in general and wrong right now: handing the car to someone, loading the boot with the phone left inside, a sensor that has clearly gone wrong.
Start it from the Home screen. It expires on its own — that is the point.
Always-On
Disables the entire policy engine. Your key then behaves like the official one, which means relay attacks work again. The app asks you to confirm and keeps a red warning on screen the whole time it is active.
There is one legitimate use: diagnosing whether a problem is caused by policy at all. Turn it on, confirm the car opens, turn it off again.
Kill switch
The opposite extreme, and it beats everything — including override and Always-On. With the kill switch active, TeslaKee does not scan, does not answer the car, and is indistinguishable from an uninstalled app as far as the vehicle is concerned. Use it when you hand your phone away, or when you park somewhere for a longer period and want no BLE key on that phone at all. It is instantly reversible.
Sticky connection and reconnect grace
Once passive entry has been allowed during a Bluetooth connection, it stays allowed until that connection ends. Without this, a brief dip — a signal sag, a missed sensor poll — could pull authorization while you are sitting in the car.
The reconnect grace (default 60 s, adjustable 0–600 s in Settings) extends the same idea across a short dropout: if an already-authorized link drops and comes back within the window, entry stays authorized instead of re-running every rule. Set it to 0 if you want every reconnection to re-pass the full policy.
Setups that work
Everyday, garage at home — Motion REQUIRED · quorum 2 of: parking-spot cells, phone unlocked, BLE signal. Works underground, survives a dead barometer, and refuses to answer while your phone is on the kitchen table.
Street parking in a city — Motion REQUIRED, BLE signal REQUIRED (−80) · quorum 2 of: steps, phone unlocked, parking spot. Proximity has to be real, and something has to prove a human moved.
Maximum security — Motion, BLE signal (−70) and phone unlocked all REQUIRED · quorum 3 of: steps, parking spot, altitude, parking-spot cells. Expect to pull the handle twice occasionally. Combine with PIN-to-Drive in the car.
Apartment block with underground parking — Motion REQUIRED · quorum 2 of: altitude, parking-spot cells, phone unlocked. The altitude rule is doing the heavy lifting here: it is what separates “in the garage next to the car” from “asleep on the 14th floor”.
When the car won’t open
Open Policy Test first — it names the failing rule, and that is nearly always the answer. The usual suspects:
- A REQUIRED rule cannot be measured. No barometer, no step detector, Sensors permission denied, no parking-spot baseline yet, no GPS fix underground. Unmeasurable counts as failed. Move the rule to OPTIONAL.
- The quorum is higher than the evidence you can produce indoors. Lower it by one, or add one cheap optional rule (trusted Wi-Fi, parking-spot cells).
- BLE floor set too high. −70 dBm with the phone in a back pocket, against a metal-heavy car body, is genuinely tight. Try −80.
- Motion window too short. After sitting in a restaurant for an hour, a 2-minute window will not have seen motion until you stand up and walk.
- The official Tesla app is still a Bluetooth key. Then the car may be talking to it, not to TeslaKee — and no policy applies. See the Tesla app guide.
- Nothing at all happens. Check the kill switch is off, and check Settings → Background Reliability.
Still stuck? Write to contact@toothr.com with a screenshot of the Policy Test panel — it usually answers the question in one look.