I saw this design recently in an infotainment product. The goal is mutual authentication between two ECUs, E1 and E2. They only care about each other. The basic idea is to keep both keys secret and let each ECU have one. Let's call the keys k1 and k2, instead of public key and secret key, or E and D. Both keys are large.

Suppose E1 has k1, and E2 has k2. To perform mutual authentication in a cost efficient way:

  1. E1 generates random data D of a fix length, and encrypts hash(D) with k1, resulting in S1. D and S1 are sent to E2.
  2. E2 decrypts S1 with k2, and check if it matches hash(D).
  3. If OK, E2 calculates the binary complement of D, denoted D'. Then it encrypts hash(D') with k2, resulting in S2. S2 is sent to E1.
  4. E1 calculate D', decrypts S2 with k1, and check if it matches hash(D').

I have a hunch this design is risky, but fail to find the weakness. Is it secure enough in the real world?

Edit: I see there is replay attack again E2, but the "master" node, E1, can never be fooled, right? I guess the use of D' may leak some chance of MITM attack, but it's complicated to find any.

  • 1
    Any reason you can't use standard stuff for this, e.g. what TLS does? Also, you'll have to roll your own crypto to do this -- all the stuff I know is predicated around keeping only secret keys secret, so it generates keys and handles them accordingly. – Nic Hartley Oct 3 at 0:41
  • 1
    @NicHartley: The OP is asking about the security of an existing system ("I saw this design recently in an infotainment product") and not if he should implement such a design himself. – Steffen Ullrich Oct 4 at 6:30
  • @SteffenUllrich Thank you! It's not my design, and I don't like it, either. – wdscxsj Oct 4 at 7:42
  • Oops, so he does -- I skipped right to the protocol description, hah. – Nic Hartley Oct 4 at 17:36

Don't make your own crypto.

I see a MITM potential there, since an attacker could copy the mutual authentication tokens and change the rest of the communication, but there's probably some hidden risks behind the RSA primitives you are using and the data you are transmitting.

Why not use at least a couple of keys, anyway?


The only reason I can imagine for using that scheme is to avoid using 2 key pairs due to technical reasons (for example, not enough available space in the memory system seams reasonable to me for an infotainment system).

If that's the case I suggest using a symmetric cryptographic algorithm with its corresponding secret key since it looks like you only need to protect the confidentiality and integrity of the message on transit, and you can achieve that by using symmetric cryptography.

Furthermore, it looks to me that this design is abusing public key cryptography to fit a use case that requires the use of a couple of key pairs for its appropriate use.

As said before by other people, since cryptography is a complicated science you better don't mess with it unless you are forced to do so, if you can choose, then make a sensible decision and use the standards to its maximum extent.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.