Towards Formal Verification of Contiki OS with Frama-C Nikolai Kosmatov
joint work with Allan Blanchard, Simon Duquennoy, Fr´ ed´ eric Loulergue, Fr´ ed´ eric Mangano, Alexandre Peyrard, Shahid Raza, . . .
DigiCosme Software Day, June 7th, 2018
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
1 / 30
Introduction Memory Allocation Module MEMB Cryptography Module AES-CCM Linked List Module LIST Conclusion
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
2 / 30
Introduction
Contiki OS
Contiki: A lightweight OS for IoT It provides a lot of features (for a micro-kernel): I (rudimentary) memory and process management I networking stack and cryptographic functions I ... Typical hardware platform: I 8, 16, or 32-bit MCU (little or big-endian), I low-power radio, some sensors and actuators, ... Any invalid memory access can be dangerous: there is no 55 memory protection unit. SicsthSense
N. Kosmatov
SICS Networked Embedded Systems Group
Towards Formal Verification of Contiki OS
June 7th, 2018
3 / 30
Introduction
Contiki OS
Contiki: Typical Applications I I I I
IoT scenarios: smart cities, building automation, ... Multiple hops to cover large areas • Low-power for battery-powered scenarios Nodes are interoperable and addressable (IP)
Traffic lights Parking spots Public transport Street lights Smart metering …
55 N. Kosmatov
SicsthSense
Light bulbs Thermostat Power sockets CO2 sensors Door locks Smoke detectors SICS Networked Embedded Systems … Group
Towards Formal Verification of Contiki OS
June 7th, 2018
4 / 30
Introduction
Contiki OS
Contiki and Formal Verification
I When started in 2003, no particular attention to security I Later, communication security was added at different layers, via standard protocols such as IPsec or DTLS I Security of the software itself did not receive much attention I Continuous integration system does not include formal verification I and unit tests are under-represented
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
5 / 30
Introduction
Overview of Frama-C
Frama-C at a glance
I I I I I
A Platform for Verification of C Code [Kirchner et al. FAC 2015] Developed at CEA List Released under LGPL license, URL: http://frama-c.com/ Offers ACSL annotation language Extensible plugin oriented platform I Collaboration of analyses over same code I Inter plugin communication through ACSL formulas I Adding specialized plugins is easy
I Used by various academic and idustrial partners
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
6 / 30
Introduction
Overview of Frama-C
Plugin Frama-C/WP for deductive verification
I Based on Weakest Precondition calculus [Dijkstra, 1976] I Goal: Prove that a given program respects its specification I Requires formal specification
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
7 / 30
Memory Allocation Module MEMB
Introduction Memory Allocation Module MEMB Overview of the memb Module Pre-Allocation of a Store in memb Verification of memb with Frama-C/WP Cryptography Module AES-CCM Linked List Module LIST Conclusion
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
8 / 30
Memory Allocation Module MEMB
Overview of the memb Module
Overview of the memb Module I No dynamic allocation in Contiki I to avoid fragmentation of memory in long-lasting systems
I Memory is pre-allocated (in arrays of blocks) and attributed on demand I The management of such blocks is realized by the memb module The memb module API allows the user to I initialize a memb store (i.e. pre-allocate an array of blocks), I allocate or free a block, I check if a pointer refers to a block inside the store I count the number of allocated blocks
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
9 / 30
Memory Allocation Module MEMB
Overview of the memb Module
memb is critical! I Contiki’s main memory allocation module I about 100 lines of critical code I kernel and many modules rely on memb I used for HTTP, CoAP (lightweight HTTP), IPv6 routes, CSMA, the MAC protocol TSCH, packet queues, network neighbors, the file system Coffee or the DBMS Antelope
I memb is one of the most critical elements of Contiki
A flaw in memb could result in attackers reading or writing arbitrary memory regions, crashing the device, or triggering code execution
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
10 / 30
Memory Allocation Module MEMB
Pre-Allocation of a Store in memb
The memb Store I An array of blocks with a given block size and number of blocks I Defined by an instance of struct memb I Created by a macro for a given block type and number of blocks I since there is no polymorphism in C I blocks are manipulated as void* pointers
I Refers to global definitions added by preprocessing 1 2 3 4 5 6 7 8 9 10
/* file memb.h */ struct memb { unsigned short size; // block size unsigned short num; // number of blocks char *count; // block statuses void *mem; // array of blocks }; #define MEMB(name, btype, num)... // macro used to decrare a memb store for // allocation of num blocks of type btype
11 12 13 14 15
1 2 3
/* file demo.c */ #include "memb.h" struct point {int x; int y};
4 5 6 7
// before preprocessing, // there was the following macro: // MEMB(pblock, struct point, 2);
8 9 10 11
void memb_init(struct memb *m); void *memb_alloc(struct memb *m); char memb_free(struct memb *m, void *p); ...
3
12 13 14 15
// after preprocessing, it becomes: static char pblock_count[2]; static struct point pblock_mem[2]; struct struct memb pblock = { sizeof(struct point), 2, pblock_count, pblock_mem }; ...
Fig. 1: (a) Extract of file memb.h defining a template macro MEMB, and (b) its usage to prepare allocation up to 2 blocks of OS type struct point Towards Formal of Verification of Contiki June 7th, 2018
file demo.c) N. (in Kosmatov
11 / 30
Memory Allocation Module MEMB
Verification of memb with Frama-C/WP
Contract of the Allocation Function memb alloc 4 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
/*@ requires valid_memb(m); ensures valid_memb(m); assigns m→count[0 .. (m→num - 1)]; behavior free_found: assumes ∃ Z i; 0 ≤ i < m→num ∧ m→count[i] == 0; ensures ∃ Z i; 0 ≤ i < m→num ∧ \old(m→count[i]) == 0 ∧ m→count[i] == 1 ∧ \result == (char*) m→mem + (i * m→size) ∧ ∀ Z j; (0 ≤ j < i ∨ i < j < m→num) =⇒ m→count[j] == \old(m→count[j]); ensures \valid((char*) \result + (0 .. (m→size - 1))); ensures _memb_numfree(m) == \old(_memb_numfree(m)) - 1; behavior full: assumes ∀ Z i; 0 ≤ i < m→num =⇒ m→count[i] �= 0; ensures ∀ Z i; 0 ≤ i < m→num =⇒ m→count[i] == \old(m→count[i]); ensures \result == NULL; complete behaviors; disjoint behaviors; */ void *memb_alloc(struct memb *m);
Proven in Frama-C/WP Fig. 2: (Simplified) ACSL contract for allocation function memb_alloc (file memb.h) 3.3 Specifying Operations First, we specify the functions of memb in ACSL. Let us describe here the contract contains forN.the allocation function Towards memb_alloc shownofinContiki Fig. OS 2. Its ACSL contract Kosmatov Formal Verification June 7th, 2018
12 / 30
Memory Allocation Module MEMB
Verification of memb with Frama-C/WP
Specification in ACSL We specify the contract of each function and prove it in Frama-C For instance, the contract of memb_alloc has two behaviors 1. If the store is full, then leave it intact and return NULL (lines 12-15) 2. If the store has a free block, then return a free block b such that: I b is properly aligned in the block array (line 8) I b was marked as free, and is now marked as allocated (line 7) I b is valid, i.e. points to a valid memory space of a block size that can be safely read or written to (line 10) I the states of the other blocks have not changed (line 9) I the number of free blocks is decremented (line 11)
These behaviors are disjoint and complete.
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
13 / 30
Memory Allocation Module MEMB
Verification of memb with Frama-C/WP
Summary I The memb module specified and formally verified with Frama-C/WP I 115 lines of annotations I 32 additional assertions I 126 verification conditions (i.e. proven properties)
I A few client functions proven as expected I Proof fails for out-of-bounds access attempts
I A potentially harmful situation detected I count--; used instead of count=0; Reference: F.Mangano, S.Duquennoy and N.Kosmatov. A Memory Allocation Module of Contiki Formally Verified with Frama-C. A Case Study. In CRiSIS 2016, LNCS, vol.10158, 114–120. Springer.
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
14 / 30
Cryptography Module AES-CCM
Introduction Memory Allocation Module MEMB Cryptography Module AES-CCM Overview of the aes-ccm Modules Verification of aes-ccm with Frama-C/WP Linked List Module LIST Conclusion
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
15 / 30
Cryptography Module AES-CCM
Overview of the aes-ccm Modules
Overview of the aes-ccm Modules I Critical! – Used for communication security I end-to-end confidentiality and integrity (e.g. Link-layer security or DTLS)
I Advanced Encryption Standard (AES) is a symmetric encryption algorithm I AES replaced in 2002 Data Encryption Standard (DES), which became obsolete in 2005
I Modular API – independent from the OS I Two modules: I AES-128 I AES-CCM* block cypher mode I A few hundreds of LoC
I High complexity crypto code I Intensive integer arithmetics I Intricate indexing I based on multiplication over finite field GF(28 ) N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
16 / 30
Cryptography Module AES-CCM
Verification of aes-ccm with Frama-C/WP
Example: Function set key /*@ requires \valid_read(key+ (0 .. (AES_128_KEY_LENGTH - 1))); assigns round_keys[0][0 .. (AES_128_KEY_LENGTH - 1)], round_keys[1][0 .. (AES_128_KEY_LENGTH - 1)], round_keys[2][0 .. (AES_128_KEY_LENGTH - 1)], round_keys[3][0 .. (AES_128_KEY_LENGTH - 1)], round_keys[4][0 .. (AES_128_KEY_LENGTH - 1)], round_keys[5][0 .. (AES_128_KEY_LENGTH - 1)], round_keys[6][0 .. (AES_128_KEY_LENGTH - 1)], round_keys[7][0 .. (AES_128_KEY_LENGTH - 1)], round_keys[8][0 .. (AES_128_KEY_LENGTH - 1)], round_keys[9][0 .. (AES_128_KEY_LENGTH - 1)], round_keys[10][0 .. (AES_128_KEY_LENGTH - 1)]; */
static void set_key(const uint8_t *key) /*@ loop invariant 0 0 ==> k >= 0 ==> AddrC == cArr[i + n - 1]->next ==> linked_n(root, cArr, i, n + k, bound) (linked_n(root, cArr, i, n, AddrC) && linked_n(AddrC, cArr, i + n, k, bound)); */
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
26 / 30
Linked List Module LIST
Formalization approach
Example of required lemma: split a list into two segments /*@ lemma linked_split_segment: \forall struct list *root, **cArr, *bound, *AddrC, integer i, n, k; n > 0 ==> k >= 0 ==> AddrC == cArr[i + n - 1]->next ==> linked_n(root, cArr, i, n + k, bound) (linked_n(root, cArr, i, n, AddrC) && linked_n(AddrC, cArr, i + n, k, bound)); */
Ghost code
i cArr
&A
&B
&C
&D
&E
root
A
B
C
D
E
&A
&B
&C
&D
&E
bound
Actual code N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
26 / 30
Linked List Module LIST
Results
Verification Results I Code written and specification I I I I
46 lines for ghost functions 500 lines for contracts 240 lines for logic definitions and lemmas 650 lines of other annotations
I It generates 798 proof obligations I I I I
772 are automatically discharged by SMT solvers 24 are lemmas proved with Coq 2 assertions proved with Coq 2 assertions proved using TIP
I Discharging all PO requires about an hour of computation. Reference: A.Blanchard, N.Kosmatov and F.Loulergue. Ghosts for Lists: A Critical Module of Contiki Verified in Frama-C. In NFM 2018, LNCS. Springer (to appear). N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
27 / 30
Linked List Module LIST
Results
Bug found in list insert
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
28 / 30
Linked List Module LIST
Results
Bug found in list insert
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
28 / 30
Conclusion
Introduction Memory Allocation Module MEMB Cryptography Module AES-CCM Linked List Module LIST Conclusion
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
29 / 30
Conclusion
Conclusion Frama-C successfully used to formally verify several critical modules I functional verification of memory allocation (MEMB) I absence of security flaws in cryptography (AES-CCM and CCM*) I functional verification of a key kernel module (LIST) I other studies in progress Absence of security related errors verified in all cases End-to-end confidentiality and integrity (via AES-CCM) Basic module for memory separation of various tasks Several errors or incoherencies detected
N. Kosmatov
Towards Formal Verification of Contiki OS
June 7th, 2018
30 / 30