Securing Your Smart Home Network

Considerations_for_Smart_Home_Network_Security

Introduction

The Internet of Things (IoT) has led to the innovation of a variety solutions, covering both consumer and industrial applications. Smart home is one of the most prominent application of IoT, and many companies have invested heavily in this field. However, a major drawback with smart home and other IoT applications is network security. Since all devices are connected to each other, a single faulty device can affect the integrity of the entire network. For smart-home owners, the security requirements on networks are demanding. A hacked smart home allows unauthorized access to premises, or even the failure of critical systems such as fire protection systems.

To better understand the methods of securing smart homes, let us review the concept of network communications security.

Network Communications Security

In a Local Area Network (LAN), a third party might snoop transmitted information via the network. Although communication in a LAN is passive, a malicious listener can snoop critical data that is being communicated through the network. Additionally, malicious users can deceive the network using Address Resolution Protocol (ARP) and other means to obtain data without being detected.

What are some effective ways to solve this problem? In general, there are two methods to ensure the security of a communication network:

Using passwords for authorization
Password is a common element in network security, such as securing a Wi-Fi network. The use of passwords limits the access into a network by allowing access only to users with the proper authorization. However, this approach is not immune to attacks. If a password is disclosed, the entire security mechanism fails.
Communicating with a unique language
In this approach, a language known only to the internal network is used for communication. Even if a message from the network is disclosed publicly, the message cannot be deciphered.

Introduction to the Smart Home System

The image below shows a typical structure of a smart home system.

Image 1.

Server: Cloud server
SmartHost: SmartHost, which forwards the Ethernet data to Device via the Zigbee data
Device: Device node, including light, curtain, and access control sensors, which Zigbee connects to SmartHost
Client: Mobile application. The application may be for Android or iOS clients. It receives the command of the user. When the Client and SmartHost are on the same LAN, the Client will interact with SmartHost through Wi-Fi. If the Client and SmartHost are not on the same LAN, the Server will forward the communication.

Attack and Defense

Typically, a home network is secured with passwords to limit unauthorized access. However, the method in which the passwords are stored and communicated plays a vital role in determining the robustness of the network security.

Method 1: No Encryption

If the communication between the Client and SmartHost is in plain text, security is at risk. If a hacker accesses the home LAN, the hacker can snoop network packets and easily manipulate the devices in the house.

Communication Process

Client-->SmartHost: Login: account John, password abc
SmartHost-->Client: OK
Client-->SmartHost: Open the door
SmartHost-->Client: Done

Attack Method

If the hacker snoops the communication, the hacker can simulate the Client to log on to the system.

Hacker-->SmartHost: Login: account John, password abc
SmartHost-->Hacker: OK
Hacker-->SmartHost: Open the door
SmartHost-->Hacker: Done

The door opens.

Analysis

Because the communication is in plain text, it is easy the communication protocol between the Client and SmartHost to be analyzed. After stealing the account number and password of the user, the hacker can take full control of the household system.

Defense Level: V – The system can only defend against attacks from unauthorized users. However, the password is easily accessible since it is not encrypted.

Method 2: Using Static Key

The above problem lies in the data transmission using plain text, which can be analyzed easily. Instead, we can use a specific key to encrypt the data for extra security.

As shown below, () indicates that the contents have been encrypted with a static key.

Client-->SmartHost: (Login: account John, password abc)
SmartHost-->Client: (OK)
Client-->SmartHost: (Open the door)
SmartHost-->Client: (Done)

Because the communication is in the ciphertext, it is difficult for the hacker to understand the contents. However, as long as the hacker records the dialog and replays it, the hacker can still pretend to be the Client.

Hacker-->SmartHost: (Login: account John, password abc)
Hacker-->SmartHost: (Open the door)

As a result, the door will open.

Analysis

The hacker does not know the specific contents of the communication between the Client and the SmartHost. However, the hacker could simulate the "voice" of the Client to communicate with the SmartHost, assuming full control of the Device.

Defense Level: VV

Method 3: Adding a Time Stamp

We can make a minor improvement to deal with the above attack. In general, the hacker will not execute the command immediately after he snoops it. Instead, he will execute the command when the host is not physically present at home. Therefore, we can add a field in the ciphertext called Timestamp.

Communication Process

Client-->SmartHost: (201509261543, Login: account John, password abc123)
When the SmartHost receives the command, it compares the current system time with the timestamp. If the system time is 2015-09-26 15:44, the Client passes the verification because the time difference is within five minutes.
SmartHost-->Client: (201509261544, OK)
When the Client receives the command, it compares the current system time with the timestamp. If the system time is 2015-09-26 15:43, the SmartHost passes the verification because the time difference is within five minutes.
Client-->SmartHost: (201509261548, Open the door)
When the SmartHost receives the command, it repeats the verification process by comparing the timestamps.
SmartHost-->Client: (201509261549, OK)
When the Client receives the command, it repeats the verification process by comparing the timestamps.

