Pular para o conteúdo principal
Renesas Brasil - Knowledgebase

FAQ: SSP v1.3.0 now includes NetX Secure and efficient M2M protocol for secure IoT edge-to-cloud communication

Last Updated:09/05/2017


What are the Frequently Asked Questions (FAQs) for the SSP 1.3.0 release for NetX Secure and M2M protocol?


The FAQs for the SSP 1.3.0 release for NetX Secure and M2M protocol can be found below:


What additional capabilities are made available in SSP because of these additions?


SSP v1.3.0 adds Application Framework support for the Transport Layer Security (TLS), as well as the Message Queue Telemetry Transport (MQTT) protocols.

Transport Layer Security (TLS), sometimes also referred to as Secure Sockets Layer (SSL), is a suite of cryptographic protocols that provide communications security over computer networks. TLS is widely used in applications such as web browsing, email, instant messaging, and Voice-over-IP (VoIP). Websites use TLS to secure all communications between their servers and web browsers.

Message Queue Telemetry Transport (MQTT) is based on  ISO standard (ISO/IEC PRF 20922) publish-subscribe-based "lightweight" messaging protocol for use on top of the TCP/IP protocol. It is designed for connections with remote locations where a small code footprint is required or the network bandwidth is limited.


How does TLS add security to embedded device communication, and why is this important?


When secured by TLS, connections between a client (e.g., a web browser) and a server have one or more of the following properties:

  • The connection is private (secure) because symmetric cryptography is used to encrypt the data transmitted. The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session. The negotiation of this shared secret is both secure (the negotiated secret is unavailable to eavesdroppers and cannot be obtained, even by an attacker who places themselves in the middle of the connection) and reliable (no attacker can modify the communications during the negotiation without being detected).
  • The identity of the communicating parties can be authenticated using public-key cryptography. This authentication can be made optional, but is generally required for at least one of the parties (typically the server).
  • The connection ensures integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission1.

1 https://en.wikipedia.org/wiki/Transp...Layer_Security



In what way is the MQTT protocol more efficient for resource constrained, low-power devices, and why is this important?


MQTT is a Client Server publish/subscribe messaging transport protocol. Compared to common protocols like HTTP it is very light weight, as packet overhead is significantly reduced thus limiting the amount of data that gets transferred over the wire (or air)

One of the design goals for MQTT is to support wireless networks with varying levels of latency due to occasional bandwidth constraints or unreliable connections. One example of a situation would be a battery powered device that is only able to communicate when it comes out of it’s low-power mode.

The publish/subscribe pattern used by MQTT also helps improve communication efficiency for such devices, as it decouples a client sending a particular message (the publisher) from client(s) receiving it (subscribers) by way of an intermediate entity called a broker.


This setup allows for several improvements for this particular class of devices, compared to conventional client/server communication.

  • Space decoupling: Publisher and subscriber do not need to know each other (by IP address and port for example).
  • Time decoupling: Publisher and subscriber do not need to run at the same time.
  • Synchronization decoupling: Operations on both components are not halted during publish or receiving2.

Enterprise grade IoT cloud service providers like AWS IoT, Microsoft Azure and others already offer MQTT based device connectivity. In addition, the publish/subscribe semantics employed by MQTT makes it easy to use on the IoT device side.

2 http://www.hivemq.com/blog/mqtt-esse...lish-subscribe



What are some typical use cases for this functionality?


Any developer considering to deploy a connected device today needs to pay attention to various security aspects concerning the way the device will communicate.

  • Is the communication between the device & gateway secured, or is it possible for an unauthorized 3rd party to listen in?
  • Is the gateway really communicating with an authorized device, or vice versa?
  • How do the communicating devices ensure that the counterpart is what it claims to be, and not a Trojan attempting to get deeper access to the network?
  • What is the best way to ensure the integrity of the communication, to make sure that messages arrive without having been altered in any way?

TLS helps resolve all the above issues. The protocol is designed to support many different ciphers & hashing algorithms, allowing implementations to scale to the appropriate level of security. As the protocol is standardized and widely deployed, the risk of security issues that affect the integrity of the system going unnoticed, so called (security by obscurity) is minimized. Recent events have shown that breaches in embedded device security can cause seriously financial harm to companies of any size, and the amount of exposure given in the media to such incidents today makes it more important than ever to ensure that security is part of the design from the start.

In addition to the need for security, most IoT devices tend to belong to one (or both) of the following categories:

  • They are battery powered and therefore need to optimize the duty cycle to minimize the amount of time spend receiving & transmitting data to conserve power.
  • They operate in environments where reliable network connectivity is not always available.

In both these situations, employing a communication solutions that lets the device transmit and/or receive the data it needs with as little overhead as possible is strongly desired. MQTT achieves this, and broad support for the protocol with existing enterprise cloud providers makes it a natural choice for efficient cloud connectivity.


Is there any extra cost for me to get access to this additional functionality in the Synergy Software Package?


Renesas is committed to increase the value of the investment customers are making by developing with the Synergy platform over time by continuously adding new functionality to the platform. All new SSP functionality introduced in version 1.3.0 is available at no additional fee charge for the entire range of Synergy MCUs. Once you download the new SSP package from the Synergy gallery, your production license will automatically be updated to cover the new functionality when you download SSP v1.3.0


Suitable Products
SSP 1.3.0