Intercepting the web traffic from an IoT device

WayToDoor
  • Intercepting the web traffic from an IoT device WayToDoor

    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?

  • 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.

    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.

Tags
security privacy lpwan mobile-data
Related questions and answers
  • 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?

  • There are two MQTT Brokers, the connection between them should enable traffic shaping. Broker A has multiple clients who publish data, Broker B has multiple subscriptions. Is there a possibility to enable traffic shaping on the connection to ensure that very publisher hast a minimum of granted bandwidth on the connection to broker B? This scenario is implemented using the Mosquitto MQTT broker with the broker-bridge feature to ensure every MQTT message will be send only once over the connection between broker A and B.

  • There are two MQTT Brokers, the connection between them should enable traffic shaping. Broker A has multiple clients who publish data, Broker B has multiple subscriptions. Is there a possibility to enable traffic shaping on the connection to ensure that very publisher hast a minimum of granted bandwidth on the connection to broker B? This scenario is implemented using the Mosquitto MQTT broker with the broker-bridge feature to ensure every MQTT message will be send only once over the connection between broker A and B.

  • I need to allow two devices to communicate by generating a set of pulses (in the range of 100 to 1K HZ) in one device to be received by another device. The two devices are very near each other (say 5mm) and both devices have their own power. I could create two pins to connect the two devices, but this means that I need to design a case that connects the two pins and make sure that they always connect in the field. Can I transfer these pulses using a contact less method? The solution should be very cheap (less than 1USD) and low power (less than say 1mw consumption). So solutions

  • I need to allow two devices to communicate by generating a set of pulses (in the range of 100 to 1K HZ) in one device to be received by another device. The two devices are very near each other (say 5mm) and both devices have their own power. I could create two pins to connect the two devices, but this means that I need to design a case that connects the two pins and make sure that they always connect in the field. Can I transfer these pulses using a contact less method? The solution should be very cheap (less than 1USD) and low power (less than say 1mw consumption). So solutions

  • based OS. THE QUESTION How would you go about creating a Tor Hidden Service in Windows IoT Core, and route the Universal Application traffic through Tor to Azure? ...The Background I'm prototyping some basic home automation software using Windows IoT Core and Azure. I have built a Windows Universal Application that sends data to a Web App hosted in Azure via Web API. (token based auth) The Problem I don't want people sniffing my network and trying to breach either the Pi or the WebApp/database! - The data sent via API is very sensitive and should

  • based OS. THE QUESTION How would you go about creating a Tor Hidden Service in Windows IoT Core, and route the Universal Application traffic through Tor to Azure? ...The Background I'm prototyping some basic home automation software using Windows IoT Core and Azure. I have built a Windows Universal Application that sends data to a Web App hosted in Azure via Web API. (token based auth) The Problem I don't want people sniffing my network and trying to breach either the Pi or the WebApp/database! - The data sent via API is very sensitive and should

  • According to this article from The Register, a university network was recently brought down by what was essentially a DDoS attack from various connected devices on the network campus (specifically vending machines and the like): A US university saw its network traffic slow to a crawl thanks to an IoT malware infection that hit, among other things, its vending machines. The story, as told... that the school's DNS servers were buckling under heavy traffic loads. Much of the lookup traffic (requesting seafood-related subdomains, oddly) was suspected to be from a botnet. After some investigation

  • According to this article from The Register, a university network was recently brought down by what was essentially a DDoS attack from various connected devices on the network campus (specifically vending machines and the like): A US university saw its network traffic slow to a crawl thanks to an IoT malware infection that hit, among other things, its vending machines. The story, as told... that the school's DNS servers were buckling under heavy traffic loads. Much of the lookup traffic (requesting seafood-related subdomains, oddly) was suspected to be from a botnet. After some investigation

Data information