# Feasibility Assessment of a Fine-Grained Access Control Model on Resource Constrained Sensors
## 3 Access Control Model
### Authorization Policy Language and Codification
#### 3.2.2 Measurable Policy Instance Examples
Contiki OS combines the advantages of events and threads, therein implementing a hybrid _Prototthread_ model, which supports both event-driven and multi-threading operation. Contiki OS comes with a library that offers pre-emptive multi-threading on top of the event-driven kernel. The library is only linked with the program if an application explicitly uses it. The Contiki OS memory has a footprint of 1.5 kB, and the OS is written in the C language, with the inclusion of its own adaptation directives for the use of threads and the hardware functionalities of the sensors. This OS's kernel allows direct communication with the hardware by the drivers. There are two partitions in the OS: the core and the loaded program. As a general rule, the core is not changed once loaded, while the loaded program can be modified at run time. The implementation of the energy management is not performed natively by the OS; it must be implemented through a series of developer-provided functions. Contiki OS has been ported to a number of more platforms based on different microcontrollers. For communication, Contiki OS includes microIP (uIP) and Rime stacks. The uIP stack is a light-weight stack that supports IPv6. The uIP stack uses protocols specifically deployed for low-power and wireless memory-constrained real-time sensor devices. Once the operating system is selected, compatible C0 and C1 hardware platform sensors are analyzed. The considered sensors are TelosB [34], Zolertia Z1 [35], Wismote [36] and IRIS [37]. The selection criteria are the technical features, broad adoption, the programming potential and usability. These four criteria are appropriate for the prototype, and there is no clear winner. Therefore, IRIS is selected for implementing the sensor-side Hidra protocol and TelosB for implementing the border router because of the broad adoption, availability and previous background. Their technical features are summarized in Table 6. \begin{table}
\begin{tabular}{l c c} \hline \hline  & **TelosB** & **Iris** \\ \hline
**Processor** & TI MSP430, 16 bit & XM2110 CA, 8 bit \\
**Program Flash** & 48 kB & 128 kB \\
**Measurement Serial Flash** & 1024 kB & 512 kB \\
**RAM** & 10 kB & 8 kB \\
**Serial communications** & UART / USB & UART / MIB520 CB \\
**RF transceiver** & CC2420 & CC2520 \\
**RF frequency band** & 2400 to 2483.5 MHz & 2405 to 2480 MHz \\
**Current draw / Rx** & 23 mA & 16 mA \\
**Transmit data rate** & 250 kbps & 250 kbps \\
**Outdoor range** & 75 to 100 m & 300 m \\
**Indoor range** & 20 to 30 m & 50 m \\
**Battery** & 2X AA batteries & 2X AA batteries \\
**User interface** & 3 LEDs & 3 LEDs \\
**Sensors** & Light, humidity, temperature & Light, humidity, temperature \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Hardware technical features. \begin{table}
\begin{tabular}{l c c c c c c} \hline \hline \multirow{2}{*}{**OS**} & \multirow{2}{*}{**Kernel**} & **Network** & **Programming** & **Development** & \multirow{2}{*}{**Scheduling**} & \multirow{2}{*}{**Real-Time**} & **Adoption** \\  & & **Stack** & **Model** & **Language** & & & **\& Support** \\ \hline TinyOS & Monolithic & Yes & Event-driven & NesC & Preemptive & No & High \\ Contiki OS & Modular & Yes & Protothreats & subset of C & Preemptive & Partial & High plus \\ Riot & MicroKernel & Yes & Multi-threading & C, C++ & Priority-based & Yes & High \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Comparison summary of operating systems for Hidra test-bed implementation. #### 4.1.2 Hidra Security Protocol Application Implementation

In the software implementation, two aspects are distinguished: on the one hand, network protocols and the required E2E connectivity, and, on the other hand, the Hidra messaging security protocol running at the application layer. The Hidra messaging protocol application is achieved by different software modules covering different functions for each of the three parties involved in the protocol: subject, ACS, and sensor.