Tesla's response to me leaking info about the P100D?

[MarkS22]

Privacy & Legal | Tesla Motors

Thanks... That's a nice gesture on the part of Tesla. I was unaware they listed it. That said, I still think there's a reward being part of the EAP in itself. And if an EAP member finds a confirmed vulnerability, they belong on the same "Wall of Fame."

Also, wk's action probably wouldn't be a "security vulnerability" yet he did show Tesla (if they weren't already aware) that people can gain access to undisclosed model information. Now they can address it moving forward when releasing new firmware.

 

[SomeJoe7777]

Hash - encrypting something is alsocalled hashing it
Salt the hash - use a seed value for the encryption algorithm that makes it harder to reverse unless you know the seed (salt)

No sir. Encryption and hash algorithms are two very different things.

Encryption is reversible. Suppose I have some unencrypted information (called the plaintext or P), and a secret that only I know (called the key or K).

Encrypting the plaintext with the key results in encrypted information (called the ciphertext or C). I can now allow anyone to view the ciphertext and be confident that they cannot recover the plaintext without the key.

The person who needs to recover the plaintext can do so by reversing the encryption algorithm and only if they also know K. This decryption process takes C and recovers P.


Hashing is a one-way function. The message (M) of any length can be hashed and give a constant-length hash value (H). There is no key for this operation. The hash algorithm is not reversible, so if you have H, there is no way to recover message M.

wk057 took a message ("P100D") and ran it through a hash algorithm called Secure Hash Algorithm 2 (SHA2). This gives a 256-bit hash, H. There is no way to recover the message M from the hash H. However, because the message M was so short, it was easy to guess, and running the guess through the same algorithm arrives at the same H. Thus we can conclude that wk057 originally started with "P100D". No "decryption" was done for this, it was simply a few well-informed guesses that allowed the determination of M.

The notion of "salt" or "salting a hash" means that random additional data is added to the original message M before running it through the hash algorithm. This lengthens the message, and because the salt is random, makes it impossible to guess. Now the resulting H is secure from any type of guessing. But wk could prove later that he knew the original message M by disclosing the salt that he used. The resulting hash of the message M and his salt will give his previously posted H.

 

[gizmoboy]

I will say this one more time in the (probably vain) hope that certain people take notice this time:

wk057 did not deliberately leak information

That dubious distinction belongs to whoever first broke the cryptographic hash and published the result, not wk.

"But ossifer, I didn't kill him, I just booby-trapped his door with a shotgun rigged to the handle. He actually killed himself when he came home..."

Let's get real. He deliberately put the non-public information out in the public when it wasn't before. That's a leak.

He may have intended to make it "impossible" to read when he did so, but he failed spectacularly in that regard.

 

[JER]

"But ossifer, I didn't kill him, I just booby-trapped his door with a shotgun rigged to the handle. He actually killed himself when he came home..."

That's a spectacular mischaracterisation.

Let's get real.

Indeed, let's.

What wk did is tweet a SHA256 hash of the secret. SHA256 is a strongly one directional transform. It is normally impossible to obtain the original data from the hash; assuming that disclosing a hash would be safe was not totally unreasonable.

The only reason the leak happened was the original data was short enough for the secret's hash to be a known - or easily found - result of the transform. Really, the only mistake wk made was not salting the secret with another, longer secret before hashing it; had he done this, P100D would certainly have stayed secret.

He deliberately put the non-public information out in the public when it wasn't before. That's a leak.

It was Tesla that sent the non-public information out to every car in the fleet, in plaintext and in unencrypted images. THAT is a leak.

wk was at least trying to take more care than Tesla was.

He may have intended to make it "impossible" to read when he did so, but he failed spectacularly in that regard.

Agreed. But given wk does not often have Hagrid Moments, can we just give the guy a break? There was clearly no ill intent on wk's part here.

(Plenty of ill intent with all the blue-on-blue smear campaigning going on afterwards, though.)

 

[Endoplasmic]

*whew* that was a lot of pages!

What I learned in this thread is pretty exciting and inspiring (I love connecting to things to see what makes them tick).

I'm not sad that a larger battery is coming out (we've ordered the 90D, we haven't even got the mail saying it's in production yet). What I am potentially sad about is if the hardware has changed on the Model S moving forward and I'm missing it by a couple of weeks. I assumed a larger battery was coming, so I didn't care if that was the only thing, but yah, sad times if they add a bunch more sensors or something

 

