Revision as of 09:10, 7 March 2013

Introduction

The password negotiation protocol is a prelude to the secure M3DA protocol. The idea is to generate a new password at the first connection. The rationale is easier password provisioning on the client side : in place of provisioning in both client and sever a password different for each client, you can provision same "negotiation password" (also called pre-shared key) on a batch of client. It will be used at the first connection for connecting with the server and receiving a new unique and random robust password. Once the new password is generated and saved on the both it should close side (client and server) it will be used for authentication and ciphering all the future communications.

Definition

The login is defined as the device unique identifier (see "agent.config.agent.deviceId" in Mihini). The registration password: is an input of the generation process, it's provisioned along with Mihini on your client platform. The used password is generated using a well known cryptographic function: HMAC/SHA1 (http://en.wikipedia.org/wiki/HMAC) as follow: password = HMAC(presharedkey, login)

Security limits

If a third party know the client unique identifier (usually easy: this is semi public information, like S/N, IMEI) and the negotiation password (vulnerable because shared among several devices) then he can deduce the credentials used by all devices. The device itself is not protected among local attack: local access would allow the attacker to retrieve the negotiation password : protect your negotitation password and try to change it often.

Password negotiation protocol

If the M3DA client want to start communication with the server for sending some data and have no final password it will start the "password neogication protocol" for acquiring a final password from the server before sending the data.

The whole protocol is using only empty M3DA envelopes, the payload is only in the headers of footers.

Step one : salt exchange

For avoiding replay attacks, the first step of the negotiation is to exchange random binary chain to be used as salts for the next communications.

The client start by sending the client salt, it will trigger the negotiation protocol start on the server. if the server have previosly negotiated a password with this client the session must be closed by the server.

The client salt must be used by the server for the next authentication phases.

The server will send the server salt in exchange. The client must use it for its next authentication messages.

Step two : Elleptic curve Diffie-Hellman key exchange

Before being able to transfer a new final password from the server to the client, the two endpoints need to create a shared secret for ciphering the password message. For that we use the Elliptic curve based Diffie-Hellman algorithm (ECDH): http://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman with the NIST standardized curve P512.

When the client received the server slat it generates a ECDH key pair and send the public key to the server in a secured envolpe signed with the salt and its public ECDH key.

When the server receive the client ECDH public key, it first authenticate the message checking the signature. If the signature is not matching the server should close the session. When the message is authenticated, the server generate its ECHDH key pair and generate the ECDH shared secret.

The server generate the final random password and generate a MD5 hash of it. The MD5 hash of the password is XORed with the ECDH shared key.

The server send a reply to the server with : the XORed MD5 of the final password and its public ECDH key in an authenticated envelope (HMAC of the message with the client salt and the negotiation password).

Step Three acknowledge

The client receive the ciphered final password md5 and the server public key. If the message is authenticated the client save the new password and send an acknowledge message to the server.

The client authenticate the message, save the password in flash and send an authenticated acknowledge message to server.

Starting from there the client and the server will use the new password MD5 for mutual authentication and ciphering.