IoT Protocols: Z-Wave and Thread
IoT Protocols: Z-Wave and Thread
Abstract— Today there are a multitude of IoT protocols available in the marketplace. Two protocols from different time periods are selected to
be compared. The two protocols selected are: Z-Wave which is one of the oldest and the most commercially successful protocol, and Thread
which is the latest protocol released for commercialization. This paper discusses both the protocols PAN, PHY, MAC, Routing, encryption, etc.
Z-Wave is based on propriety standards, most of which is not publicly available, although some have been reverse engineered by researchers.
Thread on other hand is based completely on open standards. All Z-Wave modules are made by a single company, while Thread modules are
expected to be available from multiple vendors. Z-Wave has a large installed base and has proven to be a commercial success. Thread is new and
has a open protocol, but Thread based devices are not yet readily available in the market for users.
Keywords-Z-Wave, Thread, Threadgroup,IoT,Internet-of-things
__________________________________________________*****_________________________________________________
357
IJFRCSCE | November 2017, Available @ http://www.ijfrcsce.org
_______________________________________________________________________________________
International Journal on Future Revolution in Computer Science & Communication Engineering ISSN: 2454-4248
Volume: 3 Issue: 11 355 – 359
_______________________________________________________________________________________________
Z-Wave routing protocol is propriety, however researcher authenticated by the Commissioner (an authentication server).
have reverse engineered most of it [6]. Z-Wave routing has 4 Commissioner itself must be authenticated. Commissioner
possible hops plus one final hop to the destination node. authentication requires a onetime Commissioning Session, a
Thread uses standard routing RIPng [RFC 2080]. RIPng is secured client/server socket connection, between
a distance vector routing protocol [RFC 1058] for IPv6. RIPng Commissioner and the Border Router via DTLS (RFC 6347) or
has maximum of 15 hops. TLS (RFC 5246). Using the advertized UDP port, during
There are two main data protocols currently being used at discovery, Commissioner provides PSKc (Pre-Shared Key for
transport layer in IoT PANs, CoAP (Constrained Application Commissioner) credential. The Border router with human
Protocol) [20] [27] and MQTT (Message Queuing Telemetry interaction than authenticates the Commissioner.
Transport) [21]. Both of these protocols were specifically A new device wishing to join the Thread network must
designed for low power IoT type devices. transmit an unsecured Discovery Request message. A router
Actual transport protocol used by CoAP is a UDP (User responds with a Discovery Response message including the
Datagram Protocol), which enforces use of DTLS (Datagram joining UDP port. The device will perform DTLS handshake to
Transport Layer Security, IETF RFC 6347). CoAP has a set of establish a secure session with router. The router will relay
security modes and mandatory-to-implement ciphers. CoAP UDP messages to the Border router, which in turn will relay
borrows some concepts from REST (Representational State them to the Commissioner. The device and Commissioner then
Transfer) protocol [22]. exchange token to establish trust. Commissioner inspects the
The transport protocol used by MQTT is TCP, which device IID (Interface Identifier) and credentials. If the
enforces TLS (Transport Layer Security, IETF RFC 5246). Commissioner is satisfied with the responses from the device, it
MQTT is a publisher/subscriber style protocol, requiring a will be provisioned with the appropriate data and services, and
server-broker. A typical MQTT session consists of establishing also provided with KEK (Key Encryption Key). Once it is
a connection, authentication, communication, termination. authenticated by the Commissioner, router will provide the
MQTT provides authentication and authorization scheme, but device network credentials.
does not have any security implementation requirements. Each Thread node also receives a master key when joining.
MQTT is designed to operate in a secure network, and thus has Two different 16-bit keys, one for MAC and other for DTLS,
no defined security mechanism. MQTT sends username and are generated using Hashed Message Authentication Mode
password in clear text and thus relies on Transport layer with SHA-256 algorithm (HMAC-SHA256) produces 32-bit
encryption, like TLS, to provide security. MQTT should not be output [RFC 6234] and the master key. The key set are rotated
used for global network as it does not scale well. TLS is based on key index changes, or the key rotation timer expiry, or
expensive protocol and not well suited for very low power incoming messages matches the next key.
devices [29] [30]. MQTT has TCP port 1883 reserved for non-
encrypted and TCP port 8883 reserved for encrypted
communication using TLS. Network Security Comparison
Although the DTLS and TLS have similar concepts, CoAP
with DTLS is preferred in IoT protocol due to low power IoT Z-Wave Thread
devices having limited memory and processing capabilities.
Both CoAP and MQTT can be operated in “no security” mode, Application Device & Cmd Application
“pre-shared key” mode and “certificate” mode. CoAPs (CoAP
secured) can also be configured in “raw public key” [IETF Transport DTLS 1.0, PSK DTLS 1.2, PSK
RFC 7250], but MQTT implementation is not yet available. In
pre-shared key mode CoAPs hashes pre-shared keys with a list Network Home Network ID IPv6-6LoWPAN
of corresponding communication nodes. Although use of
certificate mode is well established, its use in IoT is Data Link AES-128 AES-128, ECC
discouraged due to resource constraints. However, there is a
one big advantage in use of certificates; the certificate can be Physical None or facility door None or facility door
revoked if the IoT device is compromised. In raw public key
mode the IoT device holds an asymmetric key pair but without Perception Password Password
359
IJFRCSCE | November 2017, Available @ http://www.ijfrcsce.org
_______________________________________________________________________________________