# preventing reflection attack

I was reading the solution to the reflection attack and have some confusion as to how Alice would know Bob is a liar and isn't really Bob.

1. Alice initiates a connection to Bob
2. Bob challenges Alice by sending a nonce. B -> A: N
3. Alice responds by sending back her identifier and the nonce encrypted using the shared key Kab. A -> B: {A, N}Kab
4. Bob decrypts the message, makes sure its from Alice and not a message he had sent in the past by finding A in it and not B and if the nonce is the same as the one he sent in his challenge then he accepts the message.

Step 4 is where I get lost. So Bob can use the key to decrypt and retrieve "A". First off what does it mean in the notation when a senders name appears in the message? If we have A-> B:{A}, or just A-> B:A what does the A after the : mean?

In part 4 it seems like it's saying once Bob decrypts the message he can "some how" verify if the sender was really that person. I don't get the "some how". In implementation would A be the IP address of a machine, and since a node always knows who's connecting to it, it will be able to decrypt to 8.8.8.8 and know the actual sender was 8.8.4.4 ?

A -> B: {A, N}Kab means that A sends to B a message containing A and N, and encrypted with a secret key shared by A and B.

So Bob can use the key to decrypt and retrieve "A".

No, Bob uses the key to decrypt the response and retrieve the nonce N and the identifier A. From this, Bob knows that the response

• contains the nonce N Bob sent beforehand;
• contains Alice's identifier A and therefore has been sent by Alice, and is not a replay of a nonce Bob sent in the past;
• is encrypted with the shared secret key, so it must come from Alice which is the only party, apart from Bob, that knows the secret key.

I must say that the Wikipedia explanation is very confusing to me.

The responder sends its identifier within the response so, if it receives a response that has its identifier in it, it can reject it.

Based on the forth step, i assume that they meant:

The responder sends its identifier within the response so, if the challenger receives a response that has its identifier in it, it can reject it.

Which adds a notion of ownership of the answer. Now, this is how i understand the problem and solution:

Forget cryptography and IP addresses and think of a real case. You are in the classroom and, even though you are a lazy bastard, you feel lucky and you want to answer a complicated question (challenge), just for nerds. Assume the question is always different(nonce). Your teacher asks you the question but (as expected), you don't know the answer but you still want to look cool, so, you ask the nerd kid behind you (responder), telling that the question was for him. Assume that no one notices (you can scream: hey look Diffie-Hellman outside the window!!).

You pick the answer and you say it out loud to your teacher as yours. It is correct and you save the day. What is one of the problems here?:

Knowing the answer, you can easily announce it as yours since it is not bound to a person.

The first line of defense would be to have shared keys between the nerds and the teacher (dumb kids speak plain) and have them encrypt their messages. Only smart kids would be able to encrypt an answer (nonce). Yet, another problem arises:

You are clever enough to ask the question to the nerd kid and get the jibber jabber from him (encrypted answer) and replay it to your teacher (here replay does not mean replay attack, you are just saying what the kid said previously).

The teacher accepts the solution because, even though only smart kids can answer and encrypt, there is no way she can tell if the answer was truly yours. There should be a way for her to find out:

Introducing, identifiers: every answer is encrypted with the name of the kid and the problem is solved. In the real world, it is possible for a person to validate this easily: teacher gets answer from you but identifier is from the kid which leads to a mismatch.

In IT world, a way would be, as you said, to use IP addresses.If the attacker sends a message with the IP of another pc, it won't work. Sure he could spoof the source to match but you couldn't establish a connection. This could work if the application was a simple command executor: attacker sends the command self-destroy and the other pc would destroy itself requiring no ACKs or further message exchanges.

Stay safe ;)