ECDSA: What is the purpose of adding a hash of the used certificate to the signed data?

Question

I recently started looking into security mechanisms used for Car2Car communication according to DSRC/WAVE and ETSI.

What I found so far is that each packet is signed using ECDSA mechanism. Also each packet either contains the certificate that is used for signing or some hash value identifying that certificate. This certificate contains the public key that can be used to verify the signature.

What puzzles me is the way the signature is created. I am aware that not the whole message is used for signing, but only a hash value. But the way this hash is created, looks a bit strange to me:

Hash ( Hash ( Data ) || Hash ( SignerInfo ) )

where Data is the message or part of the message to be signed and SignerInfo refers to the certificate in use (or to an empty string in some cases).

Why is this second part required?

Hashing the message as well as hashing the certificate does not include any secret credential as both are transmitted within the message.

Given the public key from the certificate I can validate that the related private key was used for signing.

While the length of the 2 hash values isn't very large, it still means that I have to run a second round of hashing which is probably not done "just for fun".

Which benefit do we gain from this extra step?

Answer 1

It is probably a countermeasure to multi-user attacks.

In the classic (single-user) attack scenario the attacker wins if she manages to create a valid signature under a given public key, without knowing the private key. (note that a it is not request to obtain the private key, but just one valid signature)

In the multi-user scenario, instead, there are multiple public/private key pairs. And the attacker wins if she's able to create one valid signature under just one of the given public keys (the attacker can choice the target one).

The multi-user attack is believed to be easier than the single-user attack. The high level idea is that the attacker's computation can be reused against any of the allowed public key, thus increasing its efficiency.

A common countermeasure, introduced in ed25519, is to create a stronger bond between the signer and the signature by including in the hash computation the signer's public key. What you describe in the car2car scenario looks similar to that countermeasure as the forger needs to create hashes of the messages which include the signer's identity. This most likely remove the multi-user advantage compared to single-user.

Bernstein showed that adding the signer's key in the ed25519 hash computation protected against multi-user attacks. Klitz et al. later showed a reduction from the multi-user to the single-user. Bernstein, however, disagrees with the paper conclusions.

To summarize, IMHO, adding the signer to the hash is very efficient and seems to provide a generic solution to concerns about multi-user attacks, while the reduction between multi-user and single-user for signatures is still unclear.