Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Tesla credit card key - who's interested?

This site may earn commission on affiliate links.
I've had several cars with those and they've all sat in a drawer with the other extra keys. So my initial reaction was kind of "meh". The difference here is that I don't really need my Fob to lock and unlock the doors since it does it automatically... So in this scenario it might actually be something useful. So I've reconsidered... I think I'd like one too. :D
 
Last edited:
It sounds like the bluetooth idea would be both easier and not require any additional hardware (the key itself) by Tesla. In fact, they could do it as a software update.

It's a one-time thing. If it takes one minute, it's not a big deal. The system will soon have a valet mode with PIN (hopefully) so one could use that same preset PIN in order to pair any new device for key fob function.

It's not rocket science folks.
 
It sounds like the bluetooth idea would be both easier and not require any additional hardware (the key itself) by Tesla. In fact, they could do it as a software update.
Actually, a bluetooth system can be rather complicated. I’ll expound more below.

ABSOLUTELY NOT. First of all, all the hardware already exists both in mobile phones and the Tesla Model S, so there is ZERO hardware for Tesla to design/engineer. It's already done -- a Bluetooth solution would ONLY require a SOFTWARE solution.
Regarding hardware vs software - whether a bluetooth keyless entry and start system would require new hardware or not is secondary. Even if it was just software, it is a different system than what is currently used with the key fob. Thus, Tesla would need to design and engineer this system even if it was just software. And often software can be much more complex than hardware. Also, the system to enter and start your car should be super reliable and secure (I’ll expound more on this before) and shouldn’t be without bugs and this can be difficult.

Regarding hardware, you’re assuming that the Model S already has all the hardware necessary for a bluetooth keyless entry and start system. Currently the Model S probably has just one bluetooth antenna and that’s likely located inside the car. It’s probably geared toward just connecting a phone for bluetooth/audio controls. This is very different than the functionality of a bluetooth keyless entry and start system. A bluetooth keyless entry system might need multiple bluetooth antenna and they might need to be placed not in the center console but toward the corners of the car to detect approaching signals better.

