IoT Security

Engineering Internet Of Things Secure network  for our upcoming IoT service.


  • Security
  • Redundancy
  • End to End Security
  • Secure Firmware Upgrades


  • DoS Attacks
  • DDoS Attacks
  • DNS spoofing /don’t even think of DynDNS/
  • Sniffing
  • man in the middle


  • Using a VPN -> takes the problem away and requires extra settup. Not user friendly. The only pro is that it can use an existing infrastructure if present. A Big NO
  • SSL -> expired certificates , heavy overhead, often exploited. Closed source library, may already be hacked. NO
  • AES all the Way. A big YES
  • DoS/DDoS prevention – redundant MQTT brokers, with dns/firmware fallback

So Why AES?

  • Can provide end to end encryption
  • Is openly developed standard – no hidden treasures
  • Suitable for encrypting messages – MQTT messages
  • Fast on modern processors and fast enough on the esp8266
  • AES can run on smaller chips too.
  • One big con is that the mqtt user name and password can be sniffed and used to connect to the cloud. But that’s easy solvable, if they don’t speak right, disconnect them and force password change.

Secure Firmware upgrades

Only local and only user initiated, user must see and check the result of the upgrade – Any other option introduces big risk for the system and the user.

Data – What to protect and what not?

It’s well know that all encryption is value versus time. So do you really want to hide what was the temperature at your house 5 minutes ago? – May be, if you are paranoid, but you definitely want to lock the access to your internet enabled door locks.

So all the actuators must be crypto protected – they do things. While sensors can be divided into two types – sensitive and non-sensitive. For example – house alarm state is sensitive, just like house human presence . But the outdoor temperature is not sensitive, you can get it N+1 ways.



ESP8266 using different flash sizes – FOTA and Download tool

Which goes where – when using a bootloader for FOTA.

The files:

  • master_device_key.bin –  Obtained from Espressif Cloud
  • esp_init_data_default.bin – Stores default RF parameter values
  • boot.bin – bootloader
  • user1.bin and user2.bin – user firmware
  • blank.bin – blank settings , flash to get default parameters

1. 512KB

  • master_device_key.bin 0x3E000
  • esp_init_data_default.bin 0x7C000
  • blank.bin 0x7E000
  • boot.bin 0x00000
  • user1.bin 0x01000
  • user2.bin 0x41000

2. 1024KB Flash

  • master_device_key.bin 0x3E000
  • esp_init_data_default.bin 0xFC000
  • blank.bin 0xFE000
  • boot.bin 0x00000
  • user1.bin 0x01000
  • user2.bin 0x81000

3. 2048KB Flash

  • master_device_key.bin 0x3E000
  • esp_init_data_default.bin 0x1FC000
  • blank.bin 0x1FE000
  • boot.bin 0x00000
  • user1.bin 0x01000
  • user2.bin 0x81000

4. 4096KB Flash

  • master_device_key.bin 0x3E000
  • esp_init_data_default.bin 0x3FC000
  • blank.bin 0x3FE000
  • boot.bin 0x00000
  • user1.bin 0x01000
  • user2.bin 0x81000


How to use 1MB and above flash on espressif forum describes the use of download tool.

Here is what download tool does:


  • Crystal Frequncy choices:  40Mhz, 26Mhz,  24Mhz – For a 40M crystal , the booting uart tx baud is 115200,(74880 for 26m accordinglyCrystal Freq will be set to the BYTE[48] of esp_init_data_default.bin
  • SPI Flash speed: 0 = 40MHz , 1 = 26.7MHz,  2 = 20MHz,  f = 80MHz  stored in BYTE[3]&0f of the images
  • SPI flash read mode: 0 = QIO, 1 = QOUT, 2=DIO, 3=DOUT  set to the 3rd BYTE at flash address 0x0 so it is BYTE[2].
  • Flash size: Flash size is SET to the higher 4bit of 4TH BYTE at flash address 0x0 which is BYTE[3]>>4)&0xf in the image:
    0:512KB(256KB+256KB)  – 4Mbit
    1:256KB – 2Mbit
    2:1MB(512KB+512KB) – 8Mbit
    3:2MB(512KB+512KB) – 16Mbit
    4:4MB(512KB+512KB) – 32Mbit
    5:2MB-C1(1024KB+1024KB) – 16Mbit
    6:4MB-C1(1024KB+1024KB) – 32Mbit

tout as vdd33 – esp_init_data_default.bin BYTE[107]  = 0xff

tout as adc – esp_init_data_default.bin BYTE[107]  = VDD*10 /vdd > 1.8 and vdd < 3.6/

Low power options are left out for now.

To be continued …

Olimex ESP8266 module – MOD-WIFI-ESP8266-DEV

I need a bigger flash and a breadboard friendly board. Quick research lead to the following variants, beside soldering a bigger flash on the ESP-XX series modules.

  1. NodeMCU board’s that have bigger flash and fit on a breadboard but have regulators and usb 2 serial on them.
  2. ESP-XX module with adapter,  don’t like .

And the winner is Olimex’s – MOD-WIFI-ESP8266-DEV .

i got some of them:


Cardboard boxes and the modules within packed in real anti static bags.



I’ve soldered the headers, with chip on top – looked natural. But the GPIO  silkscreen markings got hidden at the bottom of the module – i think it’s better for development to have them on top, shorted out text is OK.

oli3 oli4

There are  two rows left on both sides of the the breadboard.


So, let’s see what the extra flash is good for.

SSL – Is SSL the right solution for #IoT?

FOTA  – What about the FOTA upgrades security?

Going down the rabbit hole it seems that the MOST important and hard part of a IoT implementation is to get the security right. So the extra flash will present an opportunity to test to some ideas on how to do it. And we need it for the service we are building – it’s just vital to have and to have it right.