D 1 . 1 Security requirements for connected medium security-critical applications

interpretation can be used with a high degree of automation to check for RTEs. However, it usually reports false positives, i.e. warnings about undesired program behaviours that are members of the computed approximation set of possible program behaviour, but not of the (incomputable) precise set. It would be desirable, after a manual post-analysis check for true/false positives, to provide appropriate hints to the tool that help to avoid known false positives for future runs. This kind of hints is exactly what we introduced above as minimal contracts. Minimal-contract annotations are reusable with some reasonable probability. That is, they are likely to guide Frama-C to a 100% verification rate even after minor changes in the implementation code. Verifying minimal contracts can be a synthesis of both approaches that combines each's advantages, viz. local specifications and global analysis. A minimal contract specifies just sufficient properties of a function to verify the absence of undefined behaviours. For example, the minimal contract of the function int abs(int) that computes the absolute value might just state that the result is non-negative and that no side effects occur. Contrary to a written report about manual post-analysis of abstract interpretation alarms, minimal contract annotations are reusable with high probability for follow-up analyses of the software. On the other hand, specifying and verifying of minimal contracts requires far less effort than more elaborate contracts for the business logic. Using minimal contracts helps assigning the available efforts for quality assurance in a more efficient way by concentrating on run-time error detection for a large part of the software, rather than devoting it to the verification of complex properties for a small part only. In practical projects, this selectivity gains the more importance as the main emphasis is on particular aspects of software quality, such as security issues. Within the collaborative effort of VESSEDIA task 1.1, FOKUS has annotated a critical part of a INRIA’s Contiki use-case with minimal contracts (i.e. RTE requirements only) and started to evaluate the practical feasibility of this approach. This work is described in the following. We demonstrate the methodology we developed during this case-study to enable tool-support in writing minimal contracts. We discuss the issue of a basic library function needing additional requirements on its result range in order to verify a minimal contract of its caller. As a first step towards increased software robustness, we strongly recommend to include minimal contract information into the informal documentation (e.g. Doxygen) of each function. In the Contiki software, we actually found a run-time error during computation of a value that was, however, never used. We briefly discuss the pros and cons of ostracizing such kind of code. 6.2 Description of the software for annotation In order to evaluate our minimal-contracts approach in a more realistic context, we performed a medium-scale annotation experiment within Task 1.1 of the VESSEDIA project. As target we chose a subset of the Contiki operating system, which is the use-case provided by INRIA and handled in VESSEDIA task 5.1. Contiki is an Operating System for the Internet of Things. It was among the pioneers in advocating IP in the low-power wireless world. In particular, it features a 6LoWPAN stack, that is, a compressed IPv6 stack for IEEE 802.15. 4 communication. This enables constrained devices to inter-operate and 39 Since most abstract interpretation tools, as well as most deductive verification tools, are available for C, we restrict to this language. Comparable, but less versatile, tool support is available for Ada and Java. An extension of Frama-C to C++ is currently under development. D1.1 Security requirements for connected medium security-critical applications VESSEDIA D1.1 Page 49 of 58 connect directly to the Internet. Sensors, actuators or consumer devices can be brought together and create applications in various areas such as home automation or the smart grid. Contiki is targeted at constrained devices with an 8, 16 or 32-bit MCU and no MMU. The devices usually feature a low-power radio module, some sensors, a few kB RAM and tens of kB ROM. Contiki has a kernel, written in portable C, which is linked to platform-specific drivers at compile-time. It supports more than 35 different hardware platforms. When Contiki started in 2003, the focus was on enabling communication in the most constrained devices, with no particular attention given to security. As it matured and as commercial applications arose, communication security was added at different layers, via standard protocols such as IPsec or DTLS. The security of the software itself, however, did not receive much attention. Although a continuous integration system is in place, it lacks serious quality assurance efforts and, not surprisingly, does not rely on formal verification. Selected modules of Contiki have already been verified with Frama-C/WP. In a VESSEDIA WP1 meeting in March 2017, the modules of Contiki were assessed with respect to their priority in the project. Two of them, lib and sys, were assessed as highly critical, and were assigned top priority. The former is concerned with memory management, lists, cryptography, etc., while the latter contains core operating system components like scheduler and timers. We concentrated our efforts on module lib, and had a glance at module sys. 6.3 Minimal-contract verification of selected files We found that Frama-C/WP was easy to use for the native configuration of Contiki. However, it is important to keep in mind that Contiki has a huge amount of configuration parameters. The main emphasis of Frama-C has been initially on analysis of embedded software. As a consequence, we had experienced problems with Frama-C support for software running on standard platforms, like e.g. Linux, where appropriately adapted versions are unavailable for less commonlyused include files. In such cases, manual adaptation of existing include files, often causing additional discussion with the software provider, had been necessary before start of analysis. In contrast, Contiki is a fully self-contained operating system that comes with its own include files. At least in the modules we considered for analysis, no adaptation of the latter was necessary. For the Frama-C setup, we obtained the necessary pre-processor directives from the output of the build process for a hello-world application which was recommended for tutorial purposes by the main README file of the Contiki sources. These directives are rather lengthy and hence are not shown here in detail. We also employed an external Frama-C/WP driver file registering a file Lemmas.v which contains some ACSL lemmas and their Coq proofs. • For the following files, we built minimal contracts and verified them: o lib/crc16.c o lib/gcr16.c o lib/ifft.c o lib/ringbuf.c o lib/ringbufindex.c • Besides these files we found that some files were trivial to analyse. No manual annotations were needed for them in order to make Frama-C prove the absence of run-time exceptions. These were: o lib/assert.c o lib/metabs.c o lib/print-stats.c o lib/random.c o lib/settings.c D1.1 Security requirements for connected medium security-critical applications VESSEDIA D1.1 Page 50 of 58 o sys/arg.c o sys/energest.c • On the other hand, some files were intractable, i.e. couldn't be handled with Frama-C/WP due to implementation restrictions. These were, grouped by intractability reason: • validity of unsized-array not implemented yet: o lib/sensors.c o sys/procinit.c • \valid_function not yet implemented: o lib/aes-128.c o lib/ccm-star.c o lib/trickle-timer.c o sys/process.c o sys/rtimer.c • calculus failed on strategy for XXX behaviour YYY, all properties, both assigns or not because unsupported non-natural loop(s): try [-wp-invariants] option (abort): o sys/ctimer.c o sys/etimer.c • Finally, the following files can be handled by Frama-C, but require additional manual annotations that we did not yet provide: o lib/crc16.c o lib/gcr.c o lib/list.c o lib/me.c o lib/memb.c o lib/mmem.c o lib/petsciiconv.c o sys/autostart.c o sys/compower.c o sys/mt.c o sys/stimer.c o sys/timer.c For details, we refer to the technical report "Annotating IoT-Software With Minimal Contracts" (May 2017).