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.
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.
At the flowcharting stage of my program. I would like to save energy by sending a couple of attributes in my advertising broadcast message but am worried that a radio closer to my central could spoof my message and supply bogus data using my advertisers address. Can I pair then bond and then use encryption keys to encrypt my two attributes in the broadcast message? Please refer me to a more appropriate forum if this question does not belong here.
The normal Bluetooth Core standard does not define any way of securing advertising data. The encryption keys exchanged at pairing can only be used for securing an established connection.
You have to invent your own layer or use for example Bluetooth Mesh.
I have a project using MDB (multi-drop bus) for vending machine (VDM).
The VDM has a MDB-RS232.
I'm not sure if it converts 9bit - 8bit (MDB-UART).
How do I read data from VDM in my computer?
Thanks all
MDB (multi-drop bus) is 9 bit, because after the standard 8 data bits (like in standard RS232 UART communication) there is a 9th bit called "mode".
(Wikipedia on MDB: "the mode bit differentiates between ADDRESS and DATA bytes.")
But you can read such data even with regular 8-bit RS232 interfaces, e.g. a plain standard USB-to-RS232 device for PC.
Here is how:
Use 9600 baud, 8 data bits, 1 stop bit, but RS232 parity setting "Space". Make sure you receive the original character value even in case of a Parity Error indication. Any MDB address byte from your VDM will be received with a Parity Error (but still be displayed correctly). Any data byte will be displayed without error.
For sending MDB ADDRESS and DATA bytes using a standard 8-bit RS232 port, you could apply temporary parity changes: Change the parity setting to "Mark" before sending an address byte, then change back to "Space" before sending data bytes.
On Windows, you can do such tricks with our Docklight software (see Docklight and MDB). It's free for basic testing and there is also a related 9-bit example project.
On Linux / Raspberry Pi other users have successfully implemented the parity trick, too, see this stackexchange post about a MDB + Pi.
But also with RealTerm, Teraterm, Termite, Bray, YAT or any other RS232 application you should be able to read the data, as long as it handles "Space" or "Mark" parity settings correctly.
You'll need an adapter which will do all convert operations on-the-fly and in real time. If you want to emulate VMC (master), you'll need MDB-UART master adapter. If you want to emulate MDB peripheral device (such as coin changer, bill validator etc), you'll need this. For two-way "sniffing" MDB bus you'll need a combination of these devices.
Direct connection PC's RS-232 to MDB will not work due to strict MDB timings (delay between VMC command and peripheral response must not exceed 5ms, delays between POLL requests are 50-300ms in general). I mean pretty reliable functioning available for commercial purposes.
I'm working with ANT+ protocol, to connect a smartphone with an ANT+ USB dongle, which is connected to PC where with SimulANT+. SimulANT+ is simulating a heart-rate sensor, which sends data to my phone.
Until now I have been using a non-encrypted channel to communicate, but there is also an option to make a secure connection between devices as is written in ANT Message Protocol and Usage document. It's called Single Channel Encryption. Do someone have some code examples on how to establish this type of connection?
It is true that ANT protocol can use a single encrypted channel - however this is not the case for ANT+. (See the differences between ANT/ANT+ here: http://www.thisisant.com/developer/ant-plus/ant-antplus-defined)
If you use encryption for your device it is no longer ANT+ compliant and therefore you are not allowed to use the ANT+ Network Key or frequency.
This is because ANT+ aims to ensure interoperability between different manufacturers sensors/displays. If the channels were allowed to be encrypted, this would defeat the purpose ANT+.
Therefore if your goal is to use your device with SimulANT+ (or any existing ANT+ sensor) it will not work. In fact, SimulANT+ does not even allow the utilization of encrypted channels.
I am designing software around an existing hardware product. I have full control of the communication protocol but I'm not sure how to facilitate device detection.
A device could have a range of possible configurations (i.e. baud rate, data bits, parity bits, stop bits) that must be detected at runtime. What is the easiest, most reliable way for the software to figure out what configuration it is using? Again, I have full control of the communication protocol so I can define any mechanism I wish.
Is this a full-duplex or half-duplex device? Can you control request-to-send and monitor clear-to-send on both ends of the serial line? Is the serial line point-to-point (like RS-232) or multi-drop (like RS-485)? It will make a (albeit small) difference if you are going to interfere with other already connected devices while negotiating with a newly connected one.
If you think of the handshake process like a modem negotiating a link layer protocol, it uses a standard set of messages to describe the type of communications it would like to have and waits for an "ack" from the other end. In your case I recommend having a "let's talk" standard message that your head end generates with the range of bit rates and waits for the ack from the device.
I also recommend reducing the number of configuration options for the device. Forget about variable data bits, parity bits, and stop bits. The serial communications world is no longer as unstable as it was back in the 70's. Just use 8 data bits, no parity, one stop bit and vary the bit rate. A CRC on the end of messages provides plenty of error-checking.