Implementing security TLS/SSL with no Spark-cloud

Firmware
#1

Hi,

I was referring to this post http://community.spark.io/t/suggested-addition-to-documents-wireless-security/5552, but I could not come clear with it.

So my queries are:

  1. If I am not using the Spark Cloud means any connection over TCP ( say MQTT for instance over local wifi) is not secure unless explicitly implemented. Am I correct?

  2. I have my own cloud hosted in Amazon Web Services which has AES encryption (if I am right). Now I am trying to reach the server using custom TCP sockets ( MQTT again ) from the Spark core. Do I need to secure anything from the client side?

What SSL/TLS security can I implement explicitly, within the arduino wrapper in spark core?

Your help is appreciated.

Thanks,
Gaurav

Receiving Payments through Particle
#2

Hi @gaurav

TLS/SSL has two phases–a certificate-based public key negotiation phase and the data transfer phase using private key crypto like AES. The Spark cloud implements both of these phases by preloading all the Spark cores with the cloud public key and different core-specific private key for negotiation and then AES for the data security, so the model is similar.

The problem on a Spark with general TLS/SSL is the certificate management. If you take a look at a modern cert in your browser, there are lots and lots possible algorithms with lots of public key data that would be difficult to handle on the limited sources of the Spark or any micro.

If you could have a strategy like the Spark cloud where you are only using one type of public key crypto to negotiate and only using one type of private key crypto for data encryption, and pre-caching the public key in the firmware, then you could talk to your MQTT host in a way similar to how the Spark cloud works.

4 Likes
#3

I don’t know tls/ssl well at all, although I did have a look at porting one of the open source embedded ssl libraries to the core. Seems they are just a touch too large for the available flash and RAM without some shoehorning to get them down to size.

The public certificates could be stored in external flash - is that enough storage for all the certificates required? I imagine you only need the root certificates, and the remainder are downloaded as needed.

Is it possible for the client to always negotiate a specific cipher for the symmetric encryption, removing the need to have code for all possible ciphers?

#4

So the cert for spark.io is 2032 bytes base-64 encoded so a bit smaller when expanded on the core, but still sizable. Putting the certs in flash (internal or external) is possible but renewable security becomes anywhere from medium hard to impossible. All the root certs changed recently with Heartbleed for instance.

So I can’t say it is impossible for sure, but it sure looks really hard to me.

#5

For cert updates, wouldn’t pushing a new cert to flash be sufficient? e.g. via dfu-util?

#6

If using just AES is an option there’s this example code:

#7

And @gaurav, just to be extra clear on both your specific queries—yes, if you are using the built-in TCPClient object to connect to your own server, all communication will be plaintext (not encrypted) unless you specifically implement security yourself.

1 Like
#8

Hi @zachary

Thank you so much for this demo. I am learning AES as I want to secure communication from the spark to my own server. I do not have a deep understanding of AES. I understand that you have data(buf in this demo), a key for encryption(key in this demo), but what is the iv variable? I know it is not your job to explain AES to me. Do you have any articles you would recommend reading?

Thank you

#9

IV stands for “initialization vector”. AES can be done in several modes. In CBC mode, the key stays the same for the whole session, but the IV changes for every message. Both the key and the IV are used as part of the encryption. You can think of them as forming a composite key that changes for every message back and forth.