31

If you can plug a device into the wall, or use it in Wi-Fi, it's easy to see the traffic with software like WireShark.

But it seems more tricky to do it with a device that uses LTE/3G or other cellular networks to communicate.

If I'm worried about a device that could send some personal information without my consent, is unplugging it and returning it to the store the only solution?

What about devices that communicate using LoRaWan/LPWAN?

chicks
  • 103
  • 4
WayToDoor
  • 818
  • 7
  • 15
  • 5
    I suppose if the data is encrypted even if we sniff the traffic using tools, it is of no use. – bravokeyl Dec 06 '16 at 18:19
  • 5
    Keep in mind that sniffing wireless traffic is illegal in many jurisdictions since you can't avoid sniffing other people's traffic. – Helmar Dec 06 '16 at 23:21

3 Answers3

17

I have been professionally developing a "device that use LTE/3G or other cellular networks" for decades now, and WireShark is one of our major test tools. Data can be encrypted (generally at layer 2, which is an option, or layer 4, by writing code to do so), but much (most?) is not.

If I'm worried about a device that could send some personal information without my consent is unplugging it and returning it to the store the only solution.

If you do not have access to the source code, then you cannot trust the device, or the communication channel.

Mawg says reinstate Monica
  • 3,110
  • 1
  • 12
  • 34
  • 1
    So you are saying that most of traffic from IoT devices I use is - not secured and - can be easily read by a potential attacker ? That's scary! – WayToDoor Dec 06 '16 at 18:36
  • 1
    Just follow online publications. For instance http://www.theregister.co.uk/ regularly exposes flaws, including devices which transmit even password in cleartext. Google for more. Rule #1 is *always* to immediately change any passwords that the device may have. – Mawg says reinstate Monica Dec 06 '16 at 18:45
  • 1
    Recommended reading - http://www.theregister.co.uk/2016/12/05/how_to_survive_iot_security_nightmare/ – Mawg says reinstate Monica Dec 06 '16 at 18:46
  • 3
    That doesn't answer the question of how to intercept LTE and 3G traffic (even assuming it isn't encrypted at the application level). – Gilles 'SO- stop being evil' Dec 07 '16 at 00:55
  • 1
    Even if you do have access to the source code, how do you know that it's what's actually running on the device? And how do you know what the source code is really doing? Open source helps but it doesn't solve the problem. – Gilles 'SO- stop being evil' Dec 07 '16 at 00:56
  • Well, I tend to code myself, but , of course, I only code the app, not, for instance, the TCP/IP stack. It is generally agreed that all that you can do, to be safe(r) is to take the sources of everything from a trusted source and build and install them yourself. Something like https://www.gentoo.org/, but for IoT – Mawg says reinstate Monica Dec 07 '16 at 08:13
10
  1. 3g v Wifi Security
  2. Standard wifi v LoRaWan/LPWAN
  3. If I'm worried about a device that could send some personal information without my consent is unplugging it and returning it to the store the only solution.

3g v Wifi Security

It is possible to sniff 3G signals, e.g. , however of more concern might be ensuring the packets cannot be decrypted on the cloud receiver end, where they can be easily wiresharked. In order to avoid this a good device encryption level protocol could be used.

On the WiFi side, yes you can sniff more easily but again if the message is encrypted, it doesn't matter.

The AWS platform offers really strong security.

AWS IoT supports the following certificate-signing algorithms:

[SHA256WITHRSA][1]
SHA384WITHRSA
SHA384WITHRSA
SHA512WITHRSA
RSASSAPSS
DSA_WITH_SHA256
ECDSA-WITH-SHA256
ECDSA-WITH-SHA384
ECDSA-WITH-SHA512

So using this security stack your data cannot be brute force sniffed at source as it would currently take billions of years. I am familiar with AWS but assume azure has a similar offering which of course you could implement separately.

In summary, the transport protocol does not matter. Take your security pick, (3G or wifi). If implemented properly both are secure assuming the hackers are not microscopically x-raying and modelling the silicon of your IoT device. Perhaps if you see someone in your house with a star trek type X-Ray machine it is time to worry?

Standard wifi v LoRaWan/LPWAN

Let's rate against SHA256withRSA

LoRaWan

Each device is provisioned with a unique AES 128 key

To my knowledge AES 128 is un-crackable.

LPWAN

LPWAN is not a standard. It includes:

LoRa / SigFox/ WAVIoT NB-Fi. So you need to evaluate the security of each protocol falling under LPWAN. As we have seen LoRa is pretty secure.

If I'm worried..

I would suggest talk to the manufacturer first, see what data they collect, maybe it is harmless? If you are still suspicious and don't believe them and don't have access to the source code, then maybe it is time to return it.

Bence Kaulics
  • 7,783
  • 8
  • 41
  • 90
SeanJ
  • 1,245
  • 8
  • 19
  • 1
    "To my knowledge AES 128 is un-crackable." This is a common misconception. Yes, AES-128 itself is very good, but for this to work you have to exchange the keys somehow and this can make the system very vulnarable, see the reports about security flaws in ZigBee. – koalo Sep 20 '18 at 10:35
0

You may use several different LPWAN technologies (NB-IoT, LoRaWAN, Sigfox, etc.) to connect an end-device to a Target Network. Most of these technologies encrypt the device-data and you cannot intercept the traffic just by listening to the radio traffic. However, please note that the Target Network, does not have to be the Internet. It can be your private network or your even Application Server. You can intercept the traffic there.

If your device vendor sells devices as part of an end to end solution including an Application Server in the cloud (Internet), you may still have concerns on whether your App Server provider uses your data properly. If you want to intercept the traffic in that scenario, you can set up a proxy app server in your private network that forwards the data to the real App Server and you can intercept the traffic there. Please note that this technic can only work because - at the time being - most of the LPWAN connectivity services decrypt the data (and optionally reencrypt it with the subscribers' key) before forwarding to the Target Network.

If your App Server provider implements E2E security, without sharing any keys with you, you have no way to intercept the traffic..

Norbert Herbert
  • 802
  • 2
  • 11