Continuing the discussion from Electron: Hardware Discussion:
Definitely a good question, much more possible on the Photon than the Core (since there are more resources available). @zachary and @mdma, what do you think?
1 Like
This should certainly be possible on the Photon and the Electron since they have more room for firmware code and available RAM.
I’ve added an issue to our internal tracker - will post back here when adding TLS to the photon is scheduled!
5 Likes
In this document from the UBLOX writes that the modules have implemented support for SSL.
https://www.u-blox.com/images/downloads/Product_Docs/u-blox-ATCommands_Manual_%28UBX-13002752%29.pdf
See page 454 Chapter 26 HTTP.
<HTTP_secure> Number HTTP Secure option (SSL encryption). It enables or disables the HTTPS (SSL secured connection for
HTTP application) usage:
• 0 (factory-programmed value): HTTPS (SSL encryption) disabled and the HTTP server port set
to 80
• 1: HTTPS (SSL encryption) enabled and the HTTP server port set to 443; an USECMNG profile
can be specified with an additional parameter.
This should make it a simpler implementation in the firmware of this protocol.
The microcontroller does not necessarily make encryption.
@mdma any updates on TLS support for the Photon / Electron?
Just saw this.
No updates to report. But we will be using PolarSSL to provide TLS and DTLS on the photon and electron. We hope to have this in place by the end of the year.
1 Like
I need my photon to run a couple of simple GETS over HTTPS. Is this possible yet?
Hi @dougM
Have you seen this thread:
The licensing is not ideal for some uses, but it is a great achievement nonetheless.
I’ve commented in that thread as well. Can’t seem to get any of the examples working, let alone any custom code.
The documentation to use it is sparse as well.
1 Like
Hello everyone.
I know you already use mbed DTLS for Electron and it’s great for use with Particle Cloud but there are certain cases where you should directly communicate with other servers. As I can see the interest is very high for SSL/TLS library.
Do you have tested the AT command + USOSEC.
It’s about SSL / TLS mode configuration on TCP socket.
Is it enough to include this option or is required to modify a driver for TCP Client.
It would be great to add this option in the firmware.
In this way would avoid external library that takes too much flash and RAM.
If this it is possible to do then it will solve the problem for TLS TCP Client for electron. About Photon not know if there is this kind solution.
SARA-G3 / SARA-U2 System Integration Manual Page 78-79
AT Commands Manual Page 507, 538-540
1 Like
Unfortunately version of modems that are built up of Electron, do not support embedded SSL.
Electron 2G module is SARA-G350 01S-00, while the 3G module is SARA-U260 00S-00.
In the next version of the production this could be change.
These versions are supported:
TOBY-L200-02S TOBY-L210-02S TOBY-L210-62S TOBY-L220 TOBY-L280-02S MPCI-L200-02S MPCI-L210-02S
MPCI-L280
LISA-U200-03S LISA-U200-83S LISA-U201 SARA-U201 SARA-U260-03S SARA-U270-03S SARA-U270-53S
SARA-U280-03S
Modules
SARA-G340-02S SARA-G350-02A SARA-G350-02S
Aren’t you concerned about the data usage over cellular? TLS is quite data hungry. We’ve had to take many steps to optimize the DTLS communication with the cloud.
You have achieved maximum savings when it comes to communication. For example I think it would be great to exist SSL support for TCP library.
By using third party sim card is not a big problem the consumption of data.This applies to TCP Client library and not for communication with the Particle Cloud.
TLS is data hungry but for some applications that require a higher update rate it is the only way to go. The current secure solution, going through the Particle cloud, is much more expensive than a 3rd party sim with more data.
For me not having TLS on the road map could be a deal breaker and cause me to move to a different hardware platform.
I think Particle team has a plan to enable TLS, only at the moment are busy with improving the stability of the firmware.
There are other platforms based on GPRS / 3G but none offers the possibilities of Electron.
For example here’s Open Picus which is based on 16bit PIC MCU, but does not have the support of this great community, and as far as I know OpenPisus still does not support TLS. Also it is operated only on GPRS.
Also using TLS need more flash memory. For example for mbed platform, SSL example of MTS Dragonfly occupies more than 225kb out of 512kb. This applies to simple example.
https://developer.mbed.org/platforms/MTS-Dragonfly/
To mention that both platforms are certified for use in end device but not have direct support for Cloud and OTA through Cloud. Particle offers a complete solution.
However you are right, to use another server unless Particle Cloud, you need TLS.
I think it might be good for the next version of the electron to use more powerful MCU or GSM module for direct support for TLS. With that principle even 8bit Arduino gained support for SSL. By simply using a wifi module with embedded TLS.
So be patient, I believe that by the end of 2016 will have a solution for TLS.
I invite any of Particle engineers to say whether they plan to work on the problem for TLS Client library for Electron.
@zach @mdma @BDub
2 Likes
I agree 100% that the Electron is best thing going in regards to a Cellular platform. I am betting on the future of the Electron. I am currently verifying version 0.1 of a circuit board for a new application. (I hope version 1.0 will go to manufacture next week.) I hope you are right about the end of 2016 time frame for TLS, that will fit perfectly into my road map.
I have done some work with the Dragonfly, and I still might do something down the road. It is a good hardware platform but it has no “ecosystem” like Particle/Electron does.
The advantage to having the TLS in software is that it can easily be upgraded with the firmware if there are security changes. If it is embedded in the modem it gets more difficult to update.
For the sake of this particular discussion my current application requires an update every 30secs. It uses MQTT for the the protocol. The published data packet is 848 bytes. Based on the Electron usage counters I am using about 1300 bytes per update. (That is Tx and Rx data.) So at 2,880 updates a day that is about 3.8MB/day, or roughly 120MB/month.
@skeller I'm not sure what your communicating with but would AMQP data transfer help you out any? There is a AMQP library in the Build IDE.
I hear Microsoft Azure works with MQTT & AMQP for data input but I have never heard of AMQP but I do hear that it is a secure format. It's all new to me to be honest.
Some data about AQMP -
AMQP in a Nutshell
AMQP, which stands for Advanced Message Queuing Protocol, was designed as an open replacement for existing proprietary messaging middleware. Two of the most important reasons to use AMQP are reliability and interoperability. As the name implies, it provides a wide range of features related to messaging, including reliable queuing, topic-based publish-and-subscribe messaging, flexible routing, transactions, and security. AMQP exchanges route messages directly—in fanout form, by topic, and also based on headers.
There’s a lot of fine-grained control possible with such a rich feature set. You can restrict access to queues, manage their depth, and more. Features like message properties, annotations and headers make it a good fit for a wide range of enterprise applications. This protocol was designed for reliability at the many large companies who depend on messaging to integrate applications and move data around their organisation. In the case of RabbitMQ, there are many different language implementations and great samples available, making it a good choice for building large scale, reliable, resilient, or clustered messaging infrastructures.
AMQP is a binary wire protocol which was designed for interoperability between different vendors. Where other protocols have failed, AMQP adoption has been strong. Companies like JP Morgan use it to process 1 billion messages a day. NASA uses it for Nebula Cloud Computing. Google uses it for complex event processing. Here are a couple of additional AMQP examples and links:
It is used in one of the world’s largest biometric databases India’s Aadhar project—home to 1.2 billion identities.
It is used in the Ocean Observatories Initiative—an architecture that collects 8 terabytes of data per day.
More examples and links are available at amqp.org.
MQTT Overview
MQTT (Message Queue Telemetry Transport) was originally developed out of IBM’s pervasive computing team and their work with partners in the industrial sector. Over the past couple of years the protocol has been moved into the open source community, seen significant growth in popularity as mobile applications have taken off, and it is in the process of moving into the hands of a standards body.
The design principles and aims of MQTT are much more simple and focused than those of AMQP—it provides publish-and-subscribe messaging (no queues, in spite of the name) and was specifically designed for resource-constrained devices and low bandwidth, high latency networks such as dial up lines and satellite links, for example. Basically, it can be used effectively in embedded systems.
One of the advantages MQTT has over more full-featured “enterprise messaging” brokers is that its intentionally low footprint makes it ideal for today’s mobile and developing “Internet of Things” style applications. In fact, companies like Facebook are using it as part of their mobile applications because it has such a low power draw and is light on network bandwidth.
Some of the MQTT-based brokers support many thousands of concurrent device connections. It offers three qualities of service: 1) fire-and-forget / unreliable,2) “at least once” to ensure it is sent a minimum of one time (but might be sent more than one time), and 3) “exactly once”.
MQTT’s strengths are simplicity (just five API methods), a compact binary packet payload (no message properties, compressed headers, much less verbose than something text-based like HTTP), and it makes a good fit for simple push messaging scenarios such as temperature updates, stock price tickers, oil pressure feeds or mobile notifications. It is also very useful for connecting machines together, such as connecting an Arduino device to a web service with MQTT.
Learn more at mqtt.org.
I am familiar with AMQP. I think it requires a bit more overhead than MQTT. I don’t know if it is anymore efficient than MQTT in regards to data. In my case I am sending binary data so there is not much more that can be done to crunch it down.
In the context of this topic AQMP is still going to need TLS to secure the connection.
You can always include mbedTLS or another other TLS library in your application and implement TLS over plain sockets - you’re not blocked by it being included in system firmware.
1 Like