Let's say we have:

  • client_id_ran: 256 bit random text (chosen only once for whole system) used to generate client_id by incrementing 1 for each client.
  • challenge_ran: 256 bit random text (chosen only once for whole system) used to generate challenge_plain_text by incrementing 1 for subsequent authentication requests.
  • challenge_plain_text: generated from challenge_ran as specified above.
  • client_id: generated from client_id_ran as specified above.
  • server_secrect_key: random 256 bit text
  • client_secrect_key: pre-shared / configured at industry to AES256(ENCRYPT,server_secrect_key, client_id);

Authentication procedure:

  1. client request for challenge_plain_text by sending client_id

  2. Server response with the AES256(ENCRYPT,client_secrect_key, challenge_plain_text);

  3. client decrypts the massage by client_secrect_key to get challenge_plain_text

  4. client encrypts the challenge_plain_text_increamented_by_one with the client_secrect_key and send back to the server. i.e, AES256(ENCRYPT, client_secrect_key, challenge_plain_text_increamented_by_one);

  5. server decrypts the encrypted_challenge_plain_text_increamented_by_one by generating client_secrect_key from client_id. if(decrypted_challenge_plain_text_increamented_by_one == challenge_plain_text_increamented_by_one && response_time<=4000ms), client authenticated else connection closed.

AES_ECB mode is used for encryption & decryption of 256bit texts. Hence challenge_plain_text_increamented_by_one should be achieved by incrementing each 128bit part of 256bit text by one.

The proposed plan is for authenticating IoT devices where we can save the client_id & client_secrect_key to the device before delivering to the customer.

  • 1
    $\begingroup$ AES is a 128 bit block cipher, it is not defined for input other than 128 bits. Usually a MAC is used instead of the block cipher itself for these kind of purposes. $\endgroup$ – Maarten Bodewes Dec 8 '18 at 11:47
  • 4
    $\begingroup$ We're cryptographers, it's our job not to ignore the little things. You've just published a draft to us, can we please expect it to be written to the best of your abilities? Yes, the block size is 128 bits. So how do you define AES256(client_secrect_key, challenge_plain_text, ENCRYPT) if challenge_plain_text is 256 bits? $\endgroup$ – Maarten Bodewes Dec 8 '18 at 12:21
  • 1
    $\begingroup$ As mentioned by SEJPM, a MITM could just pass the authentication data unchanged, and then modify the application data at will. Because of this, there has to be some cryptographical binding (e.g. encryption/MAC keys) between the authentication and the rest of the exchange... $\endgroup$ – poncho Dec 8 '18 at 14:57

If the goal of this protocol is to authenticate the user, then it falls rather easily to a man in the middle attack.


  • By passively sniffing on the real server's traffic figure out the current value of challenge_plain_text.
  • Impersonate the server.
  • As soon as you get a request from any client, accept it and record the client ID.
  • Send a challenge_plain_text back to the client which you expect to be used soon by the real server.
  • Receive the encryption of said challenge from the client, you may now ignore the client or fake successful authentication.
  • Now to impersonate the client from whom you just got the response to the challenge wait for the moment where the next authentication will use the challenge_plain_text you used.
  • Now claim to be said client and request authentication.
  • You will get the challenge_plain_text for which you have the answer, respond with it and be authenticated.

This works as all the values are easily predictable. A rather simply mitigation would be for the server to always pick a fresh random value for each authentication request. But then still the attacker could perform a man in the middle attack and "authenticate" as the client thinking the attacker is the server to the real server by doing a simple pass-through of all messages.

| improve this answer | |
  • 1
    $\begingroup$ Other mitigations: somehow including the ID in the challenge (use a MAC to extend input range) or even better: using different keys for client and server. $\endgroup$ – Maarten Bodewes Dec 8 '18 at 11:46
  • $\begingroup$ @DebabrataMandal I don't have time for a proper explanation now, bnut will probably provide one within 24h (if not ping me again). The short version is that for the second mitm attack the attacker will behave like any server en-route of the data packets and just modify the metadata to claim it's them who is requesting authentication but still forwarding everything. Mitigations against this are more difficult. The 4s timelimit should be no problem for any of the attacks. $\endgroup$ – SEJPM Dec 8 '18 at 12:41
  • $\begingroup$ @DebabrataMandal well for that one, remember that the attacker picked a challenge_plain_text from the future, so they observe the current authentication requests to and from the server and as soon as the the one for which the attacker already has an answer is next, they request authentication and use the saved data. $\endgroup$ – SEJPM Dec 9 '18 at 13:26
  • $\begingroup$ As for your previous comment, the idea is that the attacker knows that these values are incremented, thus they pick a value of eg +50 when they impersonate the server to the client and then after 49 new requests to the server they have their chosen challenge_plain_text is next and they can successfully resend the saved messages. $\endgroup$ – SEJPM Dec 9 '18 at 13:28
  • 1
    $\begingroup$ @DebabrataMandal I would indeed strongly recommend you to just use TLS 1.2 or 1.3 with the pre-shared key ciphersuites / handshake if possible. $\endgroup$ – SEJPM Dec 9 '18 at 18:02

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.