Attack Process

The hacker snooped the whole process but was not aware of the contents, particularly the timestamps. When the host leaves the house, the Hacker would launch an attack at 21:09.

Hacker-->SmartHost: (201509261543, Login: account John, password abc123)
When the SmartHost receives the command, the current system time is 2015-09-26 21:09. Because the time difference exceeds five minutes, the request is discarded.
The attack fails.

Analysis

Because the hacker cannot read the contents without the static key, he cannot extract the timestamp information. Therefore, the hacker cannot penetrate the defense.

Defense Level: VVV – This method can defend against most disguised command attacks but is limited to the time range defined in the system.

Method 4: Adding a Serial Number

The above solution can defend against commonly disguised attacks launched after five minutes but cannot deal attacks launched within five minutes. To cope with this, we can add a serial field (that is, a serial number) in the command to prevent the repeated command in a short time.

During the communication, a serial number, Serial:xxxxxxx, is generated randomly. When the receiver receives the command, it will check the SerialTable to see if there is xxxxxxxxx within five minutes.

If this serial number cannot be located, the receiver will execute the command and then add xxxxxxx to the SerialTable. Upon finding this serial number, the request will be discarded.

Since the system only stores the serial number for five minutes, it will not cause a high load for table query.

When used together with the time stamp, the disguised command attack of the hacker can be prevented.

Analysis

Similar to the timestamp, the hacker cannot modify the timestamp and serial fields because he cannot read the contents. When a copied packet is re-sent, it is bound to fail.

Disclosure of Static Key

Although the methods above seem perfect, they depend on three premises:

The encryption algorithm is too strong for inverse operations.
It is too costly for a brute-force attack.
The third party cannot obtain the encryption algorithm and the key of the communication.

To prevent inverse operations, we can adopt internationally recognized encryption algorithms to encrypt the message, such as the AES in OpenSSL.

To prevent brute-force attacks, we can increase the complexity of the encryption key. For instance, we can use a key of 128 bytes for encryption. In this way, it will be too costly for a brute-force attack.

However, there is no immediately available solution to prevent third parties from obtaining the encryption algorithm and the key of the communication.

Since the code consists the encryption key, it is possible for development engineers to unintentionally disclose the encryption key. If a hacker obtains the static key, all encryption methods would become invalid.

There are two possible solutions to prevent the problems mentioned above.

Solution 1: Limiting Access to the Encryption Key

The common development engineer is not allowed to touch the encryption algorithm and encryption key. Only the core developer of the company can carry out the design of the encryption algorithm. Other common development engineers can only access the binary static library or dynamic library.

However, the most important thing is that, no matter what the encryption process generates, the encryption key shall never be in plain text. For example, the encryption key can be built using the command:

const char *encrypt_key = "adi3dfa;9era";
...

However, it is easy to retrieve the encryption key because it is stored plain text. For example, running this command lists all plaintexts in the library:

strings libEncrypt.a

Even when the core developer did not disclose the key, the Hacker can still carry out strings analysis on the program with a SmartHost to retrieve the static key.

Therefore, the key must be generated dynamically. For example:

//! The name should not expose the encryption key. It should be in a common phrase
char encrypt_key[128] = {0};

//! The name should not expose the encryption key. It should be in a common phrase
void GenerateEncryptKey() 
{
  //! The key in the encrypt_key is generated through a certain algorithm here 
}

In this way, the hacker cannot obtain the key easily. However, the hacker can still obtain the access key by carrying out single-step tracking and commissioning, although not so easily.

Solution 2: Automatically Generating an Encryption Key

This method is based on the principle of "an encryption algorithm that cannot stop the encryption algorithm designer himself is not a good algorithm." In this method, the static key encryption is used only once. Each product will receive a unique key upon delivery, which has a corresponding data table on the server.

The data encrypted with unique key is indicated with [] below.

SmartHost Logging on to the Server

After the user purchases the SmartHost and starts it for the first time, the SmartHost will log on to the Server.

SmartHost-->Server: (uid=xxxxxxxx)[timestamp=201509291255, serial=82342, I am SmartHost, model=M1, Log in]
SmartHost uses the static key for encryption for introducing its uid, but uses the unique key for encryption.
Server-->SmartHost: [Allow]
The Server extracts the uid from the packet and searches for the unique key corresponding to the uid in the database and then encrypts the response data with the unique key.
The SmartHost encrypts the subsequent packets with the uniquekey.
In this way, only the super administer of the database can access the SmartHost unique_key corresponding to the uid.

