On the mobile app client side. When enter the correct user name and password the client opens TCP socket and sends request to the Lock to connnect.
Once the connection is built, the client is able to generate a random number and hash this number with its intermediate key to create a MAC. The client sends its fixed challenge, random number and MAC to the server. If the authentication is successful, the user is able to unlock the door by pressing the unlock button as shown below:
The following picture shows the scenario where the wrong password is enter. The terminal window shows the login error:
The lock can also can generate a temporary user that is able to get the access to the lock for certain amount of time.
On the lock server side, when it connect to an access point, a server TCP socket is open and it start listening. When the server accepts the request from the client, it receives the client's fixed challenge, random number and MAC. The Server then generates the server's intermediate key by using the client's fixed challenge and Atmel's secret key. The intermediate key is then hashes with the random number to get the server's MAC. By comparing the MAC the server generates with the client's MAC, the server is able to send the response message back to the client.
The following picture shows the successful authentication scenario:
On the lock server side, when it connect to an access point, a server TCP socket is open and it start listening. When the server accepts the request from the client, it receives the client's fixed challenge, random number and MAC. The Server then generates the server's intermediate key by using the client's fixed challenge and Atmel's secret key. The intermediate key is then hashes with the random number to get the server's MAC. By comparing the MAC the server generates with the client's MAC, the server is able to send the response message back to the client.
The following picture shows the successful authentication scenario:
The picture below indicates the server receives a random number that is sent before. When received the used random number, the server sends the authentication failure message to the client.
If the fixed challenge of the mobile device is not valid, the lock generates a intermediate key that dose not match the client intermediate key, the resulting MAC is also different from the one generated by client. This scenario is shown below:
The Parse cloud stores every unlock attempt (successful and fail attempts) sent by the lock server. The picture below shows the Parse cloud data base for this project: