QW Home Automation Advanced Topics


The Problem

Security is a very important part of home automation system. However it is often overlooked by the end users.

Somehow users are under impression that security has been very well taken care by the home automation system vendors, which unfortunately is most likely not true.

Recently the massive government surveillance programs raised concern about the privacy. I hope it will draw people's attention about the security of the home automation systems as well.

One of the fundamental principles of information systems security is that security requires user participation. In this chapter we will disclose the security measures implemented in QW Home Automation systems, in detail, in hopes that users will be aware of all potential risks associated with the system.

Encrypted Communication

Starting from version 1.7 of QWHA controller, the communication channels used by QWHA Admin and QWHA Android client are encrypted only. The legacy system uses TCP sessions with plain text, which will be completely disabled with version 1.7+.

Dual Encryption Schemes, SSL and AES

The QWHA system uses two encryption schemes, SSL and AES.

SSL is only used in commissioning. For example, retrieving certain system configuration parameters at the first time the system is set up.

Once the client retrieves the system parameters, the client can operate with AES scheme, which is QWHA proprietary.

Why Two Schemes?

SSL is well adopted scheme. Why do we need to add another proprietary schema?

There are two reasons:

  1. Because SSL is well known, the traffic can be detected. And it is subject to various attacks, which can be resolved by QWHA.
    However, SSL can be simply blocked by some regimes (I am not going to name who). In that case the connection can be simply forced to terminate once the handshake is detected, which renders SSL unusable in some regions.
  2. SSL handshake takes much higher traffic and much longer time, compared to QWHA AES session.

QWHA AES Explained

QWHA AES required a shared secret, a 256 bit encryption key (32 bytes).

QWHA controller creates a unique key per user, at the first time the user is created. The key can be later updated by generating a new one. However, once the key is updated, the client has to re-synchronize the new key with server (using a SSL session with user name and password as authentication).

The QWHA AES encryption is proprietary, but we don't have to keep the scheme as a secret. Here is the full disclosure of the scheme:

  1. The client establishes a TCP connection to the server. Once the connection is established, the client sends it's user name.
  2. The server receives the user name from client. If the user name is unknown, the server will close the connection. Otherwise, the server will retrieve the shared key and use the key for further communication for this session.
  3. The server sends back a 12 byte IV to the client.
  4. The client uses the IV, a zero length AAD and shared secret key to send out the logon message. The messages are encrypted using AES/GCM, with a 128 bit MIC block to authenticate the message from altered by potential attackers.
  5. The server receives the message, check the authentication of GCM MIC and proceeds further. Note, every time a new message is received by either client or server, the recipient will use the last 12 bytes as the new IV for next outgoing message block.

The description above is not intended for end users. It is for security experts to verify the scheme is actually secure.

System Configuration

For version 1.7+, the new encrypted communication requires some configuration change of the system.

Previously, the system only needs to open one port for both admin and control applications.

With version 1.7+, the system now requires two ports, SSL port and AES port.

System upgraded from pre 1.7 won't work properly until the configuration is modified.

Is Your System 100% Safe After 1.7 Upgrade?

No system is 100% safe.

Theoretically, the encryption in communication can't be broken by simple eavesdropping.

So your system is safe as long as the shared secret key is safe from attackers.

However, a lot is required to keep the shared secret key safe.

For example, if your android phone is infected by some malware. The shared secret key, which is stored in your phone, is at risk because the malware can access it. It is the inherent problem because android doesn't offer secure storage as fart of the system. So there is no way to keep a file from being accessed by other programs.

The same is also true for the user name and password, which is also stored in the phone.

How about encrypting the key with another master key obfuscated in the code? It is security through obscurity? It will certainly help. However it is still risky because the code itself is public and is subject to all kinds of analysis by anybody. The advantage is that this approach increases the cost of breaking the system. The disadvantage is that it is much easier to break the obfuscated code than breaking the encryption itself, and it always give users a false impression that the system is safe and unbreakable.

Now you would understand why the cellphone of president's costs tens of millions to enforce security. They have to carefully choose application installed to make sure every application can be trusted and without vulnerability. Also the maintenance is also very high. So average people will never afford that kind of technology. 

Also the SSL channel is subject to man-in-the middle attack. The simple solution for average user is to try to only do commissioning at home. The future version of QWHA will employ more complicated SSL certificate checks to alleviate the risk.


Copyright 2005 - 2013 Teraspaces Inc. All rights reserved.