The SPIC project has three main research objectives. First, specifications of wireless protocols are analyzed to identify and fix potential vulnerabilities as early as possible. Second, wireless products already on the market are tested for vulnerabilities to identify the causes of insecurity. This also includes the development of new wireless attack methods. Third, solutions are developed to improve security of wireless communication in a targeted manner. This includes for example the development of a novel type of Bluetooth security analyzer which can be used to analyze specification implementations and concrete products.  

The first results have shown severe vulnerabilities in various products with wireless connectivity. For example, proprietary protocols with insufficient security were found in smart locking systems. In wireless computer peripherals, vulnerabilities were discovered that allow cyber-attacks on companies. The development of various attack tools and demonstrators has clearly shown the effects of these security vulnerabilities in practice. 

During the last decade, "Greybox" or coverage guided fuzz testing has become a preferred method for testing conventional software. It can achieve a fully automated and deep testing with minimal manual setup effort. The central idea of coverage guided fuzzing is to use a feedback loop between the fuzzer and the target that gives the fuzzer information about the code coverage achieved with the current fuzz case allowing it to optimize its search. 

Current techniques for coverage guided fuzzing rely on instrumentation, emulation or OS-features not available or feasible for deeply embedded or power constrained systems that typically run a minimalistic (real-time) OS or even a bare-metal monolithic firmware. Emulation is complicated by dependencies on peripherals and real-time constraints. 

In the project ETCH, we make highly effective coverage guided fuzzing applicable to deeply embedded systems with minimal setup effort by testing the target code unmodified on its original hardware. To achieve this, we develop methods to extract sufficient coverage information from available hardware based feedback channels such as debug and tracing interfaces or power and EM side-channel analysis. 

CryptoBlue investigates the security of Bluetooth protocols from a cryptographic viewpoint. Bluetooth is a security protocol to connect wireless devices within short distances. It is used extensively in the Internet of Things (IoT) today, and is also highly visible in our daily lives, for example, when connecting mobile phones to cars or headphones to computers. The goal of the project is to make mathematically sound statements about the achieved security and privacy guarantees of the latest Bluetooth standard. One of the interesting aspects in the research is that Bluetooth involves human interactions for the connection, which differentiates it from other security protocols. If weaknesses are detected during the investigations, they are disclosed responsibly and the project proposes secure fixes. 

Software-programmable microcontrollers are still the most common main processing units for cost and energy efficient Internet-of-Things (IoT) systems. As such, they remain susceptible to attacks via vectors such as buffer overflows and code injection. Some of these attacks can be defended against by static protection measures. However, these established techniques can neither detect temporal anomalies, nor perform semantic analyses of the processed data values. 

The Dynamic Execution Integrity Engine (DExIE) developed in the SHMoDaCo project is a lightweight hardware monitor that can be flexibly attached to many IoT-class processor pipelines. It is guaranteed to catch both inter- and intra-function illegal control flows in time to prevent any illegal instructions from touching memory. The performance impact of attaching DExIE to a core depends on the concrete pipeline structure. In some especially suitable cases, extending a processor with DExIE will have no performance penalty. DExIE is real-time capable, as it causes only very few and then perfectly predictable pipeline stalls.  It is often faster than software-based monitoring and often smaller than a separate guard processor.