4.1. Security Analysis
Table 2 shows whether the proposed as well as existing schemes support multiplatform, is designed to consider the security considering the low resources of the device with small computing and battery power, and whether it protects the user’s privacy. Also,
Table 3 shows how much the proposed as well as existing schemes are secure from the various security threats. The proposed protocol provides mutual authentication between sensor and gateway, gateway and SP and sensor and SP. In the proposed protocol, TTP acts as distributed KS that guides the sensors and SPs secure from relay attack, replay attack, eavesdropping, leaked key, and forward security threats, helps them authenticate each other, and share session keys. Besides, when compared with conventional system, the proposed system is more stable and ensures privacy, supporting the low cost of a smart home sensor and the multiplatform environment.
Multiplatform: In this smart home infrastructure, which ensure users’ privacy, smart home sensors with PUF chips, gateway, and service providers have reliable TTP and organically communicate with each other through it. This infrastructure designed TTP to own PUF DB, so multiplatform service providers or sensors can build a secure channel through mutual authentication, without prior information. It designs the gateway to authenticate service providers and sensors with information it receives from TTP and to build a secure channel. As a result, the smart home infrastructure proposed in this paper solves the issue of heterogeneity and prior information exchange in a multiplatform environment.
Privacy: Privacy exposure in smart home environment is not an issue of a single individual, but a grave threat to his/her whole family. To tackle problems such as malicious eavesdropping or exposure attributable to user’s recklessness, the proposed smart home infrastructure and protocol proposes building multi-security channels, not simply station-to-station security channels, between smart home sensors and the gateway, between the gateway and the service providers, and between service providers and home sensors, to prevent the leakage of privacy in advance.
Relay attacks: A malicious attacker may try to perform a relay attack between a sensor and the gateway or between the gateway and SP, but if the malicious attacker sends an authentication request to the gateway while disguising him/herself as a sensor, the attacker may get the values transmitted from SP, but they are not valid and useful as public values. PUF Response R values necessary for producing a session key are transmitted in a hashed state and can be produced from physically unclonable PUF. Therefore, it can’t build a secure channel with a SP. Even when the malicious attacker disguises him/herself as an SP and then asks a sensor for authentication through the gateway, it cannot create a session key between a sensor and the SP because the attacker has to get PUF Response R values, with which a session key can be produced. Therefore, the session key between a sensor and SP cannot be produced.
Replay attacks: A malicious attacker may intercept and re-use for malicious authentication the messages between a sensor and TTP and/or between SPs by conducting replay attacks. In Zero-knowledge proofs which is conducted between the gateway and SP, however, it is impossible for a malicious attacker to perform a replay attack and get access to the message because the gateway computes Witness value x using a random value for authentication and furthermore PUF Challenge-Response pairs exchanged between sensors and SPs are removed every time they are used. In addition, the sensor does not use PUF DB. Although the values used are not removed from the DB, C values cannot be re-used because the Challenge C value is transmitted in a hashed state with a time stamp TT value from the TTP. In addition, when a sensor sends an authentication value to the SP, it sends hashed values with time stamp TT and random value secret ND. Therefore, re-use attacks are impossible.
Eavesdropping: A random user may eavesdrop the message exchanges at the mutual authentication stage. Especially, as communication is conducted wirelessly between sensors and the gateway, it can be a big security threat if eavesdropped message contains any confidential information. The clear text exchange in the proposed protocol is composed of public values for zero-knowledge proofs, ID for each authentication entity, non-reused Challenge C, random value, and time stamps, but the Response R value, which is sensitive data required for authentication and creation of session keys, is all hashed before being exchanged.
Leaked keys: When the sensor and SP exchange keys for the construction of a secure channel, and their keys are exposed, there can be a lot of problems from the possible exposure of the sensitive information exchanged during the communication. In our proposed protocol, the key is secure because the key required to construct the secure channel between sensor and SP is created through the PUF Response value, that the PUF of the sensor which can get the Response R is physically unclonable, and the server stores the Challenge C value only on PUF DB and receives the R mapped on the Challenge C from TTP only. In addition, when the sensor performs the authentication process with SP through TTP, it has no risk of confidential value exposure even if the TTP server or SP is hacked since it does not expose confidential value to the others by using zero knowledge proofs.
Mutual authentication: As the platforms of sensors and SP are uniform in a multiplatform smart home environment, various kinds of issues related to heterogeneity can take place. In the proposed protocol, a gateway is positioned between sensors and SPs as a uniform communication channel and it secures reliability among multiplatform devices by mutual authentication via TTP. The system is designed to provide the mutual authentication between sensor and gateway, gateway and SP, and SP and sensor so that each section of the communication process can be authenticated.
Forward security: A malicious attacker may try to take away current session keys between the sensors and SPs and restore past messages. In case the sensors and SPs repeat using a (same) session key at a regular interval, or use parameters that affect past and present in creating a session key, the attacker can restore past session keys, but the proposed protocol does not allow the re-use of PUF Response R values already used in producing sessions, but remove them from the DB every time it is used. Therefore, this system ensures forward security.
4.3. Storage Resource Analysis
Table 5 shows the storage resources calculated under the proposed protocol where there are x sensors, one gateway, Y SPs and one TTP at the provisioning phase and authentication phase. The sensor of lowest storage capacity has its own ID and the IDs of gateway, TTP and SP to which they belong, and stores five additional parameters for the authentication and secure channels. The gateway owns its own ID, X sensor IDs and Y server IDs as well as two parameters for authentication. SP has its own ID and one respective ID for gateway and TTP, and x sensors’ IDs. In addition, it possesses mx Challenge C values and x time stamp parameters to perform the authentication with sensors and build secure channels. TTP has its own ID and IDs for x sensors, Y SPs and a gateway, and mX challenge-response pairs to authenticate x sensors. By capacity, storage resources were allocated to sensor, gateway, SP, and TTP in this order and minimum storage capacity was allocated to a sensor lacking storage resources the most.
If 100 sensors should save 128 bytes passwords in each entry to authenticate to TTP, SP, or gateway, SP, gateway, and TTP would require the storage space with 128 bytes * 100 units = 12,800 bytes by each. However, it does not have to store the passwords in TTP or SP by using zero knowledge proofs, so it can save storage space.