I am currently working on a project that includes Bluetooth communication between a mobile application (currently using the Ionic platform) and an embedded device. For comparison, our product is similar to a smart lock.

Security is of utmost concern, and we are looking into ways to ensure our hardware and software are not hackable. What steps should we take to ensure our system is secure?

Edit: Yes, we are currently encrypting communications, and using HTTPS when the device communicates with our server.

  • Use HTTPS? Are you coding both devices? Encryption?
    – Mawg
    Commented Dec 6, 2016 at 18:13
  • 1
    Consiedr also asking at security.stackexchange.com
    – Mawg
    Commented Dec 6, 2016 at 18:13
  • 2
    @Mawg As far as I'm aware HTTPS is not applicable to bluetooth (or at least, not in a normative/sane sense).
    – goldilocks
    Commented Dec 6, 2016 at 18:20
  • 1
    I'm voting to close this question as off-topic because this fails to show how this is IoT specific. It's just securing communication between devices.
    – Helmar
    Commented Dec 6, 2016 at 20:43
  • 4
    @Helmar Communication between devices is a pretty important feature of IoT, even a defining feature, so I fail to see why this question would be off-topic. Commented Dec 7, 2016 at 0:28

2 Answers 2


To ensure that your device is secure enough, I have several tips:

  1. Add some encryption to the Bluetooth communication. I'd recommend keeping the encryption keys off air. For example, you might ask the user to scan a QR code that's on the device, on printed in the box etc. at the initial setup of mobile app, maybe with an AES key? Up to you. This is to prevent someone from seeing the password transmitted over the air with plain text.
  2. If you can, stay away from ECB (use CBC) mode of the encryption algorithm you pick, as it might give some info on the data transmitted. More info on that can be found here.
  3. On the bluetooth data transmission, make sure to include some unique ID, so that the message can't be repeated (for example, you might include a timestamp). You might also implement some TOTP-like system.
  4. Put a port on the device that allows it to be easily flashed, so that in case you realize the software has a bug (and for some reason you can't update it OTA), the device is not an expensive paperweight, just a device that needs to be plugged into a PC and flashed to new software.
  5. Extra: To ensure that someone with a rogue root cert (probably self-issued and installed on client device) can't intercept your server communications, verify the HTTPS certificate. Here is a SO asking it for Android, you must be able to find similar resources for iOS too.

Also, if you want to learn more about cryptology and encryption you'll use to secure your device, check this (free) ebook. It talks a lot about good and bad implementations of encryption algorithms, and should help you with securing your product. (Note 1: Please, please do not create your own algorithm. Note 2: I'm not affiliated with crypto101 or lvh.)

  • 2
    “If you can, stay away from ECB”. No, bad advice. Passable advice would be “never use ECB”, but it's still imcomplete. A better answer would say that if you're typing the letters C-B-C into your code, you're doing it wrong. In particular AES-CBC does not ensure the integrity or authenticity of communication. Commented Dec 7, 2016 at 0:26
  • @Gilles ECB is certainly better than all the iot devices out there nowadays that just transmit stuff as plaintext or simply xor with a set value, but yes, ECB doesn't nearly get your product to "not hackable" (technically nothing does, but you can attempt to do something that'll keep it as secure as currently possible for the longest amount of time, and that, doesn't involve ECB, but a proper implementation of AES-CBC 256).
    – ave
    Commented Dec 7, 2016 at 0:33

If you can have end-to-end TCP, then use end-to-end TLS (e.g. with HTTPS).

Don't reinvent the wheel, especially when it comes to cryptography — most people get it wrong. Unless the device is too resource-constrained to support TLS, if you get down to the level of AES, you're doing it wrong. #1 mistake is to encrypt and forget to authenticate — if you have an encrypted channel between your server and a man-in-the-middle, instead of an encrypted channel between your server and your device, then encryption hasn't provided any benefit. If you can't use TLS, make sure that whatever protocol you're using authenticates everything, and encrypts what needs to be confidential.

To use TLS securely, think about what guarantees you need to have, from the point of view of each participant. Generally the device needs to know that it's talking to the legitimate server. That means that it must check the server's certificate. The device must have the X.509 certificate of a certificate authority recorded as trusted; this requires storage that can't be modified by an attacker, but it doesn't require any confidentiality of the storage. Note that you shouldn't hard-code the server's certificate directly, because that wouldn't let you easily replace that certificate if it's compromised. Instead, the device stores the expected identity (host name) of the server, and the certificate of a certificate authority that guarantees that a certain public key belongs to the expected host name. Once again, don't reinvent the wheel, rely on the certificate checking provided by your TLS library or application.

If the server needs to know that it's talking to a legitimate client, then each client needs to have its own client certificate. That requires confidential storage on the client. Pass the client certificate to the TLS session opening function from your TLS library, or set it in the application configuration.

That takes care of securing the communication between your server and your device. If the mobile application can talk to the device directly (e.g. to allow disconnected operation while it's on the local wifi network), you need to first perform pairing between the smart switch and the mobile phone. Pairing means an exchange of keys, preferably an exchange of public keys if resources permit, otherwise an agreement of secret keys. The goal of this pairing is to ensure that each device knows who it's talking to.

You'll need to secure the control channel as well, whether it goes directly from the mobile device to the smart switch or via a server. Think about authorization: are there different levels of access to the switch, e.g. a control level that allows doing reconfiguration and a basic channel that just allows on/off switching? This is generally handled by an authentication step after establishing the secure channel (TLS if possible).

Another consideration is firmware updates. That's a tricky one: on the one hand, there's no such thing as absolute security, so you will have security patches to apply now and then. On the other hand, a firmware upgrade mechanism is a complex thing and might itself have bugs. At the very least, make sure that your firmware upgrades are signed. Relying purely on the security of the communication channel for upgrades is dodgy, because the trusted based for a secure channel is larger than for a static security verification, and sometimes you might want to apply firmware updates without a network connection. In addition to verifying the signature, ideally you should have some protection against rollback, so that an adversary can't just push an “update” to version 1 on a system running version 2 and then exploit the security hole that version 2 patched.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.