Second, since the car already has a Bluetooth radio and interface built in, Tesla would just need to choose (or add) an additional EXISTING Bluetooth Profile (See: List of Bluetooth profiles - Wikipedia, the free encyclopedia ).. in this case, something like Proximity Profile (PXP) or OBject EXchange (OBEX) or any of the other profiles which may be more appropriate and a profile that the mobile phones already support (possibly one of the more generic ones, like Generic Access Profile (GAP), Generic Attribute Profile (GATT), Generic Object Exchange Profile (GOEP), etc. All it would require is an additional button on the mobile app (if this feature is enabled with a PIN on the car): "Start Model S". When you click it, it asks for a PIN, then the mobile phone contacts the Model S bluetooth stack, the PIN is confirmed or denied, and the car is started.


For a Bluetooth developer, this is *maybe* a one-day job, two at most if he sleeps at night. Then a few weeks of testing, etc. But I suspect something like this is pretty low on the priority list.
Alright, let’s take a deeper look into what a bluetooth keyless entry and start system would entail.

First, since it is a entry and start system, it needs to be super reliable. You don’t want people to be waiting an extra 1-2 seconds at the car while the bluetooth connection is being established before the door handles appear. This would defeat the whole purpose of the system.

Further, you don’t want an owner to be waiting in front of their car and the bluetooth connection to fail. And the owner needing to restart his smartphone and even worse, call Tesla ownership to troubleshoot just to get the door handles to appear.

The problem with bluetooth is that it’s a connection protocol, meant to transfer data. As with any connection protocol, a connection needs to be established between two devices. The challenge with this is most connection protocols aren’t perfect. Even if the bluetooth connection is successful 99.97% of the time, there’s still the 0.03% of the time that the connection might fail.

Now, imagine if 0.03% of the time the connection failed. That would mean 3 out of every 10,000 times it would fail. Surely the Model S is opened more than 10k times a day (probably 100k times) and that’s a lot of failed connections that would frustrate owners and clog up the Tesla ownership hotline with mad owners.

Even wifi isn’t the most reliable connection. Sometimes, my home/work/starbucks wifi connection gets interrupted or it doesn’t connect instantly and takes some time.

When you’re in front of your Model S you don’t want to wait for a connection and you don’t have the tolerance for even a second delay.

So the question is, is bluetooth going to provide the reliability of near 100% instant connection and response required to be an adequate keyless entry and start system. My suspicion is no.

Another problem with bluetooth is that it relies on the owner’s smartphone. There are a ton of smartphones, especially Android ones. And all of the phones have minor nuances. It’s a pain to develop for smartphones since there’s so many variables with so many phones, operating systems and versions. Believe it or not, but even the bluetooth systems on each of these phones could operate ever so slightly different and could cause connection problems. This is a technical support nightmare for Tesla, and it just increases the possibility of connection bugs, issues, and problems.

The point I’m making is for a keyless entry and start system, reliability is the number one issue and it should be pretty darn close to 100% reliable. If it’s not, then it’s not a viable solution. This is different than streaming audio in your car with bluetooth. If it doesn’t work right away, you’re frustrated but it doesn’t completely ruin your experience in the car. I’ve had quite a few times when I’ve experienced difficulty connecting with bluetooth devices via my phone (ie., car stereo, headset, etc). Theoretically bluetooth might sound great and it probably is for most people but since it’s a connection protocol and there’s so many devices out there, bluetooth is inevitably going to present it’s own set up bugs and issues.

Now, compare that with Tesla’s current key fob system (probably using a system of RF and LF antennas). It’s borrowing from the keyless entry systems of other cars that’s been proven to be reliable. And you’re dealing with only one key fob - not hundreds of different types of smartphones.

Now, I’m not saying bluetooth can’t be done successfully ever. Maybe some of the newer protocols could be used, but my point is that it’s going to take a lot of software engineering, testing, iteration, etc. And it’s not a simple process. It’s easy to get software to work 99% reliable, it’s that last 1% that’s extremely excruciating and difficult.

It's called two-factor authentication. One would need both parts to start the car-- the bluetooth phone (previously paired and known to the car) AND a PIN (or password or passphrase). Not Just a PIN code (or password or passphrase), and not just a phone.

Ok, now let’s take a look at the security angle.

Typically, pairing of phones usually require 4 digit pin (note: a 4 digit pin is a very weak password).

Let’s say you’re valeting your car, and the valet takes out his phone and pairs his phone with your car. Is he able now to enter and start your car with his phone? With typical bluetooth systems, that’s how pairing works and it’s scary to rely on that when dealing with a Model S.

So, if Tesla would need to design/engineer a new pairing system so that not anybody could pair their phone with your car. It doesn’t necessarily have to be a hardware solution, it could be software-only but nevertheless it might be quite complicated to code, build, and test… especially with the hundreds of smartphones out there.

Also, would it be possible for someone to copy/find/fish/steal your phone’s IMEI, serial #, ICCID, MEID or whatever else the bluetooth is relying on to identify your phone and then use that info to establish a connection to your car (ie., a valet person). And if the PIN is only 4 digits, then the passcode could be easy to guess/hack.

Now, no system is perfectly secure and it’s all about mitigating risk. The question is does a bluetooth entry and start system have more risk than let’s say a key fob. I think it does, unless there’s some majorly advanced programming/coding that somehow makes it much more secure than typical bluetooth pairing now (ie., just 4 digit PINs, etc).

Overall, I’m not saying that bluetooth, or NFC, or biometric, etc methods aren’t viable. What I’m saying is that these are different systems and would need a lot of effort, design, engineering (ie., even if it’s just software engineering) for Tesla to make them work well. And since it deals with entry and start, it’s a super important part of the car that they need to do well.

My hunch is that a new entry/start system won’t happen without new hardware installed into the car (ie., new antenna, etc) and it probably won’t be with bluetooth but maybe with another technology, and it won’t happen during the next few years.
 
Wow.. that's a ton of assumptions, "probably"'s and FUD. You sound like you know what you're talking about, but you qualify almost every statement with "probably" or "even ifs" or "can be"s or "imagine if"s. Just saying that it's difficult and complicated doesn't make it so.

Seems like hundreds of thousands of existing bluetooth devices have no problems connecting to each other, all sorts of phones, devices, whatever. They've solved that problem LONG AGO.

Bluetooth PINs can be much more than 4 digits, it's not a hard-limit. My BMWs require a 6 digit PIN. And you totally missed my point about using a pre-stored PIN before allowing just any phone to be paired to the car. Your "valet" scenario of pairing their phone to your car is just not possible without guessing a long PIN. 6 digits is 1 million combinations. Bluetooth pairing with a passcode is built into the bluetooth protocol.. it's nothing Tesla would have to build.

If someone is skilled enough to clone your phone's IMEI and several layers of hardware and firmware encryption, they'd be doing bigger things than stealing cars that can be 100% tracked and instantly disabled. You're talking about so few people who could actually do that, it's essentially zero.

Without spending an hour refuting every single one of your hypotheticals on top of hypotheticals, we'll just have to wait and see if/when Tesla enables a feature like this, with or without additional hardware. I say they can and it would pretty straightforward to do. No need to over complicate something so simple with hyperbole.
 
Wow.. that's a ton of assumptions, "probably"'s and FUD. You sound like you know what you're talking about, but you qualify almost every statement with "probably" or "even ifs" or "can be"s or "imagine if"s. Just saying that it's difficult and complicated doesn't make it so.
Hi Hank, I actually come from a software background. Often people tend to underestimate the complexity of software especially when it comes to reliability and security. Again, I’m not saying bluetooth isn’t possible… I’m just saying I think it will be extremely complicated to design, build, engineer and get right. It has to do with the final 0.01% of reliability with a part of the car where reliability is crucial. Also, I didn't just say it’s difficult and complicated, I gave plenty of examples and reasons regarding the difficulty and complexity. I’d appreciate it if you focused on the examples and my points rather than make generalizations.

Seems like hundreds of thousands of existing bluetooth devices have no problems connecting to each other, all sorts of phones, devices, whatever. They've solved that problem LONG AGO.
This is not true. Bluetooth devices have plenty of problems connecting and maintaining connections. To claim that there are “no problems” is not accurate. Just yesterday morning, I couldn’t connect my iPhone (already paired via bluetooth) to my Pioneer stereo in my other car. It took me several tries and 10 minutes to re-establish connection. Overall, bluetooth is a wonderful protocol and works well most of the time. My point is that a entry/start system for a car requires extreme reliability which I have my doubts that bluetooth can deliver in its current form.

Bluetooth PINs can be much more than 4 digits, it's not a hard-limit. My BMWs require a 6 digit PIN. And you totally missed my point about using a pre-stored PIN before allowing just any phone to be paired to the car. Your "valet" scenario of pairing their phone to your car is just not possible without guessing a long PIN. 6 digits is 1 million combinations. Bluetooth pairing with a passcode is built into the bluetooth protocol.. it's nothing Tesla would have to build.
If someone is skilled enough to clone your phone's IMEI and several layers of hardware and firmware encryption, they'd be doing bigger things than stealing cars that can be 100% tracked and instantly disabled. You're talking about so few people who could actually do that, it's essentially zero.

The pairing system is just one of the many parts of what would be required for a bluetooth keyless entry/start system. Also, 6 digits is not very secure at all, even though it’s 1 million combinations there are a variety ways to hack that rather quickly. Again, I’m not saying Tesla couldn’t design/engineer their own solution, I’m just saying it’s going to take plenty of effort and far from your assumption of a few days engineering time.

With regards to grabbing some phones IMEI, it can be quite simple as picking up the phone (ie., if phone is accidentally left in car at valet) and reading/copying the IMEI number.

I’m not saying any hacking situation is likely, but in software development it’s not just preventing the “likely” but also preparing and preventing the “unlikely” as well. Part of preparing and preventing for the “unlikely” is to identify possible unlikely scenarios and identify their impact. In terms of a keyless entry/start system, in the unlikely event of a hack it could cause major anxiety with Tesla owners and a huge publicity event for Tesla naysayers. In other words, the effects could be very, very bad. Since it deals with one of the most important parts of the car (entry and start), Tesla will need to address as many “unlikely” scenarios as possible due to each scenario’s significant impact on owners and the company. I could go on for a quite a long time on various hacking scenarios but I won’t for the interest of time.

Without spending an hour refuting every single one of your hypotheticals on top of hypotheticals, we'll just have to wait and see if/when Tesla enables a feature like this, with or without additional hardware. I say they can and it would pretty straightforward to do. No need to over complicate something so simple with hyperbole.
Again, I wish you would just focus on each point and/or example I make, rather than generalize.
 
There's plenty of hardware startups now doing Bluetooth LE (not Bluetooth) door locks and other security "sensitive" products. It's quite a different beast than normal Bluetooth in many regards. That said, I'm not 100% sure the current Model S has a suitable LE radio in it.

To make something like a lock it's more than just recognizing the phone's IMEI, when the phone and device are first paired they negotiate a unique encryption key to that phone, then whenever the car comes back into range an app on the phone can do a secure encrypted handshake over the link to verify it has the key. iOS allows apps to listen for Bluetooth LE proximity events and wake up in the background when it recognizes a known device. Just cloning the phone's ID isn't sufficient to unlock anything.

Like the existing mobile app pairing, it should obviously be something a user could disable if they wanted.
 
Hi Hank, I actually come from a software background.

I don't just come "from a software background". I've been developing software and user interfaces for the better part of 35 years now. So I know all about software reliability, testing, and security. As well as when someone is blowing smoke with assumptions and hyperbole in terms of software design and development.

You example of someone leaving their phone in the car at a valet.. A IMEI thief who wanted to clone your key fob phone would need several different pieces of information (and hardware) to successfully clone your key fob function, not JUST the IMEI. That's the point of two-factor authentication. Even if they got full access to your phone, they still couldn't do anything with it. So your example of a valet still is just FUD.


Again, I wish you would just focus on each point and/or example I make, rather than generalize.

Aint-nobody-got-time-for-that.png
 
So if I'm reading these posts correctly (and I'm sure someone will set me straight if I'm not), we've really only traded one problem for another.

-- Key fob: Annoying, but when in the proximity of the car, handles autopresent & you can just get in the car and go.

-- Proposed phone bluetooth solution (and btw, I agree with Dave T regarding issues*): No fob to carry, but now need a second form of authentication such as a password entered.

My two cents? No thanks. I'll drop the fob in my purse and not worry about it. If I left my phone behind somewhere or it was out of juice, I might be stranded.
---------
*You can't claim it's a 1 or 2 day programmer job 'plus a few weeks of testing' ... that makes it a 15 or 16 day job, minimum. Testing IS part of the job. Coding is a small part of any job, never the largest part. It just isn't. Requirements, testing, user instructions- these things take time. It's never a '1 or 2 day job'. Ever.
 
*You can't claim it's a 1 or 2 day programmer job 'plus a few weeks of testing' ... that makes it a 15 or 16 day job, minimum. Testing IS part of the job. Coding is a small part of any job, never the largest part. It just isn't. Requirements, testing, user instructions- these things take time. It's never a '1 or 2 day job'. Ever.

Sure, I'll agree with you there, but it's still not something that "Tesla would need to design, engineer a system from ground up" either. Most of the hard work has already been done.
 
I know all about software reliability, testing, and security. As well as when someone is blowing smoke with assumptions and hyperbole in terms of software design and development.
First, I’ll say I really don’t like getting into drama here. It doesn’t add value to the community. Again, please focus on the points rather than generalize. I think that’s a reasonable request.

Second, you were the one who stated that a bluetooth keyless entry/start system for the Model S would only take a day or two of a bluetooth engineer’s time and a few weeks of testing. How is that not “blowing smoke with assumptions and hyperbole in terms of software design and development”?

Your assumption that a bluetooth keyless entry/start system would be easy/simple to implement is the reason why I expounded on reasons why this is not necessarily the case.

Sure, it’s a one-day job to establish a bluetooth keyless entry/start system that’s maybe 99% reliable or even up to 99.9% reliable (considering the vast quantity of various smartphones out there). But to get to 99.99% reliability is probably not easy and it’s no where close enough to where Tesla would have to be at to implement this. Because it’s such a crucial part of the car, reliability would really need to be at close to 100%. And this is part I’m questioning, especially given Tesla’s existing bluetooth antenna system.

I think it’s completely reasonable for me to question your assumption that it’s a one-day job and “easy”.
 
No thanks. I'll drop the fob in my purse and not worry about it. If I left my phone behind somewhere or it was out of juice, I might be stranded.

Ok, so you're saying that the solution is that we all need to start carrying man-purses?

:)

Seriously, for women with a purse, the "problem" at hand is greatly reduced. I think for people who don't carry a purse or bag with them all the time don't want to carry around yet another thing (i.e. key fob) in their pants pocket, along with their wallet, phone, cash, changes, other keys, etc.

What I do with the MS key fob is use a small carabiner and clip it to my belt loop, so it's always on me, well attached, and also NOT in my pocket with all the other stuff.
 
So if I'm reading these posts correctly (and I'm sure someone will set me straight if I'm not), we've really only traded one problem for another.

-- Key fob: Annoying, but when in the proximity of the car, handles autopresent & you can just get in the car and go.

-- Proposed phone bluetooth solution (and btw, I agree with Dave T regarding issues*): No fob to carry, but now need a second form of authentication such as a password entered.

My two cents? No thanks. I'll drop the fob in my purse and not worry about it. If I left my phone behind somewhere or it was out of juice, I might be stranded.
---------
*You can't claim it's a 1 or 2 day programmer job 'plus a few weeks of testing' ... that makes it a 15 or 16 day job, minimum. Testing IS part of the job. Coding is a small part of any job, never the largest part. It just isn't. Requirements, testing, user instructions- these things take time. It's never a '1 or 2 day job'. Ever.

Yeah, I'm looking at it like this:

Current problem: key fob too bulky for minimalists like me.

Solution #1: shrink the current key fob by removing open frunk/trunk features and have it act just as keyless entry, make it credit card form to fit in wallet

Solution #2 (proposed by Hank): bluetooth entry/start system

Regarding #2, Hank is claiming it's easy for Tesla to implement, like a "1-2 day job with some testing". I'm saying that it could be much more complicated than that.

- - - Updated - - -

Sure, I'll agree with you there, but it's still not something that "Tesla would need to design, engineer a system from ground up" either. Most of the hard work has already been done.

Alright, let's take an example of a bluetooth key/lock system on the market:
http://www.amazon.com/Kwikset-925-Cylinder-Bluetooth-Deadbolt/dp/B00CPTD5AQ

I think it uses Bluetooth LE. It sounds like a great idea, but when you read the reviews:
Amazon.com: Customer Reviews: Kwikset 925 Kevo Single Cylinder Bluetooth Enabled Deadbolt for iPhone 4S, 5, 5C & 5S, Satin Nickel

There are a ton of reviews like:
"Over the past month I've had times when standing not 3 feet from the door that the lock did not respond. I had to inch closer to the door to activate it. As long as I'm within a bent elbows length away--about 1.5 feet, or say, the same distance away as when using a regular key--it has responded each time. But it is frustrating to think you are close enough, wait ten seconds for the lock to open only to find that you have to move closer, re-initiate the touch sequence, and wait another few seconds."

