AEtherScythe

Active Member
First Name
Leon
Joined
Oct 11, 2020
Messages
35
Reaction score
47
Location
Michigan
Vehicles
Ford Mustang Mach-E, Ford Escape Hybrid
Occupation
Sr. IT/Product Architect; Enterprise and Cloud Manageability Engineering
Country flag
...
Right now Fordpass has no previous/saved charging locations but the car does. Tried that and it does not work. I can uninstall Fordpass and it will not work. Fordpass should have no logical bearing on why the charging schedule is set, says it will do it and then resets to default (immediate 100%) and does not.
Both the car and the FordPass app are syncing with the cloud. The car is not dependent upon the FordPass per se, but the car is dependent upon the cloud.
If the FordPass app and the car do not show the same information then it is an indication that there is a problem with app and/or car having difficulty syncing with the cloud.

If you want the charging schedule to honor your desired charge level and times, you need to achieve synchronization with the cloud. FordPass app is your way to know if what you set in the car is syncing properly to the cloud. The car consults its location against the settings in the cloud. If it's having trouble connecting to the cloud there will be issues.

I do not know how much autonomy Ford has engineered into the system for when the cloud can't be reached, but given how flakey it is even when supposedly connected via the modem, it seems likely that the experience would be even worse if the car can't reach the cloud reliably.

When trying to get the car and app to agree re: what is stored in the cloud, there is the added complication that if the car has been off for a while and is plugged in but not charging, the FordPass app might not show the saved charge locations properly. This suggest some kind of caching or logic issue in that if the car hasn't checked in recently, the charge location information cannot be retrieved by the app. That is why I had to go through several iterations to get the charging schedule and charge level settings to "stick" (in the cloud).





Advertisement

 

zhackwyatt

Well-Known Member
Joined
Dec 18, 2019
Messages
1,168
Reaction score
1,840
Location
Arizona
Vehicles
'21 InfBlu Prem MMEx Past: '13 C-Max '98 Explorer
Country flag
My employer's Internet traffic flows through an intercepting proxy much like the app you paid for, except at an enterprise-wide scale. All TLS/SSL traffic (other than sites added to an exception list) appears to be signed by their certs instead of the originators'.

Doesn't this suggest that if you were to sign into my company's WiFi, someone in IT at the company could see, in plain text, the traffic between your phone and @Ford Team's servers?
The way that works, is the company puts their public certificate into the trust store of the computer/browser. Without that certificate, the user would see an authentication failure and if they proceeded, then the company would see the data.


What I would not want is to encounter a similar arrangement at a hotel or restaurant, for example, where an untrusted party is able to copy and make use of my keys to my car simply because FordPass accessed the Internet while I was connected to their WiFi. Even if they are less privileged than "full access" keys and unable to put the car into Drive, I wouldn't want them to even be able to remote start it or unlock its doors.
Wouldn't work like that because the hotels cert is not in your phone. Therefor it wouldn't work...unless the app is ignorning authentication errors or the connection is not TLS.

What does happen in hotels is people will set up their own hotspots that have the same name as the hotel. You connect thinking your going to the hotel and your actually connecting to the bad guy. As long as the connection is TLS and you get no authentication errors your still safe. But if they aren't, or you just click accept on the authentication errors (not knowing what it means), well the bad guy sees it all.
 

zhackwyatt

Well-Known Member
Joined
Dec 18, 2019
Messages
1,168
Reaction score
1,840
Location
Arizona
Vehicles
'21 InfBlu Prem MMEx Past: '13 C-Max '98 Explorer
Country flag
Apples and oranges. You're raising an Area 51 level conspiracy theory level of nonsense against what happened totally between ME on MY device, and something happening at an enterprise level. Your company shouldn't be doing what they're doing.

There's nothing wrong with what I am doing with me and my data on my device. Please just stop.
He's raising concerns that the Ford pass app isn't verifying things correctly allowing an app like yours to work.

Also, the company should absolutely be inspecting TLS traffic that passes on its network. They have to protect themselves and using a company asset for personal data is a privilege provided by the company, not a necessity.
 

zhackwyatt