[doofenshmirtz]

No sir. Encryption and hash algorithms are two very different things.

Encryption is reversible. Suppose I have some unencrypted information (called the plaintext or P), and a secret that only I know (called the key or K).

Encrypting the plaintext with the key results in encrypted information (called the ciphertext or C). I can now allow anyone to view the ciphertext and be confident that they cannot recover the plaintext without the key.

The person who needs to recover the plaintext can do so by reversing the encryption algorithm and only if they also know K. This decryption process takes C and recovers P.


Hashing is a one-way function. The message (M) of any length can be hashed and give a constant-length hash value (H). There is no key for this operation. The hash algorithm is not reversible, so if you have H, there is no way to recover message M.

wk057 took a message ("P100D") and ran it through a hash algorithm called Secure Hash Algorithm 2 (SHA2). This gives a 256-bit hash, H. There is no way to recover the message M from the hash H. However, because the message M was so short, it was easy to guess, and running the guess through the same algorithm arrives at the same H. Thus we can conclude that wk057 originally started with "P100D". No "decryption" was done for this, it was simply a few well-informed guesses that allowed the determination of M.

The notion of "salt" or "salting a hash" means that random additional data is added to the original message M before running it through the hash algorithm. This lengthens the message, and because the salt is random, makes it impossible to guess. Now the resulting H is secure from any type of guessing. But wk could prove later that he knew the original message M by disclosing the salt that he used. The resulting hash of the message M and his salt will give his previously posted H.

Thank you for clarifying!

 

[Naonak]

No sir. Encryption and hash algorithms are two very different things.

Encryption is reversible. Suppose I have some unencrypted information (called the plaintext or P), and a secret that only I know (called the key or K).

Encrypting the plaintext with the key results in encrypted information (called the ciphertext or C). I can now allow anyone to view the ciphertext and be confident that they cannot recover the plaintext without the key.

The person who needs to recover the plaintext can do so by reversing the encryption algorithm and only if they also know K. This decryption process takes C and recovers P.


Hashing is a one-way function. The message (M) of any length can be hashed and give a constant-length hash value (H). There is no key for this operation. The hash algorithm is not reversible, so if you have H, there is no way to recover message M.

wk057 took a message ("P100D") and ran it through a hash algorithm called Secure Hash Algorithm 2 (SHA2). This gives a 256-bit hash, H. There is no way to recover the message M from the hash H. However, because the message M was so short, it was easy to guess, and running the guess through the same algorithm arrives at the same H. Thus we can conclude that wk057 originally started with "P100D". No "decryption" was done for this, it was simply a few well-informed guesses that allowed the determination of M.

The notion of "salt" or "salting a hash" means that random additional data is added to the original message M before running it through the hash algorithm. This lengthens the message, and because the salt is random, makes it impossible to guess. Now the resulting H is secure from any type of guessing. But wk could prove later that he knew the original message M by disclosing the salt that he used. The resulting hash of the message M and his salt will give his previously posted H.

Thanks, I was going to say something similar. However, not to be pedantic, but the salt is not random data. It CAN be random data, but there's no requirement for it to be random, and in fact for most password storage solutions in use on forums and stuff, the salt is not random at all, nor does it need to be, as long as the salt stays secret. Adding iterations to a hash can also prevent most brute force attacks, no salt needed.

 

[gizmoboy]

Again, you miss the point. Had wk actually done this properly - i.e. use random salt - it would've been literally impossible to break without the salt. There could be no leak.

Don't believe me? Well, he's posted another hash - this time done right - and nobody has broken it. Nobody will, because cryptography done right is, to all intents and purposes, an unbreakable box.

