I sniffed a XBEE S1 packet and it's normally a full 802.15.4 packet.
The AES encryption is enable on my module xbee s1 and I know the key.
What is the algorithm to decrypt the data payload ?
Normally, in a 802.15.4 packet, there is the flag "Security level" that say what AES is used (AES-CCM, AES-CTR or AES-CBC). Here the flag is at 0 (None).
I think that is AES-CTR, Wireshark can decrypt AES-CCM and it doesn't work.
I looked in the 802.15.4 specification how to decrypt the AES-CTR and I think that I don't understand how the nonce is build because my decryption doesn't work. Can someone explain to me how to decrypt a XBEE S1 packet ?
Thanks !
I found why I couldn't decrypt the packet.
XBEE S1 modules use AES-CTR but they don't really respect the 802.15.4 specifications during encryption.
The field of security reserved, the key id mode and the sec level are not in the packet however they should be... That shifts the reading of one byte.
And, normally, during encryption, the frame counter and the data payload must be used in big endian. With Xbee S1 modules, they are used in little endian.
Related
I'm writing a firmware for an embedded system (microcontroller). The firmware can be updated by a bootloader (also written by me).
Now there is a requirement to take measures to prevent manipulation of the firmware, so the system must only execute a downloaded firmware if it has some sort of a valid signature.
The firmware file comes encrypted. It is decrypted by the bootloader (in the microcontroller) and then programmed into the flash memory.
Since the firmware comes encrypted, in my opinion a simple CRC check on the flash content should be sufficient to prove the firmware validity. But I'm no expert for cyber security, so... do I need more?
I presume that the encryption is strong enough and that the flash memory cannot be read out.
Since the firmware comes encrypted, in my opinion a simple CRC check
on the flash content should be sufficient to prove the firmware
validity. But I'm no expert for cyber security, so... do I need more?
If you chose a sound cryptography method, and guard your encryption keys properly, and you also guarantee that the firmware cannot be read-out after it has been transferred, and the bootloader rejects the firmware if it cannot successfully decrypt it, then you already guarantee firmware validity. Unless one of the above assumptions is violated, only the person who owns the keys to encrypt the firmware can ever produce a firmware that will be accepted by the bootloader.
As others have pointed out, CRC is not used to protect against intentional modification as you could just append trash-data to any file to produce the desired CRC. However I'd still recommend to have a CRC on at least two stages of your firmware-upgrade process:
CRC the encrypted data during transmission, preferably on each transmitted packet so you can re-transmit single packets without restarting the whole process (i.e. CRC over 256-byte chunks of the encrypted data)
Second over the flash area occupied by the firmware (minus bootloader) against a CRC of the decrypted firmware that is generated by the bootloader after successful decryption (or a static, fixed CRC, some µC-IDEs support this built-in), to make sure no flash-write-errors occured. It's common practice to safe this CRC-value to some flash area that is not part of the CRC, so that the bootloader can verify the application's integrity on every device reset.
During the encryption procedure of a BLE connection, the master and the slave perform a 3-way handshake to validate the encryption. I am facing a case where the slave does not send the last part of this handshake, i.e. the message LL_START_ENC_RSP which is in red in the following schematic of this handshake :
Is there a specified reason for this to happen ? By specified I mean a reason that is not implementation specific.
The BLE Core Spec 4.2 tells this :
When the Link Layer of the slave receives an LL_START_ENC_RSP PDU it
shall transmit an LL_START_ENC_RSP PDU. This packet shall be sent
encrypted.
But this does not specify any condition for the slave not to send this packet.
Would it be possible at this point that the slave thinks it has the Long Term Key associated with the current Master (because if it wasn't the case the slave wouldn't have started the 3-way handshake, right ?), but its LTK is incorrect and the decryption fails ? If it happened, wouldn't there be a disconnection message, instead of nothing ?
As I am pretty new to BLE I have no idea how to analyze or interpret this issue, so any help would be greatly appreciated. The presence and the absence of the messages has been observed with the help of a BLE sniffer.
Note : Image 1 is a reproduction of Figure 7-26 of the book : Bluetooth Low Energy The Developer's handbook by Robin Heydon.
According to the spec, the third message shall always be sent. If it is not sent, there is a bug in the implementation.
If the slave has the wrong LTK, the slave will not accept the LL_START_ENC_RSP from the master. If this happens, the link will be dropped after the supervision timeout since the slave will never acknowledge that packet.
Note that in order for a sniffer to successfully decrypt a packet, it needs to know the LTK. Nordic's sniffer program will catch the LTK if the sniffer runs during the pairing process.
I want to encrypt the messages that are exchanged between sensor nodes.
Can I do it without having access to real hardware sensor nodes, such as Tmote Sky?
Can software encryption/block ciphers only be simulated on Tmote Sky nodes? If I need to use hardware encryption algorithms, then should I have a real sensor node?
Also, I read that for symmetric encryption one must have real sensor nodes, but asymmetric encryption can work with emulated nodes as well?
Any documentation or description would be helpful.
Contiki has LLSEC (link-layer security) layer. This layer is hardware independent, as it uses generic AES driver API instead of directly accessing the hardware. There are multiple AES drivers implemented in Contiki - a software-only version and a couple of hardware accelerated ones, including for CC2420 (the radio chip on Tmote Sky).
The problem with Cooja is that the HW acceleration feature of CC2420 is not implemented in the mspsim emulator. So HW acceleration is not going to work in Cooja as opposed to real Tmote Sky nodes; you must explicitly select the software-based AES driver in configuration:
#define AES_128_CONF aes_128_driver
The bottom line is that AES encryption will work in Cooja, but will be slow.
Now the example configuration of LLSEC - there is little LLSEC documentation around, but the basic setup is described in this README file:
Add these lines to your project_conf.h to enable noncoresec:
#undef LLSEC802154_CONF_ENABLED
#define LLSEC802154_CONF_ENABLED 1
#undef NETSTACK_CONF_FRAMER
#define NETSTACK_CONF_FRAMER noncoresec_framer
#undef NETSTACK_CONF_LLSEC
#define NETSTACK_CONF_LLSEC noncoresec_driver
#undef NONCORESEC_CONF_SEC_LVL
#define NONCORESEC_CONF_SEC_LVL 1
NONCORESEC_CONF_SEC_LVL defines the length of MICs and whether
encryption is enabled or not.
The important paramter here is NONCORESEC_CONF_SEC_LVL, which corresponds to the IEEE 802.15.4 framer security levels, with numerical values from 0x0 to 0x07.
To enable encryption, set it to 0x4:
#define NONCORESEC_CONF_SEC_LVL 0x4
The other values are:
0x00 No security Data is not encrypted. Data authenticity is not validated.
0x01 AES-CBC-MAC-32 MIC-32 Data is not encrypted. Data authenticity is validated.
0x02 AES-CBC-MAC-64 MIC-64 Data is not encrypted. Data authenticity is validated.
0x03 AES-CBC-MAC-128 MIC-128 Data is not encrypted. Data authenticity is validated.
0x04 AES-CTR ENC Data is encrypted. Data authenticity is not validated.
0x05 AES-CCM-32 AES-CCM-32 Data is encrypted. Data authenticity is validated.
0x06 AES-CCM-64 AES-CCM-64 Data is encrypted. Data authenticity is validated.
0x07 AES-CCM-128 AES-CCM-128 Data is encrypted. Data authenticity is validated.
To enable both encryption and authentication, set the level to 0x5, 0x6 or 0x7.
Another useful configuration parameter is NONCORESEC_CONF_KEY, the network-wide shared key.
As for the other questions, there is no support for hardware-accelerated asymmetric encryption on sensor nodes. Also, there are no software based implementations for that in mainline Contiki; there is no support (yet) for end-to-end security in general in this OS, as opposed to link-layer security. There are some projects that have developed DTLS and IPSEC for Contiki, but describing that goes beyond this answer.
The llsec is the security stack. For example the anti-replay llsec_driver avoid replay attack.
About pure encryption (so no logic security), software encryption are available for all platform (not only skymote) with hardware boost (for some platform) (contiki-os blog check at encryption paragraph).
Cooja is an emulator, not a simulator (Cooja in depth). So it simulates everything from the hardware. Therefore, you don't need a real mote to make test.
Symmetric and asymmetric encryption have differences on a logical point of view. But on hardware it's same : you'll send bits that represent a key. I don't see why it would be different for emulation.
For hardware encryption, if the mote support it, yes you can. If not you can't. (emulated or not).
Hope it helped.
I have a processing sketch that pumps out basic serial commands to an xbee.
Then I have two (soon to be 3, maybe 4) arduino's with their own xbee's who receive the data and do stuff.
Thing is each Arduino has it's own purpose, and therefore it's own data packet.
So, to implement this. Is there a way to send a message to a particular xbee? I.e. can I assign the xbee an index or channel of some sort, then get the broadcasting xbee to send data to whatever index or channel it needs to?
Or, will this need to be implemented in the Arduino software?
i.e. Processing prefix the data packet with an index/identifier and the arduino ignore incoming messages with that prefix?
Or is there another option entirely :P
Thanks in advance for your advice.
While not a specific answer to your question, with this type of communication some packet error checking would be beneficial. Send the data using a crc error checking algorithm. Packet structure could look something like:
0x7F 0x02 (Address Bytes) (Command Bytes) (CRC bytes) 0x7F 0x03
Where 0x7F is the DLE character used to indicate either a start byte will follow, and end byte will follow, or a data byte with the value of DLE will follow. This means any DLE character that is part of the address or command should be preceded by a 'Stuffed' DLE character. The CRC is calculated from the address and command bytes and used to check the integrity of the data that is received. The CRC check bytes are included in each packet.
This type of communication will prevent packets going to the wrong source from being used, and also packets that are in error from being used.
To read more on serial framing here is a good place to start: http://eli.thegreenplace.net/2009/08/12/framing-in-serial-communications/.
To what i understood is that you want to be able to tell the diffrence to what Xbee you are sending data to. You can do this by using IP adresses. If you have for example two Xbees with the IPs:
Xbee1 - 192.168.80.50
Xbee2 - 192.168.80.51
Xbee3 - 192.168.80.52
You can send information between them by just connecting the Xbee that will start the communication to the Xbee that will receive it. If you want to have any kind of communication over the wireless network (or ethernet) you must have an IP assigned to every Xbee.
EDIT:
If you have a server on a computer that you have made yourself in for example Java. You can connect the Xbees to that and connect of them to the computer server. Then you can set up the server to receive and send data to the diffrent Xbee clients.
I did something similar to this: Maintaining communication between Arduino and Java program , but i didn't use a Xbee, i used the official WiFi shield.
Hope this helped!
-Kad
I am doing some experiment for which I need to collect Data from wlan driver.
I am interested in transmitting IEEE 802.11b Packets with more flexibility in terms of Data Rate, Packet Size etc.
Basically, I will have the laptop as the transmitter and I have built a custom receiver for IEEE 802.11b which would read the packets ( IEEE 802.11b 1/2/5.5 or 11Mbps) .
So, I am looking at some Linux tool which gives the option of setting these parameters while transmitting data.
I am thinking at commands like iwpriv to set the parameters for the wireless driver, and iperf commands to generate Traffic.
I am not sure, how to use them to achieve a Data traffic, say 1Mbps / and 1024 Bytes PSDU (Packet Size).
The receiver is a dedicated hardware ( not a Computer). Any suggestion or idea in this direction would be helpful.
Thanks
Use wireshark or pcap (via perl,python etc) to capture what you want.
You may be better off asking this on Server Fault. I found a couple of packet generators that look like they could do what you need but I'm by no means an expert.
packETH:
you can create and send any ethernet packet [...]
sending sequence of packets
delay between packets, number of packets to send
sending with max speed, approaching the teoretical boundary
change parameters while sending (change IP & mac address, UDP payload, 2 user defined bytes, etc.)
Ostantino:
Modify any field of any protocol (some protocols allow changing packet fields with every packet at run time e.g. changing IP/MAC addresses)
[...]
Configure stream rates, bursts, no. of packets
I found these in the Wireshare Wiki where there are a number of other tools that may help.