# Is the following authentication protocol insecure?

I am a student taking cryptography this semester. I was just wondering why can't we use this simple protocol?

Alice → Open Connection → Bob
Alice ← Cert$_b$ ← Bob
Alice → {K$_{AB}$}$_{Bob}$ → Bob

Assume bob is the server and we're only interested in one way authentication.
Is there anything wrong with it in terms of security and performance?

-
Totally insecure... I assume $K_{AB}$ is chosen by Alice? What is the indication for Bob that he talks to Alice? –  DrLecter Dec 19 '13 at 12:13
Alice does not know she got Bob's certificate (if Eve can tamper with the messages). Bob has no clue at all, who he is talking to. No authentication at all. –  tylo Jan 16 at 15:35

Security wise, it's susceptible to a replay attack since no nonce or timestamp is used. Alice is also not authenticated, only Bob is.

As for performance, since there is no preshared secret, one pki operation is needed. So it's quite efficient as it's only two pass.

-
How should Bob be authenticated? Eve sends Bobs certificate and Alice believes it talks to Bob... –  DrLecter Dec 19 '13 at 12:18
Bob is authenticated if he is able to use his private key to decrypt the correct value of Kb. Bob can repeat the same two pass protocol to authenticate Alice. i.e. encrypt a nonce with Alice's public key and get Alice to decrypt it. –  jingyang Dec 19 '13 at 12:23
That's not stated in the protocol description... –  DrLecter Dec 19 '13 at 12:26
I think this should usually be implicit. If you look at the ISO authentication protocols, such things are also not explicitly stated. –  jingyang Dec 19 '13 at 12:41
Bob is not authenticated at all. Let's assume when the protocol steps stated are done, then Alice and bob start talking over an encrypted channel with $K_{AB}$. But Alice can not be sure she is talking to Bob, because in the protocol she only got a certificate (it could be Eve's) and she talks to who ever was able to decrypt a message to the owner of the certificate. –  tylo Jan 16 at 15:33

For one-way authentication (where Bob is the server and Alice the client), I would rather do something like this:

Alice → Open Connection → Bob
Alice ← $R$ ← Bob
Alice → $K_{A-B} (R)$ → Bob

By using a “once-in-a-lifetime” value $R$, and then checking the returned value, $K_{A-B} (R)$, Bob can be sure that both Alice is who she says she is (since she knows the secret key value needed to encrypt $R$) and is "live" (since she has encrypted the nonce, $R$, that Bob just created).

Now…

Your description looks pretty similar but it notes a $Cert_b$ which I interpret to be a certificate. A certificate does not represent a “once-in-a-lifetime” value. In your case, Bob would not be sure if Alice is "live" because the certificate data could have been collected/intercepted at an earlier time… potentially by Eve instead of Alice. As a result, authentication would fail secure verification in your protocol description. In the end, you're facing the possibility of crashing into a replay attack by Eve when doing it your way.

-

Bob needs proof that Alice is authentic: A-Open Connection-Cert partial random key->B Both keys combine to form an access key.

Standard one-way authentication protocol only requires submitting a correct password once, in order to gain access and control. By randomizing part of Alice's password, significantly reduces the likelihood of her password becoming victim of replay attacks and man-in-the-middle-attacks, just to name a few. [Random Assymetric] Bob's server has been preset for random variations of Alice's hash value

• Is there anything wrong with it in terms of security and performance?

Technically speaking, there is nothing wrong with your suggested one-way authentication protocol. However, the security function of your protocol can be increased by preconfiguring Bob's server with random hash variations of Alice's password for added security. Best of luck with your protocol

-