He assumed (wrongly) first time that what he was posting would have that level of security. Really, can't you give the guy some slack for not being at 100% smarts at that moment?

The thing is, he had no need​ to post it at all, so any risk (and even with this new stuff, there's a risk) is unwarranted, save for ego stroking.

- - - Updated - - -

I'm just curious -- and obviously no expert -- but is the point of posting a salted hash to be able to release the key after the information is otherwise made public so that you can show you did have the information as of the time you made the post?

Yes. It's a reservation for a future "look at me!" event.

And let me be clear... I'm wowed by the technical capabilities that wk057 has demonstrated. They are quite impressive.

But just because one can (even legally) do something does't mean that one should. And if one wants to be considered a white-hat individual, putting another company's trade secrets at risk at any level isn't on the list of things one should do.

 

[wk057]

Wow. If I post a puzzle and challenge people to solve it ... and they do ... well it's clear you and I reach different conclusions on that scenario. But I'm sure he appreciates such loyal followers that rise to his defense.

As mentioned several times already (including my last post where you even bolded that specific portion in your response saying it was a good post), it wasn't meant to be a puzzle or challenge at all. It was meant to be a fun way to time stamp the fact that the P100D was in the firmware before it was released, then when it was actually released I would have posting something like, "Oh, remember that hash from a while back? It meant xxxxxx. Yeah, Tesla had it in the firmware since xx/xx/xxxx."

My late night mistake was not actually making it impossible to brute force in our lifetimes (by adding a salt to the input) and instead just using a 5 character input.

So it short, JER is right (thanks for the support). It was not my intention to leak the information.

Privacy & Legal | Tesla Motors

I do believe that list predates Tesla's bugcrowd program, which has its own hall of fame (on which I'm listed as private). I could be wrong though, but it hasn't been updated for a while.

And no, cryptography done right is not 'unbreakable'. It is tough to break. (source: I spent some of my programming career in cryptography)

Then you'll know that a properly salted SHA256 hash is quite literally *impossible* to break with even the entire world's computing resources combined in less than, oh I don't know, the remaining life of the universe?

I'm just curious -- and obviously no expert -- but is the point of posting a salted hash to be able to release the key after the information is otherwise made public so that you can show you did have the information as of the time you made the post?

^ This. As mentioned above, I thought it'd be a fun way to prove that Tesla had basically sent the info to thousands of customers well ahead of time, without actually giving up the info.

 

[gizmoboy]

That's a spectacular mischaracterisation.



Indeed, let's.

What wk did is tweet a SHA256 hash of the secret. SHA256 is a strongly one directional transform. It is normally impossible to obtain the original data from the hash; assuming that disclosing a hash would be safe was not totally unreasonable.

The only reason the leak happened was the original data was short enough for the secret's hash to be a known - or easily found - result of the transform. Really, the only mistake wk made was not salting the secret with another, longer secret before hashing it; had he done this, P100D would certainly have stayed secret.



It was Tesla that sent the non-public information out to every car in the fleet, in plaintext and in unencrypted images. THAT is a leak.

Let me see if I am characterizing your position accurately:

Tesla embedded information in their software byte code and which requires highly technical expertise to reverse-engineer and view, and the hacking of which is not supported or encouraged in any way by Tesla (and would likely be strongly discouraged by them or forbidden if one were to ask them). This information is, with 100% certainty to any reasonable observer, not intended for public dissemination at this time.

This information in the firmware you considered to have been "leaked" by Tesla to the public.

Is that your position?

If it is, do you suggest that it is unclear that Tesla doesn't want this information to be made public at this time, or that their wishes are irrelevant to the matter?

 

[JER]

Is that your position?

No. I have already stated my position very clearly. Your additions - apparently made for your convenience - are unwelcome.

You can draw as many chalk outlines on the ground as you like; I have no intention of lying down in any of them.

Let me know when you're done with the bad faith argumentation.

 

[gizmoboy]

No. I have already stated my position very clearly. Your additions - apparently made for your convenience - are unwelcome.

You can draw as many chalk outlines on the ground as you like; I have no intention of lying down in any of them.

