CAN message usually has max 8 bytes, how would you sign it to actually transfer some useful data and without signature being laughably simple to crack?
Just use a simple rolling code, like a garage door opener, HOTP, or the key fob itself, and enforce a rate limit for bad codes. 3 bytes can hold 6 packed digits, which is plenty.
The threat model here is that the thief walks up to your car and tries to broadcast messages to the door controller. If they can't observe prior messages to the controller, the chance that they will correctly guess the next code is, literally, 1 in a million.
Let the door controller start rate limiting (ignoring messages) after 10 bad attempts, and then only listen to one code per second. The thief will have to stand here for a week for a 50% chance of correctly guessing a 6 digit code.
Congratulations. Everyone is now potentially DDoS'ing everyone else's car, and all it takes is one a-hole with a gibberish screamer to lock everyone out of their cars within range.
You have solved nothing, and in fact, made plain old keys the more attractive alternative. I swear, people want to throw cryptography, radios, and security buzzwords at everything, but completely forget that the easiest way into the car will be taken. The tumbler lock. Once in there, hoods can be popped. Replace brain box. Move right along.
The signing key would of course be unique per ECU/keyfob that needs to sign stuff so dumping another ECU doesn't help you crack it.
Loading a new private key from the server? Well, thief's device can probably pretend to be a server and load a new private key into the control unit behaving as a master of immobilizer. Then the thief will get car and instantly new set of keys.
Erm... using the LSB of a network RX timer is common way to add entropy (and perfectly feasible here). You could also use the LSB of the +voltage rail sense or the thermometer that probably exists on your MCU.