Can someone point me to a doc or site with information about how to build the encrypted section(s) of a zigbee packet? I'm looking at the output of a zigbee sensor system and I can see where most of the 'data' packets are being produced but there is a section call NWK Payload that is encrypted. I've watched the whole sequence of the connection with the 'base station' and I don't see where any sort of encryption key is being passed.
This shows the section I'm referring to. The packet analyzer has figured out the rest.
Long term goal is to build these packets and use the sensors separately from the 'base station'. To do that I need to be able to replicate the whole communication cycle.
In Zigbee there is are two keys used for encryption: the Link Key and the Network Key. The Link Key is used during the network association process, and the Network Key is used to encrypt all traffic once the device is "associated" (also referred to as "joined") to the network.
If the device is HA (Home Automation), the security handshake goes something like:
Joining Device sends Association Request to the Trust Center (usually address 0x000)
Trust Center responds to joining device with a NWK Key packet. The contents of this packet are encrypted using the well know Home Automation Link Key.
You should be able to decrypt the NWK Key packet if you know the Link Key. I'm pretty sure I can't post the key (sorry), but you can probably find it online.
As for the actual encryption algorithm, that's defined in the main Zigbee Specification, which I believe you have to be a member to gain access too. There are a few open source Zigbee stacks though ZBoss and FreakZ.
You might also look at Wireshark, I believe they have a decent Zigbee packet decoder though I haven't used it personally.
We use here the Perytons sniffer (http://www.perytons.com).
They have an Add-On with which you can create, edit and transmit messages (in parallel of doing the capture). We also use the add-on for "constructing" the ZigBee packets and encrypt it based on what you need so you can consider using it for debugging your encryption process.
They have a 30 days free evaluation with some of the TG Add-On options enabled ;-).
Hope this helps.
Related
I want to know if my BLE 5 (low energy, not "typical"/core bluetooth) embedded system uses (preferably asymmetric) encryption, if encrypted at all.
I'm using this ble module that is communicating with an SOC. My SOC is capable of encryption but the FAE of the BLE module product couldn't come up with any useful information.
My program doesn't appear to have a bonding/pairing process, but I could be wrong since I did not take a closer look at the HAL layer program.
My question is, does BLE 5 require encryption?
If not, how do I find out if my connection is encrypted or not, using methods other than sniffers? For example are there any steps which must be gone through to facilitate encryption, in which case I should check if these steps were skipped or not? (If skipped then surely my communication is in plain texts).
ETA: The target BLE module is based on nrf52832, don't know what BLE stack/softdevice they are using. My soc is STM32WB55 series, using a rather comprehensive BLE stack that supports most functions of which name I couldn't recall for the moment.
BLE does not require encryption for a connection to be made.
At first, every BLE connection starts in Security Mode 1, Level 1 which does not use any encryption at all. Every message will be sent in cleartext. To increase the security two devices have to "pair". Security keys are exchange during the pairing process. There are multiple different pairing methods with different requirements. Have a look at this article for a starting point.
The pairing process is usually not started manually but automatically as soon as a device tries to access a secured characteristic. If you are using a phone to access such a characteristic you will be prompted with a pairing request popup. Based on your description I would assume that your connection is currently not encrypted.
To enable encryption on your SoC please have a look at the function aci_gatt_add_char. This document (direct download link) refers to this function on page 55 and shows that it takes Security_Permissions as an argument. The next page states the possible options as:
0x00: ATTR_PERMISSION_NONE
0x01: Need authentication to read
0x02: Need authorization to read
0x04: Link should be encrypted to read
0x08: Need authentication to write
0x10: Need authorization to write
0x20: Link should be encrypted for write
I am completely new to ns3. All the tutorials that are given in the repo mainly consist of echo servers where they are sending a packet of specific size and receiving the echo. I want to design a real world scenario where the server offers some service. e.g. the client node takes a string in lower case as input and sends to server. The server changes it to upper case and returns to client and client prints it on console. How to model this exact situation in ns3 ? I could not get any solution even after searching for a lot of time and I am not getting any way of actually interacting with the user in ns3.
Your question is very general and cannot be answered in a few lines. You can find the ns3 repository here LoRaWAN ns-3 module. It contains end devices, a gateway, and a server. A server is responsible for interacting with end devices in many ways. For example, the network server can control the end device's data rate, transmit power, and bandwidth. It also notifies end devices with downlink acknowledgment through a gateway. Based on my opinion, this module can be helpful for your mentioned scenario. If you do not want to violate the tcp/ip protocol stack you should modify the MAC commands used in this module to fulfill your needs.
If StackOverflow is the wrong Exchange for this question, please help direct me to the correct one.
Short Version
What is the best design for a networking application in which one user transmits a constant, high-bandwidth stream of data to many other addresses? The solution must not require the uploader to duplicate the packets for each recipient and preferably will not transmit to users that have not been accepted by the transmitter.
Long Version
A friend and I have written an application that enables someone to transmit data in real time to one or more recipients that he wants to receive the data. I have designed the high-level application protocol to use UDP and to encode the data so that each packet can be lost without hurting the use of the rest. This solution requires managing sockets with each user and sending each packet to every user.
The problem here is that the stream can be very high bandwidth. The user can modify the settings for how high quality the data he is sending should be, and can end up sending 6 Mbps to each user. It is unfeasible to expect a user to pay his ISP enough to be allowed to upload such a stream to the preferred minimum of four other users at a time.
We need a way for the transmitter to send a packet exactly once and have each user receive a copy.
We have looked at multicasting. It may be what we need to use in the end, but we are concerned about the fact that anyone can join any group. It would be preferable to not allow users we do not want to see the data to not be allowed to join in. There is also the problem that if multiple transmitters happen to use the same group, viewers may find that they are receiving multiple streams' worth of data when they only want one.
My searching has revealed something IBM published over a decade ago called Explicit Multicast (Xcast) that looks perfect, but I have yet to find any information to determine whether this technology is commonly supported. Also, I have not yet seen whether it supports datagrams.
Does anyone know the best way to design an application that meets our needs?
Please keep in mind that we have no funds to support our project. Solutions need to be free.
Edit
In the summary above, I hinted at but failed to explicitly state that this is for a real-time application. The motivating drive behind the application is to keep the clients/recipients as close together in time as is possible. If packets are lost or arrive too late to be used in keeping the server and clients in phase, they need to be disregarded. That is why I designed the application protocol on top of UDP with independent data in each packet. Even if a client receives only one packet out of 300 for a given time step, it will use what it did get.
I think that I_am_Helpful's recommendation may be a good step in the right direction (or possibly the destination). I need to do some experimentation to determine whether using a system like Spread will work. However, I do not think I can budget more than additional 17 ms in transmission time.
If you can think of a system that enables sending unreliable datagrams to a specific group of users (like Spread) for a real-time application (unlike Spread, see p. 3), please let me know about it.
We need a way for the transmitter to send a packet exactly once and
have each user receive a copy.
In my limited knowledge, I would say that Reliable Multicasting appears to be one of the viable option for broadcasting in the group. I would like to mention that there are some of the possible Java API's* which could help you achieving the same :
JGroups Java API
The Spread Toolkit -> Spread consists of a library that user applications are linked with, a binary daemon which runs on each computer that is part of the processor group, and various utility and demonstration programs.
Appia
*NOTE : I have never worked with these API's.
It would be preferable to not allow users we do not want to see the
data to not be allowed to join in.
They do provide this feature, e.g., Spread supports thousands of groups with different sets of members. It also provides a range of reliability, ordering and stability guarantees for messages. JGroups can be used to create groups of processes whose members can send messages to each other. It also has facilities like group creation and deletion(Group members can be spread across LANs or WANs).
There is also the problem that if multiple transmitters happen to use
the same group, viewers may find that they are receiving multiple
streams' worth of data when they only want one.
When you could easily create multiple groups in the same network(using Spread,etc.), then, I believe that would no longer be an issue. It is your responsibility to declassify users into different groups.
I hope the given information helps. Good LUCK.
Via multicast you achieve exactly you want: sending each packet once, but authentication seems to be a concern for you.
One possible solution could be simetric cryptography, where the same key is used to encrypt and decrypt. Via TCP your clients connect to a server and fetch the multicast IP Address of the transmission and its associated key, then they join the multicast group and decrypt the incomming transmission.
If you accept a more flexible solution, you could have a server which sends a transmission in real time to a set of distributed servers. Your clients connect to one of these distributed servers via unicast, and after authentication is done, they are inluded in a list of receivers. Each distributed server sends each new transmission packet to each registered client via UDP. in ordinary situations your clients would have the same experience as if it was delivered in a multicast group, but the servers will spend far more bandwidth. Multiple transmission at a time will be allowed, so it could be good for you, and you can have more control, as clients can send signals to the servers, like PAUSE, and etc.
I'm a young professional who's into embedded design, IT networking, control/monitoring systems and much more. Currently, I'm developing a monitoring system using a device from Tibbo Techonology, their DS1102.
http://tibbo.com/products/controllers/ds110x/ds1102
It's a programmable device that covers serial and ethernet communications. For my project, its main tasks are serial data collection and database population. Serial communication is done through RS485 and database used is MySQL 5.5. My database is hosted on a public IP which also runs a webserver for the interface while my device is behind a NAT. It connects to the database directly using the public IP.
I'd like to ask for advices so that I can enhance and upgrade it. Right now these are the
questions I'd like to ask.
Which is better? Having the server on a public IP or using port forwarding?
I'm also using it as webserver for the interface of my monitoring system.
To communicate with the device (rebooting, changing IP etc), I wrote an application in
python using UDP (using port 65535 of device) and also set the device to communicate with the application for specific commands. My concern is I want to encrypt the communication between my python app and the device both ways. The only available function for both encrypting and decrypting on the DS1102 is RC4. What are your thoughts on using RC4 for this application? Also, I'm planning to do port forwarding on port 65535 so that I can use my python app from the outside. Can RC4 be reliable for this too? I really want to learn how to use encryptions properly.
I'm also planning to implement SMTP for alert messages. Tibbo has a sample code from which I based mine. Problem is, it's on AUTH PLAIN LOGIN. I think I want to turn it to STARTTLS later. Can you recommend some lessons on the algorithm of STARTTLS?
What are those details on MAIL FROM:<> and RCPT TO:<>? Because on using the command
DATA, the programmer can write anyway From: and To: which can make his identity someone else.
That's it for now. Suggestions are very welcome.
You can also share some good reading materials and links. I'm always hungry for learning. :)
Thanks for your time.
2.
Encryption substitutes the confidentiality of an arbitrary amount of data (the plaintext) with the confidentiality of a small amount data (the key). In other words, your communication is only as confidential as the key – if the shared secret key leaks out, the encryption is worthless. More on this.
Also note that plain RC4 provides no authenticity (message integrity). An adversary can modify messages as much as he wants. He can even send his own messages which will be considered perfectly valid by the cipher. Verifying the validity of the messages is is up to the code that parses the messages.
If your messages are simple (only a few bytes or so), an adversary could simply send random bytes until they decrypt such that they form a valid message, without knowing anything about the key. This happens on average after only 100 attempts for a 1-byte message for example.
You will obviously have to use some sort of a nonce to prevent trivial replay attacks.
RC4 is also rather quirky per se. I guess you are already aware of the numerous "drop-n" variants and so on.
In short, protocol design is perilous. Even experts often get it wrong (look at WEP for example). The most straightforward way to solve this would be to find hardware that can handle an existing protocol such as TLS.
I'm experimenting with my Arduino Mega. I also have an Arduino Ethernet Shield.
I need to send emails using them, without the help of a computer (or any other device; like a smartphone, etc.). Though I could find several articles, I couldn't find any acceptable solution...
How can I do it? As I'm not asking this to be used for any special application, you can
make any assumption about missing details.
From the discussion above in comments it sounds like you either need code from someone who has just done it for you or you need to take the time to learn about the components and find or make the components.
They wouldn't make an Ethernet shield for this platform if it was only useful for non-standard packets. So someone somewhere has created some level of an IP stack.
Backing up though, in order to send mail you need to learn the Simple Mail Transfer Protocol (SMTP). Almost all Internet protocol definitions are defined using something called RFCs (Request for Comments). So if you google SMTP RFC you will find RFC 2821.
IETF is Internet engineering task force. There will be many copies of these documents on many websites. And due to the age of the Internet and these protocols in many cases you will find that one RFC has been created to replace a prior one. Version numbers are not used, but it is kind of like HTML 1.0 then HTML 2.0 and so on. I recommend even though the RFC says that it completely replaces RFC xyz, go find RFC xyz and read it. I go back as far as I can find learn that one then work my way forward.
Many/most protocols that ride on top of TCP (TCP is yet another protocol defined in an RFC, more on that later) are ASCII based, makes it very easy to, for example, Telnet to learn/experiment with the protocol, you can probably use Telnet to learn SMTP.
Most protocols are some sort of a half duplex thing, make a connection and often the server sends you a string, you see that string and then you send some sort of hello string, the server responds with some sort of OKAY or fail status. For SMTP, you then do some sort of I am mailing from this email address, server says OKAY, you say I want to mail this person or this list of people, for each email address you get an okay or fail. Eventually, you tell the server you are ready to send the body of the message, you do that, end the message with the defined termination. Then either the server says okay or fail or maybe there is some more handshaking.
The protocols in general though have this back and forth. Usually you are sending strings with commands and usually the server side sends back a short okay or error. Sometimes, if they want, they send back more detail on the error, but always start with the few bytes that indicate okay or error. The protocols generally have a flow, you must do this first then this then that.
You should learn sockets programming, sometimes called Berkeley sockets. You can write programs that are mostly portable across unixes but also across to Windows using Windows sockets if that is your platform of choice. You need to learn the protocol first, and it is better on your desktop/laptop and not embedded, you can get it done faster there. You do NOT have to learn to fork or thread to use sockets. The examples may show that as it is easy to show it that way, but you can write complete applications using polling only, it is half duplex send something, wait, send something, wait. For these simple learning programs, a little time up front to learn sockets, from there, it is all learning the protocols.
Now that was the very easy part, the hard part is the TCP/IP stack. I do not recommend attempting that without gaining a lot more experience taking baby steps on your way there. For example, learn to respond to ARP first (yet another RFC protocol, address resolution protocol) then ping (ICMP echo, one subset of the ICMP protocols) then IP basics (sniffing packets) then receive and generate UDP packets. TCP is a whole other level above that, more handshaking. It is not fixed packet size, it is streaming, do not have your code operate on packets, it is a stream of bytes, like working with a serial port.
Doing your own TCP stack is very much a non-trivial thing, I don't recommend it, you need to find someone that has done a TCP/IP stack for this platform for the Ethernet shield and just use it, whatever RTOS or environment they use, use it. Then take your desktop/laptop based experience with the protocol and apply that.
From the discussion above, if you don't want to learn the protocols, etc., I think you need to google around looking at Arduino Ethernet shield examples and see if anyone has done something that sends emails.