Securing Your Smart Home Network


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:

Introduction to the Smart Home System

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

Image 1.

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

Attack Method

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

The door opens.


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.

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.

As a result, the door will open.


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

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.


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.


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:

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.

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

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.


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:

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


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.

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.