Well-Known Member
Joined
Dec 18, 2019
Messages
1,168
Reaction score
1,840
Location
Arizona
Vehicles
'21 InfBlu Prem MMEx Past: '13 C-Max '98 Explorer
Country flag
That isn't how HTTP Catcher works. The fact that it's a VPN on the same device as the app allows it to see both sides of the key exchange and replay them, same same re: client and server. There's nothing anyone can do to stop this and there's no way it can be used to exploit it against anyone else's data. It only works on-device by the user of the FordPass app looking strictly at their own data.
With correct authentication, you cannot simply replay each side and get a connection. The whole point of diffie-hellman key exchange is that it can be done with someone watching, and that observer still can't determine the private key.

It's likely that HTTP Catcher is adding its own certificate into the phones root store. Thereby terminating the FordPass app at the HTTP Catcher software, inspecting, then creating a new connection to Ford's servers.
 

Shayne

Well-Known Member
Joined
Aug 9, 2020
Messages
862
Reaction score
813
Location
Northern Ontario Canada
Vehicles
2021 MME4x Prem
Occupation
Retired
Country flag
Both the car and the FordPass app are syncing with the cloud. The car is not dependent upon the FordPass per se, but the car is dependent upon the cloud.
If the FordPass app and the car do not show the same information then it is an indication that there is a problem with app and/or car having difficulty syncing with the cloud.

If you want the charging schedule to honor your desired charge level and times, you need to achieve synchronization with the cloud. FordPass app is your way to know if what you set in the car is syncing properly to the cloud. The car consults its location against the settings in the cloud. If it's having trouble connecting to the cloud there will be issues.

I do not know how much autonomy Ford has engineered into the system for when the cloud can't be reached, but given how flakey it is even when supposedly connected via the modem, it seems likely that the experience would be even worse if the car can't reach the cloud reliably.

When trying to get the car and app to agree re: what is stored in the cloud, there is the added complication that if the car has been off for a while and is plugged in but not charging, the FordPass app might not show the saved charge locations properly. This suggest some kind of caching or logic issue in that if the car hasn't checked in recently, the charge location information cannot be retrieved by the app. That is why I had to go through several iterations to get the charging schedule and charge level settings to "stick" (in the cloud).
I will ask the engineers when I talk to them but i do not think there is anything coming from the cloud other than a location marker (coordinates) and the car does know where it is. After that it is a schedule I set up on the onboard OS for it to manage the car. On board OS ===> to Car. It is possible someone could be watching from the cloud and messing with me (no firewall) but highly unlikely they would be over riding the schedule programed and saved in the local OS. I do not think any magic from the clouds is happening or that the fordpass app has anything to do with it. It is the local OS interfacing with the hardware (or other modules). I may find out as I want this to be working.
 

AEtherScythe

Active Member
First Name
Leon
Joined
Oct 11, 2020
Messages
35
Reaction score
47
Location
Michigan
Vehicles
Ford Mustang Mach-E, Ford Escape Hybrid
Occupation
Sr. IT/Product Architect; Enterprise and Cloud Manageability Engineering
Country flag
With correct authentication, you cannot simply replay each side and get a connection. The whole point of diffie-hellman key exchange is that it can be done with someone watching, and that observer still can't determine the private key.

It's likely that HTTP Catcher is adding its own certificate into the phones root store. Thereby terminating the FordPass app at the HTTP Catcher software, inspecting, then creating a new connection to Ford's servers.
Correct.
 

macchiaz-o

Well-Known Member
First Name
Jonathan
Joined
Nov 25, 2019
Messages
3,475
Reaction score
6,963
Location
Valley of the Sun
Vehicles
human driven
Country flag
Wouldn't work like that because the hotels cert is not in your phone. Therefor it wouldn't work...unless the app is ignorning authentication errors or the connection is not TLS.
I understand that to fool my web browsers, the attacker would need to either change my set of certificate authorities or compromise one of the authorities (both are unlikely for a reasonably secured device or any reasonably operated authority).

However, does the FordPass app stop functioning in the face of untrusted certificates?

If FordPass does block untrusted certificate chains, then I'm happy. However, in an earlier response @AEtherScythe posited that they would be foolish to do so because of problems he thinks it would cause for people.
 

zhackwyatt

Well-Known Member
Joined
Dec 18, 2019
Messages
1,168
Reaction score
1,840
Location
Arizona
Vehicles
'21 InfBlu Prem MMEx Past: '13 C-Max '98 Explorer
Country flag
They could "improve" security by pinning Ford's certificate serial number in the app, refusing connections unless it has that number. This would prevent HTTP catcher from being able to work. But that's rarely used anymore due to usability issues.

The TLDR is, if all the following are true:
  1. The app uses the Android/iPhone TLS stack.
  2. The TLS stack is configured to prevent a connection when seeing an untrusted certificate.
  3. Neither the phone nor the phone is compromised in another way.
There is no issue. It's no worse than the banking app on your phone.
 

GoGoGadgetMachE

Well-Known Member
First Name
Michael
Joined
Jan 23, 2020
Messages
3,719
Reaction score
7,531
Location
Ohio
Vehicles
2013 Ford Fusion Energi, 2021 Mach-E First Edition
Country flag
They could "improve" security by pinning Ford's certificate serial number in the app, refusing connections unless it has that number. This would prevent HTTP catcher from being able to work. But that's rarely used anymore due to usability issues.

The TLDR is, if all the following are true:
  1. The app uses the Android/iPhone TLS stack.
  2. The TLS stack is configured to prevent a connection when seeing an untrusted certificate.
  3. Neither the phone nor the phone is compromised in another way.
There is no issue. It's no worse than the banking app on your phone.
yeah certificate pinning is a huge pain in the ass. it might get better someday but right now, ugh.

The TL;DR is missing step 2.5 which is "the TLS stack is configured with the user's knowledge to trust the root of the app" which is an important step actually.

I hadn't used the HTTP Catcher app on iOS/iPadOS before, but I've used Fiddler plenty of times, which does the same thing, in the same way (creating its own root and having the OS trust it). Just because I was curious, I installed the HTTP Catcher app: ‎HTTP Catcher on the App Store (apple.com)

I then paid the $3.99 to unlock it because I love all of you and you're worth it. 😘

Here's some screenshots. Apple makes it a little hard to add a trusted certificate and trust it because of course they do but the bottom line is a user has to trust the root from the app. There's nothing broken here. It's arguable that any user could be convinced to do all of this to "get the dancing bear working" but ultimately you have to trust the user a little and that is a different discussion.

IMG_0001.PNG

IMG_0002.PNG
IMG_0003.PNG
IMG_0004.PNG
IMG_0005.PNG


ps a lot of enterprises do this very thing with transparent proxies without actually telling the user.
 

TheVirtualTim

Well-Known Member
First Name
Tim
Joined
Oct 11, 2020
Messages
462
Reaction score
863
Location
Dearborn, MI
Vehicles
Mach-E First Edition, Escape Hybrid
Country flag
@AEtherScythe no... @macchiaz-o is not spouting a conspiracy theory. When TLS initiates a handshake with the server, the server is supposed to respond with a certificate.
TLS is working correctly. Nothing is broken. Time to chime in.

I actually AM a security guy. There is no problem with the implementation. This is something where non-security people see something that seems scary because they don't understand how it works.

There's really no actual risk based on the way this is all implemented because the client device (in this case the phone or iPad running the app) had to be configured to use a proxy-type device ... by the person who owns the device. Trusted certificates had to be set up to make it work ... again, a deliberate configuration that can't happen accidentally or without your knowledge. Your client device has to be configured to trust it -- again, NOT something that happens without your knowledge.

You have to configure a client device to use something like a network proxy or a VPN. This is something YOU CONTROL ... nobody can sneak one past you. If you drop a proxy server just anywhere on the internet then you break TLS ... it's designed that way deliberately. You go into the network settings to make this happen. It does not just happen by accident.

Public-key cryptography is the most common type of asymmetric cryptography ... what one key "encrypts" ONLY the opposite key can "decrypt" and vice versa. The problem with it is ... it's computationally expensive ... on the order of 100x more computationally complex than single-key (symmetric) cryptography.

There is such a thing as mutual authentication for HTTPS ... but it's very rarely used because it requires a public key infrastructure to handle problems such as key issuance (signing), revocations, and renewals. There are other questions such as did it really just authenticate the user ... or did it only authenticate the connection (there is a difference). VPNs, for example, only authenticate the device. Any process able to access the network connection may use it ... so it doesn't authenticate client applications or users. It's meant to keep people from spying on the traffic ... not to validate users or apps.

Server-side authentication (server has to have valid X.509 certificates but not the client) is good enough and that ALSO works to protect you from spying (there are some things that can be derived from HTTPS traffic so if you're really worried about security, additional measures should be taken ... but this isn't really a good application for that.)

