Home
Lehre
MNM Team
Projekte
ATV2 Cluster
DASH
Embedded MSec Lab
EnvComp
PROCESS
QuaSiModO
Previous Projects
Publikationen
en
Securing group communication in constrained networks requires new solutions to be found, implemented and evaluated. This is especially true when group communication is desired, which turns out to be much more difficult to secure than point-to-point communications, as the sharing of keys along the group potentially lowers the security of the solutions. There is a variety of work on security in constrained networks, but most of them only pick one particular security property (e.g. μTesla) or are simply designed for a very specific use case (e.g. Group-DTLS for the lightening industry). This is especially true for group communication, which is a niche, but turns out to be very attractive for constrained networks.
Smart Homes, Cars, Factories, etc. are networks of such devices acting as one system from an outside point of view. Applying well known models of informatics, this networks can be seen as administrative domains (ADs). Following this idea, the owner of a certain system (e.g. the owner of a Smart Home) acts as the administrator to the system, who in turn should decide on who to give access the system and its data. In current deployments, this access is usually managed on top of the cloud instance by registering an external actor (e.g. a smartphone) with access to the cloud service. The external actor sends control messages or data requests to the cloud, acting as some sort of "proxy" forwarding or translating the messages to the constrained device or the network.
With multicasting being an interesting option for many use cases, we are currently developing a testbed, allowing flexible deployment of group communication scenarios and implementations of different solution for secure group communication. The testbed contains devices with different constraints, such as different microprocessor architectures - namely ARM Cortex M0 and ATmega328P, but also single board computers with the ARMv7 and ARMv8 architectures. They all communicate wired (Ethernet) or wireless (Bluetooth or WiFi). The testbed is able to simulate different kinds of communication groups:
Computing Hardware:
Device | Architecture | Clock Speed |
Flash Memory |
SRAM |
---|---|---|---|---|
Arduino Uno |
ATmega328 | 16MHz | 32KB | 2KB |
Arduino M0+ |
ARM Cortex-M0+ | 48MHz | 256KB | 32KB |
Arduino Due |
ARM Cortex-M3 | 84MHz | 512KB | 96KB |
ST NUCLEO-F091RC |
ARM Cortex-M0 | 48MHz | 256KB | 32KB |
ST NUCLEO-F103RB |
ARM Cortex M3 | 72MHz | 128KB | 20KB |
ST Nucleo F401 |
ARM Cortex-M4 | 84MHz | 512Kb | 96Kb |
ST Nucleo144-F429 |
ARM Cortex-M4 | 180MHz | 2Mb | 256Kb |
Network Modules
Controller Hardware:
Device | Architecture | Clock Speed |
Flash Memory |
SRAM |
---|---|---|---|---|
Raspbery Pi v1 |
ARM1176JZF-S | 700MHz |
256MB | |
Raspbery Pi v3 |
ARM cortex-a53 | 1.2GHz Quad Core |
1GB | |
Beaglebone Black |
Cortex-A8 + Dual PRU | 1000MHz | 4GB |
512MB |
Networking Hardware
---------------------
Datenbank-Connect fehlerhaft