# Lightweight NFC Protocol for Privacy Protection in Mobile IoT
## 4 Security and Performance Analysis  
### Security Analysis  
In this section, we give the security analysis of our protocol. * Tag Anonymity In an authentication system, we often use ID to distinguish the different devices. The ID represents the identity of a device in the IoT system. Once it receives a message, the server searches for the other authentication information by ID. If we send the ID directly in an unsafe channel, attackers may falsify the tag's identity or analyze the tag's behavior. The identity information is private information that should be protected. In our scheme, we use \(VID\) to protect the device's identity, which can be understood as encrypted ID information. \(VID\) maintains the anonymity to readers and even sniffing attackers. Even if the attacker gets the \(VID\) in some way, it does not make sense as the \(VID\) will also change after each communication. Anonymity is one of the requirements of a secure authentication system. * Replay Attack Resistance A replay attack refers to an attacker intercepting a certain step message on the communication channel and repeatedly transmitting and using it. In our scheme, we use random numbers to keep every message fresh. Even if the attacker obtains the data of the tag and the mobile phone communication in some way, the next communication's details cannot be predicted as we generate a random number each time. Thus, it can be seen that our protocol is effective against replay attacks. * Consistent De-synchronization From step 6 and step 8 we achieve the update and synchronization of the device key. In step 6, the server receives the message and generates the secret device key that is used for the next session. In step 7, we update the phone's secret device key. In step 8, we update the tag's secret device key. After doing this, the key synchronization is completed. Due to uncontrollable factors such as network problems, the tag and phone may not receive the Synchronization message, which will cause the de-synchronization problem. In order to solve the problem, the server side will also store the old device key while generating the new key. Figure 5: The proposed authentication protocol. The protocol also achieves the mutual authentication between the tags and the mobile phone, the mobile phone and the server, and the tags and the server. In step 4, after the server receives the message from the mobile phone, if it can be decrypted normally, the mobile phone and tag are considered legitimate. Then the server sends \(mp\oplus Kp\oplus Kgroup\) to the mobile phone and sends \((Token|K\oplus ms)\oplus Kgroup\) to the tag. After checking this, the phone believes that the server is legitimate and then transmits \((Token|Kt\oplus ms)\oplus Kgroup\) to the tag. In step 5, after checking, the tag believes that the server is legitimate. On the other hand, if the tag receives the right message from the server, it means that the server believes that the phone is legitimate. Thus, the tag also believes that the phone is legitimate. Thus, our protocol achieves mutual authentication. Anti-DoS attack  
The possible avoidance of denial of service attacks is shown in steps 4 and 6. In step 4, we solve the DoS problem by step-by-step querying: checking before computation. Once the server receives the message \(VIDp||(\bullet||Kgroup\oplus IDp||\bullet)\oplus Kp\), it uses only one query and two XOR operations to check the phone's identity. Firstly, the server searches for \(VIDp\) in database so that it can get the phone's information item. Then it checks if the \(IDp\) is right. If \(VIDp\) does not exist in the database or if the check fails, the protocol will stop. Only after ensuring that the phone is legitimate does the protocol go to the next step. In step 6, the server uses three XOR operations to check if the message is legitimate. Only after ensuring that the message is legitimate will the server generate a new random number.