The client DOES authenticate the server ... no sneaky stuff was done here. The server has a public key in the form of an SSL certificate (and I say "SSL" colloquially because nobody really uses SSL anymore). A public cert is really the public half of the asymmetric key pair ... but extra meta-data is added to describe who the key belongs to and other properties of the key. You might be thinking ... couldn't just anyone come up with a key and some meta-data? And yes... they can. So the key is digitally "signed" by a well-known party. To "sign" a key, they compute a mathematical checksum. The equation used to generate the check-sum is complex enough that there is no way to modify any part of it and still get the correct checksum. It is possible to come up with another set of data that derives the *same* checksum ... but that second set of data is likely to be pure gibberish. It wouldn't be accepted because it wouldn't be understood. So there's no way to make a meaningful change that could trick someone. The checksum is then encrypted ... by the private key of the Certificate Authority. Your computer's web-browser has a list of known trusted authorities ... along with their public keys. Your computer performs the SAME mathematically checksum on the certificate ... and also uses the issuers public key to decrypt their checksum. If their checksum and your checksum are the same then it proves the data in the certificate has not been altered and really was signed by that authority ... in other words you can trust you are talking to the party they claim to be (In this case you know you are talking to the correct server at Ford).

SSL & TLS rely on something called the Diffie-Hellman key exchange algorithm. The "problem" with a new network connection when the client doesn't have a cryptographic public key known to the server is that you need a way to get a key that both the client and server know and agree to use ... without anyone else spying on the traffic being able to intercept or derive what that key is. There are numerous YouTube videos that explain the algorithm by using the example of mixing paint colors. (It's not really exactly how it works, but it's a pretty good analogy to explain how two parties could agree on a "secret" paint color by exchanging different colors ... in the clear ... and both will eventually end up with the same final color but anybody spying on them (even though they saw all the traffic) would never be able to figure out what the secret color is.

Since the algorithm works EVEN if someone if someone is spying on all the traffic, there's no reasonable way to crack the key ... UNLESS ... You make a DELIBERATE decision to let the middle-man in on the secret (and that's basically what happens here).

The Diffie-Hellman algorithm is used to derive a secret key and from there the entire connection is carried out via this key ... and it's much more efficient than asymmetric crypto.

The server did require client authentication and uses security tokens. Nobody can send those API's to just any VIN number they want and extract the information ... that's locked down. I cannot substitute the VIN for your car in place of the VIN for my car ... it wont work. I would need the security tokens for the person who owns that VIN ... and that's something I can't get (unless that owner gives them to me).

Bottom line...

1. Nobody came up with a way to trick the TLS algorithms into being able to spy on the traffic. The algorithms work and there is no need to augment them.

2. This ONLY worked for Leon because he intentionally configured his client device to send data through a type of proxy that completes one connection and starts another connection. This is something you can only knowingly do ... a malicious part cannot make this work to spy on you. You have to reconfigure your device to make this happen.

I hope everyone can sleep easier now ... knowing that nobody pulled a fast-one. If what Leon had done was really some sort of a security hole then the entire security of the Internet would collapse.
 

JellyBelly

Well-Known Member
First Name
Kris
Joined
Jun 27, 2020
Messages
2,249
Reaction score
1,742
Location
San Diego
Vehicles
MME RR FE
Country flag
All the latest software and a new primary drive unit. Leave for Florida tomorrow.
That’s great. Hope you have great trip and Marlin has no more issues
 
OP
tomterky

tomterky

Well-Known Member
First Name
E
Joined
Jun 30, 2020
Messages
151
Reaction score
286
Location
55129
Vehicles
2010 Mustang Pony Edition Convertible; 2021 Mach E
Country flag
  • Thread starter
  • Thread Starter
  • #538
UPDATE: Below is what the Ford Field Service Engineer did to Titan's Steed for the 12V battery issue which caused the powertrain fault:

Screenshot_20210227-192511_Acrobat for Samsung.jpg
 

MarknKC

Member
First Name
Mark
Joined
Jan 30, 2021
Messages
18
Reaction score
24
Location
Kansas City, Missouri
Vehicles
2012 Ford Focus EV 2021 Mach E Premium (reserved)
Occupation
Electrical Engineer
Country flag
I should add that the reason we had this problem in the first place is right after taking delivery of the car we sent it straight to a detailer to have it ceramic coated. The ceramic coating needs at least two weeks to "cure" and longer than that in the frigid Michigan temperatures. Also, the ceramic coating would be ruined if allowed to get wet before it was fully cured.
We had snow and ice for weeks, so the car sat, not being driven all those days.