Let me know when you're done with the bad faith argumentation.

Your ad hominem attacks are a poor form of argumentation.

If you had stated your position as clearly as you think you have, I'd not be asking for it.

But you clearly have no interest in an actual debate, so my interaction with you is at an end.

 

[bonnie]

As mentioned several times already (including my last post where you even bolded that specific portion in your response saying it was a good post), it wasn't meant to be a puzzle or challenge at all.

I bolded the part saying you were going to send a note of apology to the engineers most likely impacted by this & appreciated you taking ownership. I was very clear in that response. And that's what I meant by 'good post'. I always appreciate when people take ownership for their actions.

update --

To be clear, wk, I don't think you spilled information on purpose. But it was a foreseeable consequence - and in any case, I appreciate you owning that. I did see that first tweet as a bit of a taunt, but believe you didn't think of it that way (but hopefully you've noticed that others have read it the same way I did). I think you forget at times that there are a lot of smart people here on this forum and a lot of tenacious ones - and those two groups have a fairly large common group of members. And I think when you posted it, you forgot about the engineers who potentially are dealing with some negative blowback as a result. So that note of apology will be a good thing to do.

 

[wk057]

Let me see if I am characterizing your position accurately:

Tesla embedded information in their software byte code and which requires highly technical expertise to reverse-engineer and view, and the hacking of which is not supported or encouraged in any way by Tesla (and would likely be strongly discouraged by them or forbidden if one were to ask them). This information is, with 100% certainty to any reasonable observer, not intended for public dissemination at this time.

This information in the firmware you considered to be "leaked" by Tesla to the public.

Is that your position?

If it is, do you suggest that it is unclear that Tesla doesn't want this information to be made public at this time, or that their wishes are irrelevant to the matter?

You seem to have an interesting view of how this actually was discovered. So let me clear things up for you and others, since the cat's already out of the proverbial bag.

In v7.0 (2.7.77) the characters "P100D" do not exist anywhere in the firmware.

In v7.1 (2.9.154) several libraries had references to this model, in plain text.

root@technicality:/mnt/2.9.154/usr/tesla/UI-2.9.154/lib# strings *.so | grep ^P[0-9] | grep D$
P85D
P85D
P90D
P100D
P90D
P85D
P100D
P85D
P90D
P100D

That was it though, just some configuration options for P100D in the libraries, and a few other places. Not much else, but enough to know that it was being worked on. I received this firmware on January 9, 2016.

Not much changed until a couple of days ago when guess what finally showed up to accompany the new configuration option:

root@technicality:/mnt/2.13.77/usr/tesla/UI-2.13.77# find | grep badge
[SIZE=1][I]*snip*[/I][/SIZE]
./assets/ModelS/night/cluster/hi_res/[B]badge_p100d_ludicrous.png[/B]
[I][SIZE=1]*snip*[/SIZE]
[/I]

I mean, this isn't rocket science. Once you have access to the car this stuff is literally just laying right there. Anyone with any amount of Linux administration or dev knowledge would be able to see that a P100D was coming with access to their car's shell. This was not "software byte code" nor does it require "highly technical expertise to reverse engineer." Plaintext. Literally in plain sight. So don't try to make it out like I went out of my way to decode something in order to leak information.

 

[CarlK]

*whew* that was a lot of pages!

What I learned in this thread is pretty exciting and inspiring (I love connecting to things to see what makes them tick).

I'm not sad that a larger battery is coming out (we've ordered the 90D, we haven't even got the mail saying it's in production yet). What I am potentially sad about is if the hardware has changed on the Model S moving forward and I'm missing it by a couple of weeks. I assumed a larger battery was coming, so I didn't care if that was the only thing, but yah, sad times if they add a bunch more sensors or something

Probably not such a big deal as we have used to how fast Tesla keeps improvement coming. I got my P85+ just a few months before announcements of the two biggies, AP and D but the thought was my next Tesla would have those and many more. One can never have the latest and greatest for long with Tesla.

 

[satoshi]