Client and SmartHost

The user needs to bind the SmartHost with the Client. However, the Client does not know the uid or unique key of the SmartHost. How can the Client communicate with the SmartHost?

There is a QR code on the back of the SmartHost. It is the unique_key of the SmartHost. The user can obtain the unique_key of the SmartHost using the QR code-scanning feature of the Client.

Communication Process:

To search for SmartHost

The Client uses User Datagram Protocol (UDP) to broadcast the packet: [timestamp=201509291255, serial=24234, tell me your IP address]
When the SmartHost receives the packet, it will use the unique key to decode and verify the timestamp field. If the result is normal, which indicates that the decryption is successful, the packet is sent. Then, it will reply with the UDP packet: [timestamp=201509291255, serial=3234, ip_address=192.168.x.x]
When the Client receives the UDP packet, it will use the unique key to decode and obtain the IP address of the SmartHost.

If there are more than two SmartHosts, only the SmartHost that uses the corresponding unique key can pass the timestamp verification. The timestamp obtained by decoding the wrong unique key cannot pass the timestamp verification.

Binding the SmartHost

The unique key encryption is applied to subsequent interactions with the SmartHost.

Client and Server

When the md5sum of the password is used as the unique key for communication, timestamp and serial verification will be conducted by default.

Registering an Account

Client-->Server: (Regist: account=Lucy, password=98789) Server-->Client: (Done)

When the Server receives the registration information, it will use the md5sum of the password as the unique key to encrypt the data communicated with the Client. The data encrypted with the unique key is indicated with [] below.

The encryption level is very low at the time of registration.

Logon

Client-->Server: (Login: account=Lucy)[timestamp=201509292100] informs the Server of its account, and then the server queries the table according to the account number to obtain the unique key and then uses it to decode the timestamp and carry out timestamp verification. If it passes the verification, the login is successful. Otherwise, the login fails.
Server-->Client: [timestamp=201509292100, OK]

Attack Simulation

For hackers who do not understand the communication protocol, the packet replay attacks are useless.
The hacker in this example is assumed to be very familiar with the protocol. Suppose the hacker:

Has obtained the static key and encryption and decryption algorithm.
Cannot access the server and secret data.
Cannot access the SmartHost of the user.

There are three methods in which the hacker can access the LAN of the SmartHost:

The hacker captured the login packet of the SmartHost through the interceptor and obtained the uid of the SmartHost. Because he does not have the unique key, he cannot obtain the communication contents between the SmartHost and the Server. However, he understands the plain text content after decoding the ciphertext. He may launch attacks with the brute force method. There poses some risks but the time cost is too high.
If he can intercept the registration process of the Client, he can decode it. If the encryption of the registration packet is with static key, the hacker then can obtain the user's password and calculate the unique key of the md5sum. He can use this to simulate the true Client to manipulate the SmartHost. The key point for this method is to capture the registration packet. Since one user can use this packet only once, capturing occurs only when the communication happens in the LAN that the hacker has entered. If the user has registered its account when the hacker decides to attack the SmartHost, the attack fails.
The hacker can allure users to use a Trojan app to steal the files stored by in the mobile system of the Client. Then, he can obtain the account number and password of the Client, as well as the unique key of the SmartHost.

Conclusion

Security is a key element in smart home and should never be taken lightly. From the above examples, the most feasible attack method is using a Trojan app. By using this method, the hacker bypasses all security measures because the unique key of the SmartHost, as well as the user's account number and password are available on the mobile phone. Therefore, users must also take extra precautions when installing apps from unreliable sources to prevent a Trojan attack.

Community

Securing Your Smart Home Network

Introduction

Network Communications Security

Introduction to the Smart Home System

Attack and Defense

Method 1: No Encryption

Communication Process

Attack Method

Analysis

Method 2: Using Static Key

Analysis

Method 3: Adding a Time Stamp

Communication Process

Attack Process

Analysis

Method 4: Adding a Serial Number

Analysis

Disclosure of Static Key

Solution 1: Limiting Access to the Encryption Key

Solution 2: Automatically Generating an Encryption Key

SmartHost Logging on to the Server

Client and SmartHost

To search for SmartHost

Binding the SmartHost

Client and Server

Registering an Account

Logon

Attack Simulation

Conclusion

Read previous post:

Read next post:

Alibaba Clouder

You may also like

Comments

Raja_KT March 17, 2019 at 4:32 pm

Alibaba Clouder

Related Products

IoT Platform

IoT Solution

Global Internet Access Solution

ZOLOZ Smart AML