Particle and Data Security

[UMD]

Is there any documentation on information security wrt the Particle Cloud and Particle devices?

Specific questions:

Q1. I don’t believe that SSL is used between device and Particle Cloud. Is the traffic encrypted in any way?

Q2. I understand that events, function call requests and the like are not stored (good), but are there logs in play within the Particle Cloud that could store traffic (bad)?

Q3. Does Particle intend to publish an “official” cryptographic library? I note that there is a library called CRYPTOSUITE, but I have not assessed this as yet.

As Q1 is probably no and Q2 probably yes, to provide an environment that protects specific data, would need to implement Public Private Key Encryption/. I note that device firmware can be pulled from a device using DFU (and therefore potentially discover keys), so this why symmetric keys should not be used.

[Moors7]

Q1. I don’t believe that SSL is used between device and Particle Cloud. Is the traffic encrypted in any way?

After a quick forum search on ‘encryption’: Particle Electron to Particle cloud- Any encryption? [SOLVED]

I assume there are some device logs but I don’t think everything is being logged. Any specific concerns you have regarding this?

[UMD]

@Moors7,

Thanks for the pointer to @rickkas7 's comment where he confirmed that AES/RSA was being used for Photon to Cloud. This answers Q1.

The questioning is regarding the transmission of sensitive data, let’s say it is a name, “Alice”.

“Alice” —> Photon —> AES/RSA (encrypted “Alice”) -----> Particle (decrypted “Alice”)

“Alice” <— MyService <----- SSL (encrypted “Alice”) <----- Particle API’s

There is no “trust” at the Particle end where “Alice” is decrypted. In PCI DSS (Payment Card Industry Data Security Standard) parlance, the data in the Particle cloud needs to be within the “CDE” (Cardholder Data Environment). Note that my application is not for payments per se, just using PCI DSS as an example security model.

Thought! If the Photon is already encrypting the transmission using Public Key Encryption, then one could envisage exposing this functionality to the application layer (but using a different key) to encrypt the data on the device, and for it to only be decrypted by “MyService” because it has the private key.

Do you think this is possible and/or a good idea?

[rickkas7]

For Wi-Fi devices (Photon, P1, Core) the cloud session is CoAP over TCP, encrypted with AES and a session key. The device and cloud mutually authenticate using RSA public and private key pairs.

For cellular devices (Electron), the cloud session is CoAP over DTLS over UDP. The device and cloud mutually authenticate using RSA public and private key pairs.

None of the publish or subscribe events are logged. Only device connect and disconnect are logged.

There is no need for a library for cellular devices as it’s completely a standard (DTLS, datagram TLS). For Wi-Fi devices it’s a straightforward implementation of AES over TCP, however there is an open-source reference implementation.

[UMD]

@rickkas7,

As per usual, a well considered response.

It looks very much like device to Particle cloud comms is well secured. This is a relief!

Now that this concern is covered, my next issue is what is happening within the confines of the Particle cloud?

With PCI DSS, the service provider handling sensitive data within their environment is audited as having met with the security standard. Does Particle have a similar regime?

In my example above, is “Alice” known to any entity outside of the Photon?

You gave a clue with your comment: “None of the publish or subscribe events are logged.” This is a good thing.

So, theoretically, “Alice” is decrypted and quickly passed on within the cloud and not permanently stored. The specific issue now becomes, can this in flight traffic be sniffed? Answer, yes, but are there documented/audited security measures in place to prevent this “man in the middle” seeing Alice?

[UMD]

I note this entry for the record:

AES encryption demo and secure TCPClient usage

Here's a little demo that you can paste into Spark Build that shows how to use the AES-128-CBC encryption already available in the Spark Core firmware. https://gist.github.com/towynlin/fb1f56bdd0a77b46cf09 Put that on a Core and watch what it says on Serial. Once every 10 seconds it will create a random encryption key and will print a message plain, then encrypted, then decrypted. The open source AES implementation is from tropicssl in the core-communication-lib if you're curious, and ty…

Alas I could not compile the code in the demo…

[bko]

Hi @UMD

With the new modular building where user code and system code are separated, direct access to the crypto library is not currently available.

You could download the local gcc toolchain and do a local monolithic build–then you could use the built-in crypto libraries.

Or you could add the library code to your project as a C++ file. This duplicates some code on the device but gets you going quickly.

[UMD]

Thanks @bko,

Got it, DIY is the way we need to go for end to end crypto.

By the way, am very happy with what my research has revealed regarding the channel crypto that Particle has deployed - well thought out and implemented!

[d.chauhan]

@rickkas7 What is the length of RSA public and private key for Electron?

[bko]

I think @rickkas7 is busy today with the conference but I believe they are 1024 bit keys, You can see this for yourself in the doc that describes how to re-key your device using openSSL, just search.