Security analysis of this one time password based scheme for copy protection

Question

Imagine such protocol. Client and server initially share secret K[0].

1. When client wants to contact server she sends server K[0] and her ID.
2. Server accepts request, and generated new random K[1] and sends it to client which should use this in next communication.
3. Again, if client wants to authenticate with server now, she sends K[1]. Server accepts it if correct, and sends here K[2] to use next time and so on.

My first question is: Is there some name to this protocol in the literature? (Where security of this protocol has been studied?).

I want to use it for detecting if someone copied software of my client.

For me this scheme works most of the time: because if someone copies the client software it means the copy of the original software, will send say K[n] th password to server who will generate next password for client K[n+1]. But this way original client will go out of synchronization with the server because she will use old K[n] to authenticate and we will detect this - and achieve our goal.

The only attack I can see on this protocol if man in the middle just forwards clients messages to server and servers response to client. Someone can present security analysis of this scheme?

Answer 1

Is the motivation for this a copy protection scheme?

If so, the most obvious problem is that if $K[n]$ is transmitted by the server but not received by the client, then synchronisation is lost.

This could happen if there is a proxy in between as is often the case in corporate networks with HTTP (or more controversially HTTPS) traffic. The updated value could be transmitted to the proxy but not downstream to the client. At this point, the application is irreparably broken.

Is this one-time password being transmitted over a secure channel? If not, then the following problems also apply:

How does the client authenticate that the $K[n]$ really came from your server and not someone else?

How does the server authenticate that the $K[n]$ provided to it, came from the client and not some third party?

If the one-time password is used to authenticate a message came from a valid host, how do I stop the message being modified in transit?

Answer 2

That's not going to work. You've even found the gist of one of the main flaws:

The only attack I can see on this protocol if man in the middle just forwards clients messages to server and servers response to client.

Specifically, you get one central proxy to forward the messages and store the current value of K[i]. Each time one of the clients connects, the proxy replaces the client's K[j] by its the current K[i].

You could try to prevent this attack by having a signed connection between the client and the server. After all, TLS prevents man-in-the-middle attacks. But that only works if the client wants to avoid MitM, and here the client won't be cooperative. The client would need to protect the private key it uses for signing, or to verify the server's public key, but in your scenario the client is not under your control.

You can try to obfuscate the cryptographic operations performed by the client so that its message signing and verification is tied with the useful work that it does, and the key can't be extracted easily. Such techniques don't work against motivated, competent attackers but they can deter casual attacks (as in, it'll probably take a few months before someone publishes a crack). However, even that won't help you. The client needs to store the last K[j] that it received somewhere. If someone wants to make multiple copies, all they need is to have the proxy broadcast the new K[i] each time it makes a request, or have the proxy send the latest K[i] to each client when it reads it. Since the clients are identical, a K[i] that's good enough for one is good enough for the other, so neither your client nor your server has any way to detect this.

In addition, your proposed protocol has an inherent reliability problem: the client and the server can go out of synch, for example if the client crashes immediately after downloading a new K[i]. You'll have to allow this somehow, and this gives one more opportunity to bypass your protocol.

Detecting that software was copied is impossible, unless the software is only installed on hardware that's under your full control and that's tamper resistant. If you aren't in control of the hardware, then whoever is in control of the hardware can make identical copies of the environment (hardware and operating system) and run identical copies of the client. Don't waste your time on it.