This content originally appeared on Level Up Coding - Medium and was authored by Teodor J. Podobnik, @dorkamotorka
Securing IoT Networks with ToR
Protecting User Privacy and Confidentiality in the Age of Connected Devices
The Internet of Things (IoT) has seen a surge in popularity in recent years, leading to a significant increase in the number of connected devices that make use of public services. For example, in a Smart City, Smart Home Systems may use open services to access data like weather information. However, this can also pose a risk to a user’s privacy by revealing their location. To combat this, it is essential to access these open services anonymously. In this post, I will guide you through an end-to-end anonymity solution using Docker that utilizes the basic principles of onion routing.
Onion Routing
Onion routing is a widely recognized method for providing anonymous internet communication and is implemented in the Tor network. The fundamental concept of onion routing is to conceal a user’s identity by routing a message (such as a request for an IoT service) through various intermediary nodes (routers) while encrypting or decrypting the message at each node. This technique helps to protect the user’s privacy and ensures that their location remains confidential.
Components of the System
The system we’ve designed to secure IoT networks with onion routing is composed of multiple components, each of which has been isolated and containerized using Docker technology. This allows for a secure and efficient way to manage and deploy the different parts of the system, ensuring that each component is protected and runs independently. By utilizing Docker, we are able to maintain a high level of security and flexibility, making it easier to update and scale the system as needed. Additionally, Docker containers are lightweight and portable, allowing the system to run on a variety of platforms, making it more accessible and adaptable. Overall, using Docker technology allows us to provide a robust and secure solution to protect user privacy in IoT networks.
The originator/Client
In an onion routing infrastructure, the end user’s machine, also known as the originator, receives a chain from the directory node. This chain is then used to route requests and responses within the infrastructure. For the user, this process is made easy through the use of a frontend built with Flask, a popular Python web framework, and Cirrus CSS, a lightweight CSS framework. This combination of technologies provides a user-friendly interface that makes it easy to navigate and utilize the onion routing infrastructure:
Chain nodes
In an onion routing infrastructure, the routing chain is composed of three key nodes: the Entry Node, the Intermediary Node, and the Exit Node. These chain nodes play a crucial role in routing requests and responses, based on routing information received from the originator while preserving the sender’s anonymity through on-the-fly decryption and encryption of the payload. The Entry Node acts as the first point of contact for the originator’s request and is responsible for encrypting the payload and forwarding it to the Intermediary node in the chain. The Intermediary Node, as the name suggests, relays the request from the Entry node to the Exit node which acts as the final hop for the request and is responsible for decrypting the payload and sending it to the API Server, and relaying the response back through the network. Together, these nodes play a vital role in ensuring anonymity for the sender in an onion-routing infrastructure.
The following code snippet depicts the main functionality of the chain node and how the message is routed through the network:
Directory node
The directory node plays a crucial role as the main orchestrator in the onion routing architecture. It is responsible for preserving a list of available chain nodes and providing a fresh, randomized list of nodes to clients every time a message needs to be routed. This approach ensures that the client’s request is always routed through different nodes, making it more difficult for an attacker to trace the origin of the request. Additionally, the directory node is responsible for performing simple load balancing to ensure that the nodes in the architecture are utilized efficiently, and it also maintains the healthiness of the nodes, which is essential to ensure the smooth functioning of the infrastructure.
Here’s a short snippet of the directory node's main functionalities:
Weather API Server
The Weather API is a simple REST server that exposes a single endpoint, providing random weather data in response to client requests. The API is designed to be easy to use, and the RESTful design allows for easy integration with other systems and applications. The endpoint is designed to respond to requests in a standardized format, making it easy for clients to parse and utilize the data. The weather data provided by the API is randomly generated and does not reflect actual weather conditions in any particular location.
Okay, we got all these things but how does it work — what actions does the system perform internally?
Proof-of-Concept
As soon as the chain-node launches, it generates an RSA public and private key pair and authenticates to the directory node using the following request format:
{
'name': [random name],
'kind': [entry, intermediate, exit],
'address': [hostname:port],
'public_key': [RSA public key - PEM encoding]
}Directory-node maintains a list of all the authenticated chain nodes that it can offer to the client per request.
Once the client requests the chain route (nodes) from the directory node, it also builds the message that needs to be sent. This message is then encrypted in layers, with each layer being encrypted with the public key of the next node in the chain. This process is called onion encryption, as the message is wrapped in multiple layers of encryption, similar to the layers of an onion. This process helps to preserve the anonymity of the sender, as the message is decrypted and re-encrypted at each node, making it difficult for an attacker to trace the origin of the message.
The message format sent to the network as well as between all hoops looks like this:
{
'enc_key': [encrypted symetric key - BASE64 encoding],
'enc_payload': [encrypted payload - BASE64 encoding],
'hmac': [MAC - HEX encoding]
}hmac is generated by calculating:
{
'enc_key': [encrypted symetric key - BASE64 encoding],
'enc_payload': [encrypted payload - BASE64 encoding],
}where enc_key is a symmetric key (generated by the client) encrypted with the public key of a specific chain-node. This key can only be decrypted using the corresponding private key of that chain-node. The decryption of enc_key, using the private key, results in a decrypted symmetric key that can be used to decrypt the enc_payload which decrypts into the following format:
{
'dst': [next chain node address],
'enc_payload': [encrypted payload for next chain node],
'endpoint': [optional-endpoint]
}enc_payload for the next chain-node is sent forward to the dstthat perform the same steps as described above until the message reaches the API Server. There is an optional endpoint key that can be used to send traffic on a specific API Server endpoint.
During the request routing process, the decrypted symmetric key is stored and used to encrypt the payload during reply routing. This ensures that the API server’s reply is encrypted three times on the way back, providing an extra layer of protection. And with each encryption, the message is recursively decrypted on the client side, guaranteeing that the communication is secure.
An example reply looks like this:
{"date": "2018-03-17", "tmin": 34, "tmax": 71, "prcp": 0.27, "snow": 0.0, "snwd": 0.0, "awnd": 6.26}The complete project can be found on my GitHub Account:
GitHub - dorkamotorka/IoTOR: Securing IoT Networks with Onion Routing and Docker
Conclusion
In conclusion, the described system provides a comprehensive solution for securing IoT networks through the use of onion routing. The architecture utilizes Docker technology to isolate and containerize different components, while the directory node acts as the main orchestrator. The chain nodes play a crucial role in routing requests and responses while preserving the sender’s anonymity through on-the-fly decryption and encryption of the payload. The system also uses advanced encryption and routing techniques to ensure that the communication is secure, providing an extra layer of protection and preserving the user’s anonymity. All these features combined make the system a robust solution for securing IoT networks and protecting user privacy.
Thanks for reading! 😎 If you enjoyed this article, hit that clap button below 👏
Would mean a lot to me and it helps other people see the story. Say Hello on Linkedin | Twitter
Do you want to start reading exclusive stories on Medium? Use this referral link 🔗
If you liked my post you can buy me a Hot dog 🌭
Checkout the rest of my content on Teodor J. Podobnik, @dorkamotorka and follow me for more, cheers!
Securing IoT Networks with Onion Routing was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Teodor J. Podobnik, @dorkamotorka
Teodor J. Podobnik, @dorkamotorka | Sciencx (2023-06-04T15:52:53+00:00) Securing IoT Networks with Onion Routing. Retrieved from https://www.scien.cx/2023/06/04/securing-iot-networks-with-onion-routing/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.