requires highly technical expertise to reverse-engineer and view, and the hacking of which is not supported or encouraged in any way by Tesla

I'm going to refute these two points...

requires highly technical expertise to reverse-engineer and view

No, it does not. If a simple grep call is all you need this means that just about anyone who has ever touched linux could find it with ease. As I know of plenty of 10 year olds who know how to use grep... this is nothing special.

Here's a tutorial: How to use grep to search for strings in files on the shell

Here's a 6-year old using linux command-line: 6 Year Old Girl Utilizing the Command Line Interface with Ubuntu Linux. - YouTube

Linux commands are not by any means "highly technical" in their nature.

the hacking of which is not supported or encouraged in any way by Tesla

Bugcrowd | Your Elastic Security Team, better security testing through bug bounties and managed security programs

I rest my case.

 

[Monkey]

Lesson learned for Tesla: don't include information you aren't ready for release in the firmware. You could have politely pointed that out to them instead of releasing it publicly.

Or Tesla could just leave in things like that, which make logical sense and even add a host of other info and dummy entries or bogus stuff. Like Apple and Samsung tend to do with new software releases.

 

[Endoplasmic]

Probably not such a big deal as we have used to how fast Tesla keeps improvement coming. I got my P85+ just a few months before announcements of the two biggies, AP and D but the thought was my next Tesla would have those and many more. One can never have the latest and greatest for long with Tesla.

Appreciate the words, and I know that this machine gets updates all the time, but the event being so close to when I take delivery makes me think that I should hold off, lose the $1200 referral, and possibly add some upgrades.

 

[JER]

Your ad hominem attacks are a poor form of argumentation.

Demonstrating you don't recognise the difference between ad-hominem and a legitimate complaint about your misrepresentation is a rather poor form of argumentation.

If you had stated your position as clearly as you think you have, I'd not be asking for it.

Must I spell it out? Well, here are the explicit clauses:

(1) Tesla does not partition sensitive information from firmware pushed to customers' cars.
(2) (1) constitutes distribution to people with root access (who can access this information easily.)
(3) Those mentioned in (2) operate at Tesla's invitation and with Tesla's full awareness.
(4) wk057 is among those mentioned in (3).
(5) wk057 has overwhelmingly treated the sensitive information on his car in confidence (in addition to following white hat disclosure protocols on vulnerabilities.)
(6) The only known exception to (5) was atypical, understandable and unintentional.

But you clearly have no interest in an actual debate, so my interaction with you is at an end.

You took the words right out of my mouth.

 

[FlatSix911]

Very interesting ... thanks for the clarification!

You seem to have an interesting view of how this actually was discovered. So let me clear things up for you and others, since the cat's already out of the proverbial bag.

In v7.0 (2.7.77) the characters "P100D" do not exist anywhere in the firmware.

In v7.1 (2.9.154) several libraries had references to this model, in plain text.

root@technicality:/mnt/2.9.154/usr/tesla/UI-2.9.154/lib# strings *.so | grep ^P[0-9] | grep D$
P85D
P85D
P90D
P100D
P90D
P85D
P100D
P85D
P90D
P100D

That was it though, just some configuration options for P100D in the libraries, and a few other places. Not much else, but enough to know that it was being worked on. I received this firmware on January 9, 2016. Not much changed until a couple of days ago when guess what finally showed up to accompany the new configuration option:

root@technicality:/mnt/2.13.77/usr/tesla/UI-2.13.77# find | grep badge
[SIZE=1][I]*snip*[/I][/SIZE]
./assets/ModelS/night/cluster/hi_res/[B]badge_p100d_ludicrous.png[/B]
[I][SIZE=1]*snip*[/SIZE]
[/I]

I mean, this isn't rocket science. Once you have access to the car this stuff is literally just laying right there. Anyone with any amount of Linux administration or dev knowledge would be able to see that a P100D was coming with access to their car's shell. This was not "software byte code" nor does it require "highly technical expertise to reverse engineer." Plaintext. Literally in plain sight. So don't try to make it out like I went out of my way to decode something in order to leak information.