Most people have been driving their Mach-E's every day or at least every so often, and when driving, the HVB tops off the LVB. While waiting for the ceramic coating to cure, I had gone out and sat in the car with the seat heater on to keep warm in the 12ºF temps, while setting up my profile and checking out all the controls and the audio system. During that time every warning indicator started going off all at once and it eventually got to the point where the displays reset a couple of times and shut down. Even the door locks would not operate, so we had stuff towels in the doors to keep them from being accidentally closed until we could get help to figure out what was wrong.

It did not immediately occur to me that the LVB was dead, I mean how could it be, since the HVB had plenty of power and on top of that the car was plugged into the wall-charger? But after all the LVB was down to 5V and so nothing would function.

The software fix is for the case where the car is not ever being driven and is just left plugged into power. Though the HVB could have charged the LVB (as it does when being driven), there is logic to say don't do that because the car is plugged in.
The LVB was supposed to be charged from the wall charger, but that wasn't happening.
The software update fixes that.
We had this problem. Check with your dealer to see if they have access to the required software fix. Ours is fixed now, 100% confirmed. But it may take some doing for your dealer to get the software fix, in lieu of an over-the-air update.

BTW, the reason I know ours is 100% fixed is because I am able to snoop on what the FordPass app is doing and there is an API that shows the 12 volt battery status. It used to show:

Code:
"battery": {
      "batteryHealth": {
        "value": "STATUS_LOW",
        "timestamp": "02-23-2021 22:39:58"
      },
      "batteryStatusActual": {
        "value": 12,
        "status": "CURRENT",
        "timestamp": "02-24-2021 19:01:19"
      }
}
But now I can see that when the Mach-E is doing a "conditioning" cycle, every six hours, it is actually topping off the battery:

Code:
"battery": {
      "batteryHealth": {
        "value": "STATUS_GOOD",
        "timestamp": "02-25-2021 16:39:58"
      },
      "batteryStatusActual": {
        "value": 15,
        "status": "CURRENT",
        "timestamp": "02-25-2021 13:01:19"
      }
}
15V Is also what the 12V accessory socket shows when the Mach-E is running and the LVB is being topped off constantly by the HVB. This behavior proves to me that the LVB is getting topped every 6 hours.
We had this problem. Check with your dealer to see if they have access to the required software fix. Ours is fixed now, 100% confirmed. But it may take some doing for your dealer to get the software fix, in lieu of an over-the-air update.

BTW, the reason I know ours is 100% fixed is because I am able to snoop on what the FordPass app is doing and there is an API that shows the 12 volt battery status. It used to show:

Code:
"battery": {
      "batteryHealth": {
        "value": "STATUS_LOW",
        "timestamp": "02-23-2021 22:39:58"
      },
      "batteryStatusActual": {
        "value": 12,
        "status": "CURRENT",
        "timestamp": "02-24-2021 19:01:19"
      }
}
But now I can see that when the Mach-E is doing a "conditioning" cycle, every six hours, it is actually topping off the battery:

Code:
"battery": {
      "batteryHealth": {
        "value": "STATUS_GOOD",
        "timestamp": "02-25-2021 16:39:58"
      },
      "batteryStatusActual": {
        "value": 15,
        "status": "CURRENT",
        "timestamp": "02-25-2021 13:01:19"
      }
}
15V Is also what the 12V accessory socket shows when the Mach-E is running and the LVB is being topped off constantly by the HVB. This behavior proves to me that the LVB is getting topped every 6 hours.
I posted somewhere else that this was the exact kind of code that would fix this but I also am in disbelief that the original build did not have that routine. After all the heartache with the exact same problem with the Focus EV, you'd think somebody at Ford would have made a note. There must not be anybody from the FFE team left, or working on the Mach E.
 

dtbaker61

Well-Known Member
First Name
Dan
Joined
May 11, 2020
Messages
411
Reaction score
314
Location
santa fe,nm
Website
www.envirokarma.org
Vehicles
MME (delivered 2/26/21), DIY eMiata conversion
Occupation
Solar Sales/install
Country flag
It is funny. I just got a Ford pass update saying that for now you need to reset the odometer rating regularly until you have enough miles so that the car can learn your driving habits.

I learned that here yesterday. Upon charging again last night at 100% it went from the 232 to 241.
I would suggest 'resetting history' only if you are changing the TYPE of trip you are going to take.... i.e. if you usually drive urban/suburban stop and go and are about to embark on a long road trip where the consumption will be significantly different at highway speed with minimal help from regen
 

Advertisement





 


Advertisement
Top