These are random notes I had about the topic of security in embedded systems

  • Why is it important
    • embedded devices are in places which are likely to be hidden from sight and work without as much intervention/interaction as other tech (desktop applications, websites)
    • we also have cars which are connected to the internet now(have remote firmware updates), also fridges, and TVs with mics and cameras
    • supposedly secure tech/service/device might be compromised due to underlying insecurity in an embedded device in the path
    • internet of things is the nightmare of pervasive embedded insecurity made real - Taylor swift
    • how important it should be to you would depend on how much is at stake (privacy, security of other systems dependant on this)
  • why is it hard
    • security is hard in general, for embedded systems it is even more harder
    • recent side channel attacks are really scary, and they seen to work to
      • that hardware on hackaday to fuzz click and datainput
    • cryptography is not the solution to all problems, software bugs(and maybe other stuff too) makes devices insecure
  • Cases in the wild
    • routers are regularly found to have big security issues, this can be really bass since routers are part of your infrastructure which other things use. See SOHOpelesdly broken
    • recently tp-link locked their firmware because of fcc change in rules regarding firmware which can be modified by customers
    • http://www.theregister.co.uk/2015/03/05/broadband_routers_sohopeless_and_vendors_dont_care/
    • SCADA systems
    • http://www.devttys0.com/blog/ http://routersecurity.org/
    • http://www.bbc.com/news/technology-28208905 lightbulb leaks wifi passwords
    • Chinese camera with built in p2p features communicates with dozens of ips despite the option to disable p2p on, on by default, vulnerable.
  • Common pitfalls
    • no encyption, or some obfuscation in name of encyption
    • using deprecated crypto, ex. WEP for WiFi, TLS versions which are no longer supported because of not being strong enough
    • common pitfalls of not sanitizing input
    • RNG issues, using sources with low entropy, predictable entropy, or sources which can be tricked (?)
      • esp8266 early firmware use constant seed for rng
    • insufficient key lengths in encryption
    • insecure hash functions,md5 no longer considered secure
    • firmware update issues
    • leaving private keys inside devices same across all devices (depends on how secure system needs to be)
  • Absolute basics of security
    • do not use homebrew crypto, it means don’t create own ways of authentication, or implement your own encryption cipher
    • use standard/public/peer reviewed cryptography, not proprietary/new/your own
    • do not use otherwise secure crypto libraries or functions in a non standard, non recommended way.
    • “A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.”
    • obscurity does not add to security
    • http://www.edn.com/design/systems-design/4410267/1/The-Right-and-Wrong-Way-to-Implement-Cryptographic-Algorithms-in-Embedded-Electronic-Systems
  • Suggestions for the most common use cases
    • good coding practices to reduce the 3 most common errors resulting in bugs:buffer overflows, unchecked input, poor handling of integer type checks
      • always sanitize input
      • follow a coding standard maybe? MISRA-C
      • decouple, modules, reduce the amount of state the program has, minimize ‘globals’
      • famous apple bug, “goto fail; goto fail;”
      • properly use interrupts, should be short, modify minimal stuff
      • use fixed width integral types, uint8_t, uint32_t, int16_t etc. because int char long are allowed to be implementation defined by ISO C
    • rng
      • use hardware rng if available
      • of not use enough entropy. Example adc noise, use only LSB, xor with differences in click, LEB again, multiple readings, pass through some one way hash function recommended, etc.
    • https://en.wikipedia.org/wiki/Defensive_programming
    • OWASP is a really good resource for web application security guidelines, but security in writing software in general too. It had it’s problems though, it is not at all newbie friendly, the content is not very regulated, so good advice might be mixed in with bad advice.
      • they have an embedded security project that is really low in activity, maybe a new resource for general advice can be started
Posted on 01 May 2016

avr project workflow

When I start working on a microcontroller project, there are some basic things that are nice to haves. Basic things like a serial port for debug messages, a continuously running timer for getting time difference between two points of time(for things like timeout; or delays). Then most of the time, you need SPI, or I2C, or some other peripheral.

Unless you have been using the same platform for some time and have your own personal stash of code snippets to do this, (and unless you wrote then well enough to be reusable with other projects, might still need some work to make it work too) you’ll be doing the same things again and it takes time before you get to do the thing you wanted to do.

Although C++ is not my prferred language for writing code for microcontrollers, I write much of AVR code in C++(except ‘modules’ deliberately written in .c/.h files to make them reusable in other c projects), just to be able to use arduino libraries. This post is to explain the arduino code/libraries build process in some detail and adapting it to one’s favourite tools.

Having used a simple makefile based compilation system which replicated the arduino compilation steps(which I made a long time ago for an internship), I was looking for something a bit more robust and configurable. Found Inotool randmonly and this was exactly what I wanted. Usage is simple, create a file ino.ino to specify configuration(board, serial port, baud etc.).

A sample config file could be like:

board-model = yourcustomboard

board-model = yourcustomboard
serial-port = usb

(The setting serial-port = usb in the above is not standard)

Usage is simple, write your code in src/, add any libraries(arduino compatible format so that the build system can find it), write config in ino.ini, and:

ino build
ino upload
(also) ino clean

The overall stucture is then like:

    |     |--sketch.ino     (arduino style c++/wiring code)
    |     |--file1.cpp
    |     |--file1.h
    |     |--file2.c
    |     |--file2.h
          |--ArduinoLib/    (arduino style library)

Ino seems to be unmaintained now, but it works fine with arduino1.0.6(1.5.x and later ones should work too, but I haven’t tried), which ships with avr-gcc 4.3.2. It was only missing a way to program devices via a programmer instead of using the serial bootloader. I sent a pull request which enables use of usb programmers from the config, you can checkout my version from https://github.com/ntavish/ino/ branch patch-1(unmerged), make sure to checkout this branch.

In the config example above, there is the name yourcustomboard, which could have been one of the board names listed inside the file /usr/local/share/arduino/hardware/arduino/boards.txt, for example:


To make our own custom board available in this list, first create a ‘profile’ for your own board in any location. The structure for the files in this is:


(Note: you might need to copy the directory cores/ from /usr/local/share/arduino/hardware/arduino/cores/ as yourcustomboard/cores/)

The file pins_arduino.h is pretty self-explanatory, it is the utility header defined for all supported boards by arduino IDE so that you can write have straight numbers in digitalRead/Write etc. instead of actual MCU pin port/numbers, A0/A1/A2/.., SS/MOSI/MISO, SDA/SCL, and utility macros like digitalPinToPCICR/digitalPinToPCICRbit/.. etc. Customising this you can map pins to your preference/circuit.

A sample custom boards.txt file for a custom board, set for programming with a usb programmer is:


yourcustomboard.name=Your custom board (ATmega1280) 14.745MHz




In this config all of the bootloader settings can be ignored(the fuse settings are only for documentation too). The setting protocol is the name of the usb programmer(as listed by avrdude) you plan to use for this board. The setting maximum_size might be incorrect in this example, since it subtracts bootloader flash size. The other important settings are mcu and f_cpu.

To create your own board’s boards.txt, just use the nearest board from yours in /usr/local/share/arduino/hardware/arduino/boards.txt as a template and modify.

I use my favourite editor and jsut use ino build/ino upload and the workflow is greatly simplified. Hope you too find it useful!

Posted on 15 Jan 2016