1

I have a safety-critical embedded device, which sends data updates (in get requests) and pulls settings from a server. The device uses an embedded microcontroller/wifi chipset called the Particle P1; this takes all sent data and encrypts it with AES, sends it to a server owned by the chipset company (which we'll assume for now is secure enough), gets decrypted, and then gets sent over SSL to my server. To ensure that nobody can push false data or settings to the server, every device has both a publicly accessible serial number, and a ~50 character randomly-generated pre-set password corresponding to that serial number. The server looks up the serial number in a database and compares the password given to the one on file before considering any of the data.

Is this sort of permanent access token system secure?

EDIT: According to the microcontroller vendor, the link between the device and them is properly secured with public-key TLS:

The Particle cloud uses RSA for session key exchange and authentication and then AES for data encryption for all cloud transactions. Each device has its own copy of the Particle cloud public key and its own private key. I don't know of a doc reference but the source code is all on github for anyone to see.

Improve this question
10
  • 1
    Can you define what you mean by "pre-set key"? An RSA key, an ECC key? A password that you use to derive one of the above? Are there certificates involved? How exactly does the server "verify" this? You can use the edit link to add more information to your question.
    – Mike Ounsworth
    Mar 21, 2016 at 16:44
  • Does the device verify the SSL certificate it is connecting to? If not, you might be sending it to any rogue device that pretends to be your server.
    – Matthew
    Mar 21, 2016 at 16:45
  • 2
    What the other comments are alluding to is, how does the device verify that the server is legitimate? Is there also a preset key to got the other way? Is the encryption certificate pre-authorized? If not, it is subject to all sorts of simple attacks by anyone who can impersonate the server.
    – Jeff Meden
    Mar 21, 2016 at 16:51
  • 1
    @DC177E: if you are using SSL anyway then why not identify each device with a client certificate? This way the secret is always kept at the client (unlike with a password which need to be verified by the server).
    – Steffen Ullrich
    Mar 21, 2016 at 17:11
  • 1
    Ok, so you're making progress at understanding this protocol. It sounds like the link between the device and the chipset manufacturer is ok. Now you need to investigate the connection between the chipset manufacturer and your server.
    – Mike Ounsworth
    Mar 21, 2016 at 18:07

3 Answers 3

Reset to default
3

Alright, the main concern here is that an attacker could intercept the traffic between the chipset company and your server.

How does the device know it's talking to the correct server? If I intercepted the traffic between the device and the server and pretended to be the server, would the device happily give me its password?

The "correct" way to do this is to use client-authenticated SSL. This means that instead of a "password", each device gets a unique RSA or ECC keypair, and a corresponding certificate from the server (which is a Certificate Authority in this case). This allows you to use the bi-directional Client-Authenticated TLS Handshake.

There are secure ways to do authentication using a pre-shared secret known to both server and client, but "here's my password, make sure it matches!" is not one of them (at least not without independently solving the "how do I know I'm talking to the correct server?" problem). One way is having both ends MAC the massage with a key derived from the shared secret. Then the other party can compute the same MAC using their copy of the shared secret and make sure they come up with the same MAC. Another way is to use AES in Authenticated Encryption (AE) mode.

... Or as @SEJPM points out, skip the whole "rolling your own" thing and just use one of the Transport Layer Security pre-shared key ciphersuites (TLS-PSK).

Improve this answer
1
  • 1
    concerning your last paragraph: TLS-PSK is the real proper way.
    – SEJPM
    Mar 21, 2016 at 17:36
1

Without the client verifying the server, any scheme like this is vulnerable to impersonation. Specifically, by implementing a fake server, and forcing the client to connect to it (perhaps through a firewall rule), the fake server would receive the details sent by the client, and could then use those to send further malicious content to the legitimate server.

In order to protect against this, the client could compare the certificate of the legitimate server with that of the server it is connecting to, and only send data if it matches. However, this would require the client to know the public certificate corresponding to the private part used by the server, which isn't always possible in embedded devices (they tend to lack the ability to update upon certificate changes, for example).

Therefore, it would be possible to use other methods which allow for both ends to verify the other: perhaps a nonce, generated by the server and sent to the client, hashed using a pre-defined method (e.g. concatenating a pre-defined string to the nonce, and then hashing with a cryptographic hashing algorithm), and returned. Since the pre-defined string is never sent, this should be difficult to break without access to either the device, or the server (both of which need to know the string), even if you know the nonce for a given request.

Essentially, you need to verify that you are communicating with the expected other device, from both ends, to be sure that your data can't be tampered with. This does involve multiple steps though.

Improve this answer
0

At the risk of being overly broad, your solution is secure barring two circumstances.

"Each device has its own copy of the Particle cloud public key"

This means that (barring a software bug allowing something like tricking the client to use a weak version of TLS/SSL) the device will only be comfortable talking to the server that has the correct private key, namely the "Particle cloud" host. Therefore the server and device have a form of two-way authentication and it's done in secret so there is confidentiality and nonrepudiation.

The other loose end is, what happens if the Particle Cloud private key were to be compromised? Proper certificate management (via a CA) allows for this inevitability by invalidating a key and replacing it with a new one. If the key is hardcoded this sounds like it is only possible via a firmware update.

Are firmware updates available in-band? out of band? only as part of this cloud mechanization? not at all? The answer to that might be what determines how comfortable you are with believing that the communication channel is ready for life-safety applications. Any issue with these two caveats might leave the devices woefully unprotected until a firmware update to patch the issue is done to all devices, in a secure way (cant trust the cloud to push it any more if the key is compromised, eh?)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .