Do you remember these guys? Charlie Miller and Chris Valasek - they hacked a Jeep around 2015. When I started at Ford I referenced their DEFCON talk and white paper extensively.
Image 1 Reference 
Part of the kill chain for the Jeep hack was to update the CAN Interface Chip on the Infotainment Unit. The Renesas RH850 that the Tier-1 was using did not use firmware signing as a security control. So Chris and Charlie were able to upload their backdoored firmware and the chip ran it without hesitating. 
This blog entry is going to be about firmware signing and how it is used in the automotive industry today. Aiming to do this in 4 minutes - stay with me.
When firmware is downloaded now-a-days, there is a step to check the digital signature on the firmware update. If this signature check does not pass, then the update is not saved to flash memory. This keeps the chip from permanently writing malicious instructions into nonvolatile memory.
So what is a digital signature? It is built off of asymmetric cryptography - where there is both a private key and a public key that are used for separate purposes. A digital signature is a fixed length set of bytes sent along with the original input data that can be checked with "crypto math." It guarantees that only someone who has access to the private key could have generated that digital signature. A digital signature guarantees the integrity of the signed data (that the data was not tampered with) and that the source of the data is authentic (I can trust that the data came from who I think it came from).
Access to the private key = the ability to generate the signature
Access to the public key = the ability to verify the signature
For example, from this Wikipedia diagram , Alice wants to send Bob a message and Bob wants cryptographic proof that the message came from Alice. If Alice is practicing cybersecurity correctly she has her private key stored in a place that only she has access to (like a Network HSM - but I'm not going to get into private key storage beyond that in this post).
Alice uses her private key to generate a digital signature and sends this along with the message to Bob.
Bob uses Alice's public key to verify the digital signature. A successful verification means that he is certain Alice sent the message and that it wasn't tampered with.
Image 1 Reference 
In practice, Hash functions are added into a digital signature scheme to make it so that an arbitrary sized input can be signed by the asymmetric algorithm. (For example, RSA has a limit and can only operate on small amounts of data.) A hash function is used so that variable length input can be mapped to a fixed length hash digest. The hash digest is "encrypted" with the private key according to the asymmetric algorithm being used. (I realize calling a digital signature an "encrypted hash" may not be 100% correct but for the purposes of this blog that is the best way I see to explain it)
To end, here's an example going back to firmware signing.
Overview of the firmware signing process (Example with RSA 2048 and SHA-256 for hashing)
Input firmware is hashed from beginning address to end address
RSA Digital Signing operation is performed with the RSA Private Key (abstracting out padding for this level of discussion)
Output digital signature is appended to the firmware update file at a known address
Overview of the firmware signing verification process (Example with RSA 2048 and SHA-256 for hashing)
Calculate hash from the beginning of the firmware update image to the end of it
Decrypt the digital signature from the firmware image
Compare the first 32 bytes of the decrypted hash to the hash value calculated
If the hashes are the same, the signature verification is successful. If not, it fails and something is wrong with the firmware image or the key used to verify the signature.
Example Using OpenSSL to generate keys and Cyberchef
These OpenSSL commands produce 2 files - one for a private key and another for a public key. I am using RSA 2048 keypairs.
openssl genrsa -out demo_private_key.pem 2048
openssl rsa -in demo_private_key.pem -pubout -out demo_public_key.pem
Here is the cat of the file (again we would never publish actual private keys - this is just for a learning exercise):
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
And the corresponding public key:
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
Now go to https://gchq.github.io/CyberChef/
Generating a digital signature in CyberChef
Search for "RSA Sign" and drag the block to the "Recipe" box
Copy and paste the private key above into the "RSA Private Key (PEM)" Box
Change the "Message Digest Algorithm" to SHA-256
Input data in the Input text box to be signed (enter: "Bob hates Java")
Under the search bar, search for "To Hex" and add it to the recipe to format the output nicer in a hex dump
Notice how any change to the input data will change the digital signature
Verifying the digital signature in CyberChef
In the recipe window, disable the "To Hex" block by clicking on the following icon (see above)
Copy the public key above into the "RSA Public Key (PEM)" box
Change the "Message Digest Algorithm" to be SHA-256
Input the same ASCII text that was signed above in the input box (i.e. "Bob hates Java")
Note that the "Verified OK" appears in the Output box
Change the input data and note that the verification fails
Employing firmware signing makes it much harder for a hacker to upload malicious instructions during the firmware update process. This keeps cars running vetted firmware and not backdoored firmware like was done by Miller and Valasek.
Thanks for reading - if you liked it - please consider sharing on LinkedIn.
 By FlippyFlink - Combined changed the image https://en.wikipedia.org/wiki/File:Public_key_encryption.svg from encryption to signing., CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=78867393