Note, that this lock is using the standard Bluetooth LE protocol. And it only gets 3 stars on Amazon.

The point being is that the product is buggy, and I'd hate to see that kind of reliability and user experience with the Model S. That would really hurt Tesla. In order to avoid this, Tesla would have to put in a ton of effort into design and software engineering to get the system up to reliability of near 100% that is required for a Model S keyless entry/start system. Just because the protocol exists doesn't mean most of the work has been done.
 
Bluetooth is just a communication protocol.
The cellphone can have key material on it and have a layer of security beyond bluetooth.

The phone doesn't need to be significantly more secure than the existing key fob - a PIN would make it vastly more secure. If someone steals your key fob, they don't need a PIN.

I would really like to only carry one device - my phone.
 
You example of someone leaving their phone in the car at a valet.. A IMEI thief who wanted to clone your key fob phone would need several different pieces of information (and hardware) to successfully clone your key fob function, not JUST the IMEI. That's the point of two-factor authentication. Even if they got full access to your phone, they still couldn't do anything with it. So your example of a valet still is just FUD.
Alright, I’ll concede the point about security as long as there’s two-factor authentication.

However, my point about reliability still stands. A bluetooth keyless entry/start system would need to be as reliable or even more reliable than the current key fob system to make it worth it for Tesla. Again, I’m not saying that’s not possible (I don’t know if it is), I’m just saying it won’t be easy to accomplish that. And also it might require additional hardware that the Model S doesn’t have (ie., Bluetooth LE antennas, etc).
 
I like the Bluetooth App idea. It's not meant to replace the Fob, it's just another option as a credit card key would be. Doesn't have to be either/or, and there are plenty of people that it would be a very viable solution for. They could probably just add it to the existing Tesla App. I think it's a great idea and I bet we see it happen one day. It's got exactly the type of nerdy deliciousness that Elon loves.