2
$\begingroup$

Consider following authentication protocol.

Client ClientA knows some initial secret KeyA shared with server. Client also knows IP of legitimate server.

Now when client wants to establish connection with server she will send KeyA to server and her ID (for server to know which key to use).

The server generates new random number Key1A and sends back to client. Now following request will only be accepted if Key1A is sent by the client along her ID. When client sends another request with Key1A, server will generate Key2Aand send to client, and etc.

Now if attacker captures say KeyAn - if she uses KeyAn, it means client will not be able to communicate with the server anymore - because the server will have generated KeyAn+1 already. And expect only KeyAn+1 which the client will not know if attacker used KeyAn already. We will detect that one client with ID clientA "died" - because ID is also sent to the server. And disable request from clientA.

Does this provide identification of client in a secure way? If no how can I improve this protocol such that if attacker steals some secret and tries to authenticate with server instead of some client A (from a different computer though), then at least I can detect it?

Improve this question
$\endgroup$
13
  • 2
    $\begingroup$ As stated, the thing does not even work reliably in the absence of attacker: it does not recover if Key1A does not reach the client for some reason. In presence of an attacker, it is unsafe in many simple attacker models, including capability to eavesdrop and suppress the first message sent by the client. $\endgroup$
    – fgrieu ♦
    Dec 4, 2015 at 14:04
  • $\begingroup$ If I'm reading this right, you send the authentication tag to the client before the client should use it. So if some man-in-the-middle gets the tag (server->client), he can use that to make queries in the name of the client? $\endgroup$
    – SEJPM
    Dec 4, 2015 at 14:05
  • $\begingroup$ @SEJPM: Let's assume there is safe way to get the initial secret to the user. $\endgroup$
    – user29112
    Dec 4, 2015 at 14:10
  • $\begingroup$ @fgrieu: Yes but in that case attacker only will forge one message other messages will be detected because client can't communicate now anymore $\endgroup$
    – user29112
    Dec 4, 2015 at 14:11
  • 1
    $\begingroup$ @user200312: Positively no! If an attacker eavesdrop and suppress the first message sent by the client (containing KeyA), that attacker can now impersonate the client indefinitely, simply by applying the protocol as the client would do; and impersonate the server to the client. $\endgroup$
    – fgrieu ♦
    Dec 4, 2015 at 14:17

1 Answer 1

Reset to default
2
$\begingroup$

There are a few issues with your protocol. Namely it doesn't protect against men-in-the-middle.

Issue #1 (mentioned by fgrieu in the comments): Assume I host one of the (many) servers all your IP packets have to travel through from ClientA to Server. If I drop the server's Key1A (or KeynA) any future request won't work and I have successfully denied your user the usage of the server. He will have to re-perform the secure initial secret exchange which is likely expensive.
While this won't break the protocol in the sense you're interested in, this is still potentially harmful as it may cost you money (by losing customers being angry about the unrelieability of your protocol) if you need to do an expensive renegotiation (which involves human interaction?) too often.

Issue #2: If I don't just drop the packet, but flip a single bit, the client will get a wrong key and the server will assume the client has been successfully broken, so your legitimate client will be angry at you and has to re-perform the secure exchange. (see issue #1)

Issue #3: If I can eavesdrop on any of the server's responses and I'm able to drop all users packets, I can successfully take over the role of the client.
You send the next valid token in each of your server's responses and if I can get my hands on that and one valid client request (for getting the ID) I can successfully use said ID and the valid token to make my own requests.
All I have to ensure is that the client won't make any requests himself until I've finished all my evil requests.
The time-frame I need may be relatively short (a few seconds or minutes maybe) and I may be very well able to pretend the server is offline for maintenance for this time-frame. Or I could just launch a packet flooding attack on the client (which probably doesn't have more than 100Mbps bandwith?).
You shouldn't rely on an attacker not being able to DoS your client just because "it's not easy", a good protocol wouldn't create this situation in the first place (and the below mitigation should fix this issue anyways), for example you could avoid sending the next valid token at all,
but cleverly use HMAC to only send derived values and thereby only send the next valid nonce.

Issue #4: If the client actually is some piece of software that should authenticate to the server, I as the (not-so) legitimate user can extract the full program state from RAM / disk drive and just copy it over to another machine to perform my evil requests from there, and maybe I even install some software (like increasing packet loss or just root-level blocking the application) to make sure the legitimate client needs some time to figure out, I stole his credentials. This will be detected, but I still have some time (minutes up to days) to make my evil requests which may cause serious harm to the system and make you lose customers / money.

I hope this points the main issues of your protocol out (if anyone finds any else, please comment / answer yourself).

Now for the improvement.

The best thing to do is: Don't roll your own crypto.

The easiest way to mitigate the issues #1-#3 is by simply using your protocol on top of server-authenticated TLS. This would mean a modified packet would never reach your client application, the server would notice (thanks to record numbers / TCP) if a key didn't reach the destination and an eavesdropper wouldn't be able to read the valid tokens (and mitm is mitigated if the client checks the certificate properly). To fully mitigate man-in-the-middle attacks, you have to deploy DNSSEC along with TLS (and maybe DANE if you're at it) which would ensure you get the correct IP from the domain name for which you know the correct certificate (and can cross-check via DANE) and would allow you to drop the "known IP" requirement.

Issue #4 can't be mitigated with a pure software solution. I can go ahead and copy the state of any program (if I'm root / admin on a PC) and continue running it somewhere else (at least for some time). You need to use a hardware solution in order to ensure that a specific PC was used for a specific client or the client will be able to just shut-down his PC and copy the app to another one (in the same network?) and run it from there. The cheapest approach to this is using the TPM many modern PCs have (and which Windows 10 will require as of july 2016 for Windows 10 logo certification of PCs)

Improve this answer
$\endgroup$
11
  • $\begingroup$ " If I drop the server's Key1A (or KeynA) any future request won't work " - Yes but in this case I have detected something is wrong. That is good for me. I will keep on reading other part now ... If I can detect a fraud that also suits me $\endgroup$
    – user29112
    Dec 4, 2015 at 20:01
  • $\begingroup$ " All I have to ensure is that the client won't make any requests himself until I've finished all my evil requests."and that's not easy $\endgroup$
    – user29112
    Dec 4, 2015 at 20:01
  • $\begingroup$ Your issue 4 is wrong if you copy program elsewhere, I will detect this because old clients attempts to authenticate will fail. Please address my comments $\endgroup$
    – user29112
    Dec 4, 2015 at 20:02
  • $\begingroup$ I think you are not getting essense of this protocol if you copy my program, this means from other computer you will continue sending packets - this means old client will go out of synch with server, and get denied access - which I will detect and raise alarm. Can you address this by maybe adapting your answer to my comments? $\endgroup$
    – user29112
    Dec 4, 2015 at 20:05
  • $\begingroup$ What about fgrieus comment "Positively no! If an attacker eavesdrop and suppress the first message sent by the client (containing KeyA), that attacker can now impersonate the client indefinitely, simply by applying the protocol as the client would do; and impersonate the server to the client. " -honestly, I don't get what he means here $\endgroup$
    – user29112
    Dec 4, 2015 at 21:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.