Wireless Sensor Network, 2011, 3, 10-17
doi:10.4236/wsn.2011.31002 Published Online January 2011 (http://www.SciRP.org/journal/wsn)
Concealed Integrity Monitoring for Wireless
Sensor Networks
Björn Stelte, Thomas Bühring
Institut für Technische Informatik, Universität der Bundeswehr München, Neubiberg, Germany
Received December 21, 2010; revised December 29, 2010; accepted January 5, 2011
Abstract
Nowadays, sensor networks are widely installed around the world. Typical sensors provide data for health-
care, energy management, environmental monitoring, etc. In the future sensors will become a part of critical
infrastructures. In such a scenario the network operator has to monitor the integrity of the network devices,
otherwise the trustworthiness of the whole system is questionable. The problem is that every integrity proto-
col needs a secure channel between the devices. Therefore, we will introduce a covert channel for hidden
transportation of integrity monitoring messages. The covert channel enables us to hide integrity check mes-
sages embedded into regular traffic without giving potential attackers a hint on the used integrity protocol.
Keywords: Covert Channel, Integrity Monitoring, Wireless Sensor Network
1. Introduction
A possible scenario for a distributed system that needs
close monitoring of its integrity is a wireless sensor net-
work (WSN). Aside from secure communication chan-
nels, the main concern in WSN is the integrity of nodes,
since the widespread use of shared secrets, if any, in
communication protocols is based on the assumption that
nodes are not compromised.
Integrity of nodes may for example be verified by an
attestation protocol, which uses a trusted platform mod-
ule (TPM) to attest the integrity of cluster heads [1]. But
in order to enable a WSN-operator to react to tampering
attempts, information about node integrity needs to be
exchanged throughout the network. If such information
is exchanged overtly, attackers may be aware of the fact
that the network is being monitored. Analysis of ex-
changed information may even reveal how often such
information is exchanged and if no appropriate crypto-
graphic countermeasures are taken, it may also be possi-
ble to tell what information is exchanged.
As a solution, the integrity monitoring information
could be covertly e mbedded into traffic th at fits the well-
known purpose of the WSN, e.g., measurements of en-
vironment temperature. This does not only prevent at-
tackers from determining what information is exchanged
in order to assess node integrity, but it will even be dif-
ficult if not impossible to tell whether the integrity of a
particular network is actually being monitored. Plain
encryption of the communication channel in contrast
does not provide a similar level of deception, since it
may still be possible to distinguish ordinary traffic from
integrity monitoring traffic, e.g., by tampering nodes
while monitoring the change of message frequency or
size.
2. Requirements
According to [2], the “quality of the covert channel can
be expressed in terms of detectability (arbitration must
be measurable by the recipient), indistinguishableness
(hidden data cannot be separated from the cover infor-
mation) and bandwidth (ratio of hidden data to cover
data).” Yet, a covert channel for integrity monitoring
must not only be of sufficient quality in terms of this
definition but it must also meet some specific require-
ments derived from surveillance scenarios.
1) Delay: Typically, covert channels have a compara-
ble low ratio of hidden data to cover data. In addition to
that, they rely on the occurrence of network traffic that
can be used as a disguise for the hidden communication.
But to provide the means for efficient administrative
reaction, a reasonable maximum delay for event notifica-
tions is required. In case of covert channels, signaling a
critical system event would rely on ordinary cover traffic
taking place. A general question is, what can be done if

B. STELTE ET AL.
11
there is not enough cov er traffic or no cover traffic at all
when a critical event needs to be signaled. Regarding
scenarios such as monitoring critical infrastructure or
even in military scenarios, continuous and sufficient
network traffic are assumed.
2) Recurrence: If a covert channel is used to repeat-
edly communicate possibly unchanged information of a
node, care must be taken to avoid recurring patterns
when embedding this information into traffic that would
otherwise not have recurring patterns. The challenge is
therefore not only to hide occasional, differing event
notifications but also to disguise the transmission of re-
curring events or health information.
3) Unidirectional channel: For the purpose of this dis-
cussion only a unidirectional channel is required, even if
WSNs in surveillance and military scenarios would ben-
efit from a bidirectional communication channel for de-
livering sensor control commands. This is because for
the sake of simplicity the focus of this work is narrowed
and the results from a unidirectional communication
channel can possibly be transferred to a bidirectional
situation.
3. Related Work
Covert channels were first defined by Lampson as chan-
nels “not intended fo r information transfer at all, such as
the service program’s effect on the system load” [3].
Covert channels can be classified in the broader scope of
information hiding. However, there is no clear distinction
between steganography and covert channels. A possible
explanation is that covert channels establish information
flows between entities which would otherwise not be
allowed to communicate at all or using channels that are
not intended for communication, while steganography
enables entities to convey additional information among
legitimate, or disclosed, data. The term “covert channels”
seems to have prevailed in the context of networks and is
used to describe any information hiding approaches in
network communications, sometimes merrily mixed with
“steganography”.
Simmons et al. [4] introduced an illustrative, yet for-
mal setting for the steganographic problem: Two prison-
ers (e.g., Alice and Bob) are only allowed to communi-
cate through a warden (e.g., Willie). Their goal is to de-
vise an escape plan without the warden noticing while
the warden hopes to deceive them by altering communi-
cation or introducing bogus messages. Further, active
wardens, which might deliberately alter or introduce
messages, and passive wardens, which are limited to
observing communication, are distinguished [5].
Lampson [3] defined covert channels in the context of
process isolation within a single host operating system.
Today the possibility of covert channels in distributed
systems is a major concern, e.g. if organizations intend to
control particularly outbo und information flows from the
organi zation’s network.
In practice, two types of covert channels can be dis-
tinguished by their realization [6]. Storage-based covert
channels involve the direct or indirect reading and writ-
ing of storage locations between different processes and
timing-based channels use an modulation of system re-
sources that can be observed by another process. Appar-
ently, covert channels can also be characterized by the
layer(s) of the OSI reference model on which they oper-
ate. Handel and Sandford [2] demonstrated, how each
OSI layer could be used as a basis for implementing a
covert channel.
The evaluation of covert channels is only possible
with regard to a specific deployment. Still, it is assumed
that protocol header manipulation will deliver better per-
formance than payload steganography. At the same time,
a protocol header manipulation algorithm for a commu-
nication protocol introduces less requirements on the
particular type of cover traffic compared to applying
steganography to the cover payload. Hence, this section
is focused on covert channels based on network header
manipulation.
4. Model of a Network Covert Channel for
Integrity Monitoring (NCCIM)
This section develops a model of a unidirectional chan-
nel that connects a sensor agent application and moni-
toring application, which are running on different net-
work nodes. This model of a Network Covert Channel
for Integrity Monitoring (NCCIM) is intended to be a
modular framework for providing robust communication
between sensor and monitor. The framework is based on
the OSI reference model to provide flexibility for im-
plementations.
The sending stack of the NCCIM is responsible for
embedding the covert traffic on a node that is monitored
by a sensor agent. It interfaces with the sensor agent ap-
plication and the cover traffic source, which is the sub-
system handling network traffic generated by other ser-
vices running on that node. Similarly, the NCCIM re-
ceiving stack extracts the covert monitoring information
on the node running the monitoring application. It inter-
faces with the cover traffic sink, which is the subsystem
responsible for receiving network traffic of that node,
and the monitoring application. The NCCIM model pro-
vides a framework for the modification and interception
of cover traffic. Monitoring information is covertly com-
municated from sensors to a monitor. The covert channel
is developed given the following assumptions about the
nodes running the sensor agent or monitoring agent:

12 B. STELTE ET AL.
1) The overt services running on the node being moni-
tored generate a continuous traffic flow that provides an
upper bound on the delay of the covert channel.
2) The subsystem of the nodes responsible for deliv-
ering network traffic (traffic source) and the subsystem
responsible of receiving network traffic (traffic sink)
allow traffic to be modified and to be intercepted, re-
spectively.
3) The nodes running the sensor agents are based on
an execution model that supports concurrency.
4) Each sensor agent reports to the same monitor.
NCCIM is not responsible for gathering monitoring
data, which is performed by the sensor agents, or ana-
lyzing such data, which is the task of the monitoring
agent. However, the covert channel must ensure some
requirements on the monitoring information being trans-
mitted. Given the characteristics of a covert channel as
the limited capacity and th e need for hiding any commu-
nication associations, the relationship between sensor
agents and monitoring agents should be managed by the
NCCIM. In addition to that, ordinary communication
tasks from transport to physical layer need to be per-
formed. Hence, the NCCIM must operate on OSI layers
1 (Physical Layer) to 6 (Session Layer). For further dis-
cussion, problems that can be solved in a more or less
platform-independent way are assigned to different enti-
ties based on the OSI-reference model.
Monitoring information gathered by the sensor agents
can be represented in various formats. Well-known stan-
dard formats include syslog messages or the RMON
MIB. Custom formats may be based on XML, but it is
also possible to use an optimized binary format. The ac-
tual representation of the monitoring information is
therefore out of the scope of this architecture. However,
it is relevant if all messages are of fixed size or if vari-
able length messages must be handled (Pa6.1, see Table
1). Regardless of the fact whether messages have vari-
able size, the (maximum or general) message length de-
termines if fragmentation is necessary at the Data Link
Layer (Pa6.2). Messages smaller than the maximum
message size can be pad ded (Pa6.3).
4.1. Managing the Relationship Between Sensor
Agent and Monitoring Agent
The Sensor Session Entity provides three access points to
the sensor agent application (see Table 2). The Sensor
Agent Up and Sensor Agent Down primitives indicate
that the sensor agent is started and stopped, respectively.
The Sensor Agent Information primitive is used to send
event or status information.
The Monitor Session Entity requires according upper
layer interfaces, to inform the monitor application about
Table 1. Presentation layer parameters.
ID Name Description
Pa6.1 Fixed message
size
Boolean value that determines, if
monitoring information is represented
in fixed size messages.
Pa6.2 Maximum
message size
Unsigned integer value denoting the
maximum size of monitoring infor-
mation to be transmitted. If fixed size
messages are used or messages are
padded, this is the size of all mes-
sages.
Pa6.3 Message
padding
Boolean value that is true if a padding
is appended to messages smaller than
the maximum message size. Is only
used if the application does not pro-
vide fixed size messages.
Table 2. Session layer interfaces.
ID Primitive Parameters
Sensor Session Entity
Pr5.1 Sensor Agent UpIdentifier of the node that is started and optional information
payload.
Pr5.2 Sensor Agent
Down
Identifier of the node that is
stopped and optional informa-
tion payload.
Pr5.3 Sensor Agent
Information
Identifier of the node sending
the information and the infor-
mation payload to be delivered.
Monitor Session Entity
Pr5.1 Received Up
Information Node identifier and optional information payload.
Pr5.2 Received Down
Information Node identifier and optional information payload.
Pr5.3 Received Moni- toring Informa-
tion
Node identifier and monitoring
information payload.
Sensor Association Created, Sensor Association Deleted
and to deliver monitoring messages (Sensor Information
Received). In addition to that, the Sensor Association
Timeout primitive is used to notify the monitor applica-
tion if a sensor agent failed to send a keep-alive message
within the expected time range.
On receipt of a Sensor Agent Up primitive, the Sensor
Session Entity creates an association between the given
sensor agent nod e identifier and the monitor node identi-
fier (in Table 3), which is known beforehand. This asso-
ciation is created by invoking the Send Up Information
primitive of the Sensor Transport Entity with the sensor
agent node identifier. If the Monitor Session Entity re-
ceives an Up Information Received primitive, the asso-
ciation is created at the monitor. A similar procedure is
used for the Sensor Agent Down primitive, which de letes
the association. The Sensor Agent Information primitive
is mapped to the Send Monitoring Information primitive.
Node registration and authentication are out of scope of
this architecture and should be provided by the sensor
and monitor application , resp ectively.

B. STELTE ET AL.
13
Table 3. Application layer interfaces.
ID Primitive Parameters
Monitor
Application
Entity
Pr7.1 Sensor Association
Created
Sensor agent node identifier
for which the association was
created.
Pr7.2 Sensor Association
Deleted
Sensor agent node identifier
for which the association was
deleted.
Pr7.3 Sensor Information
Received
Sensor agent node identifier
for which information was
received and the information
payload.
Pr7.4 Sensor Association
Timeout
Sensor agent node identifier
for which no keep-alive mes-
sage was received within the
expected time interval.
If keep-alive messages are used, the session layer
maintains a timer for each association scheduling the
next keep-alive message. The timer is initialized during
the creation of the association an d is set to the keep-aliv e
interval (Pa5.1) minus a pseudo-random offset. If a keep
alive message is due, the Send Monitoring Information
primitive is invoked for the particular association with an
optional additional payload provided by the sensor ap-
plication (which can be used for latency measurement if
clocks are synchronized) and the ti mer is re-initialized as
described above. If a monitoring message is sent for this
association, the timer for the next keep-alive message is
reset to its initial value. Accordingly, the Monitor Ses-
sion Entity keeps track of all associations and the latest
valid arrival time for a keep-alive message. If this time is
exceeded, the Sensor Association Timeout primitive of
the monitor application is invoked. The latest valid arri-
val time is set on creation of the association and on re-
ceipt of a Received Monitoring Information primitive
from the Monitor Transport Entity. It is calculated from
the current time, the keep -alive interval (Pa5.1, as shown
in Table 4) and an implementation dependent tolerance
offset (Pa5.2).
4.2. Transport Layer
As shown in Table 5, the Sensor Transport Entity pro-
vides the access points Send Up Information , Send Down
Information and Send Monitoring Information to the
Sensor Session Entity. Analogous to the sensor, the Mon-
itor Transport Entity issues the primitives Received Up
Information, Received Down Information and Received
Monitoring Information. The task of the transport layer
in this architecture basically is to perform integrity
checks (Pa4.3).
The channel provided by this architecture is unidirec-
tional and thus unreliable, which avoids the complexity
Table 4. Session layer parameters.
ID Name Description
Pa5.1 Keep-alive
interval
Unsigned integer value indicating the
maximum time between two keep-alive
messages (in seconds). If zero, sending
entities do not verify the covert channel
availability by periodically sending
keep-alive messages.
Pa5.2 Keep-alive
tolerance
Unsigned integer value giving an im-
plementation dependent tolerance for
the keep-alive interval.
Table 5. Transport layer interfaces.
ID Primitive Parameters
Sensor Transport Entity
Pr4.1 Send Up
Information
Identifier of the node that is
started and data to be sent, which
is the data header (including node
identifier) and an optional moni-
toring payload.
Pr4.2 Send Down
Information
Identifier of the node that is
stopped and data to be sent, which
is the data header (including node
identifier) and an optional moni-
toring payload.
Pr4.3 Send Monitoring
Information
Identifier of the node that sends
the monitoring information and
data to be sent, which is the data
header (including node identifier)
and the monit oring payload.
Monitor Transport Entity
Pr4.1 Received
Segment
Node identifier and the segment,
which may be constructed from
several frames.
of a bidirectional protocol and reduces requirements that
must be met by an underlying communication platform.
However, loss of messages can be detected by the re-
ceiver if both, sender and receiver, use a consistent seg-
ment (sequence) numbering scheme (Pa4.2). The initial
sequence number for a new association is when the Sen-
sor Transport Entity processes a Send Up Information
primitive. The algorithm to determine the initial se-
quence number from the node identifier and other suit-
able characteristics known by the sensor as well as the
monitor is implementation dependent and may be based
on a shared secret, which acts as a seed. A non-trivial
assignment of initial sequen ce numbers enables the mon-
itor to authenticate the pro cess of creating an association,
as the result of this check is included in the Received Up
Information primitive.
The MIC value is calculated by an implementation
dependent function. The input for the MIC calculation
consists of segment header, where the MIC field is set to
all zeros, and segment body.
If a Received Segment primitive is issued by th e Moni-
tor Data Link Entity for a node identifier for which no

14 B. STELTE ET AL.
proper Up segment was received before, the Received Up
Information primitive is issued prior to the Received
Monitoring Information primitive. This behavior ac-
counts for the unidirectional channel and will further be
referred to as implicit association creation.
The distinction between up, down and message seg-
ments is introduced for the sole purpose of managing the
process of assigning sequence numbers and the associ-
ated resources. The segment is composed from the seg-
ment header, which consists of the segment type field
(Pa4.1, Table 6) and the sequence number, if any, and
the segment body containing the monitoring information.
Because of the absence of multiple monitors (assump-
tion 4), no logical addressing of recipients is required.
Furthermore, the realization of multi-hop communication
using the covert channel is highly implementation de-
pendent as explained below. Hence, introducing a network
layer is regarded as an unnecessary overhead and seg-
ments are directly interchanged wi th the Data Li nk Layer.
If possible at all, multi-hop communication with the
monitor using a covert channel can be realized using
different approaches. Flooding may be implemented by
embedding the covert channel in traffic to all communi-
cation partners. Static upstream routes can be represented
as filters, selecting which PDU of the overt channel are
used for embedding the covert information. This decision
may for example be based on the destination address of a
PDU and enables the exploitation of more complex
routes of the overt channel. Such procedures belong to
the physical layer of the covert channel, which is imple-
mentation depende nt .
4.3. Encoding into Cover Traffic
The data link layer and physical layer are responsible for
embedding the covert channel into overt traffic. While
most aspects of the physical layer depend on the sp ecific
implementation used, the concepts of the data link layer
can be formulated in a generic way. As shown in Table 7 ,
the Sensor Data Link Entity provides the Push Segment
access point to the Sensor Transport Entity and the Pop
Frame access point to the Sensor Physical Entity, while
the Monitor Data Link Entity issues the Received Seg-
ment primitive to the Monitor Transport Entity.
Table 6. Transport layer parameters.
ID Name Description
Pa4.1 Segment Type
Size Unsigned integer giving the size of the segment type field in bits.
Pa4.2 Sequence Number
Size
Unsigned integer value indicating the
size of sequence numbers. If zero, no
sequence numbers are sued.
Pa4.3 Message integrity
size
Unsigned integer value which is zero if
no message integrity check is per-
formed.
Table 7. Data link layer interfaces.
ID Primitive Parameters
Sensor Data
Link Entity
Pr2.1 Push Segment
Identifier of the node for which
the segment is sent and the
segment to be sent, which may
require fra gmentation.
Pr2.2 Pop Frame (no parameters)
Monitor
Data Link
Entity
Pr2.1 Push Frame
A buffer containing the re-
ceived frame.
These entities performs the task of (de-)fragmen tation,
if the sum of the maximum size of monitoring informa-
tion (Pa6.2) and the size of all headers is larger than the
maximum frame size (Pa2.2, Table 8). An implementa-
tion determines the frame size from the maximum num-
ber of bits that can be embedded in a cover PDU. If
fragmentation is required, it can be necessary to prefix
the frame not only with a node identifier (Pa2.1 ) but also
with a fragment number (Pa2.3). The prefix is then used
to determine the right ordering of the frames to get the
original segment. It is only required if the protocol used
for traffic encoding does not guarantee sequential deliv-
ery of data (for example IP) or if the traffic interception
is done in such a ways that the ordering features of a
sequential protocol cannot be used (for example inter-
cepting TCP traffic in the systems IP stack). The number
of bits available for representing the fragment number
(Pa2.4) limits the number of possible fragments. Thus, it
should be consistent with the maximum data size (Pa6.2),
if not, errors may b e introduced.
Table 8. Data link layer parameters.
ID Name Description
Pa2.1 Node identifier
size Unsigned integer value denoting the size of node identifiers.
Pa2.2 Frame size
Unsigned integer giving the number
of bits to be sent in one block. De-
termines if fragmentation is neces-
sary.
Pa2.3 Fragment
numbering
required
Boolean value indicating if fragments
must be numbered.
Pa 2.4 Fragment
number size
Unsigned integer indicating the num-
ber of bits available for representing
the frame number.
Pa 2.5 Maximum
frame de lay
Unsigned integer value giving a
maximum time for a frame to be sent
(in seconds).
Pa 2.6 Frame delay
tolerance
Unsigned integer providing an im-
plementation dependent monitor side
tolerance offset.

B. STELTE ET AL.
15
The Sensor Data Link Entity maintains a queue of
frames to be sent (frame queue). The entries of this
queue consist of the frame and the latest valid encoding
time. The latest valid encoding time is calculated from
the time when the first frame of the current segment got
pushed into the queue plus a maximum encoding delay
(Pa2.5). If this time is exceeded, the whole segment is
invalidated and the Segment Encoding Timeout primitive
is issued, which is handed through the layers to the sen-
sor application.
The actual encoding of bits is done by an implementa-
tion specific function (for example a packet injection
hook) that retrieves a frame from the frame queue and
encodes it into the cover traffic.
4.4. Channel Characteristics
Several characteristics useful for the evaluation of
NCCIM implementations can be formulated. First, the
overhead overhead for a particular monitoring message m
in bits is a linear function of the number of fragments
required to encode m, the size of a frame
header ov and the size of a segment header
s
erhead

frag
nm
s
*
s
egmenthdr
s.

overheadfragframehdr segmenthdr
snmss
While the message size |m| and thus the number of frag-
ments may be variable, the other values are implementa-
tion dependent constants derived from the size of the
different header fields indicated by s. In particular,
sframe is the total size of a frame and as described
below, it depends on the enc o di n g fu ncti o n used.

frag
f
rame framehdr
m
nm SS





f
ramehdrfragnum nodeid
sss
s
egmenthdrsegtype seqnum mic
s
sss
Given an encoding function c that encodes a secret
frame into a cover-PDU x, the ratio between the cover-
PDU size |x| and the number of secret bits encoded by c
can be expressed as
 
,
cencodedc
x
rx nx 
For the majority of observed covert channel imple-
mentation, is a constant, i.e., the number of
bits encoded does not depend on the particular
cover-PDU. This is assumed for all NCCIM implementa-
tions. Furthermore, a frame is expected to be the smallest
bit sequence that can be transmitted in one piece. In this
case, .
,encoded c
n
,c frame
nS
encoded
The number of cover-PDU required to encode a moni-
toring message m is therefore . However, the
above characteristics can only be expressed with respect
to secret and overt network traffic samples. Thus, a gen-
eral evaluation of a NCCIM implementation is possible,
if corresponding average values are known or assumed.
It is then possible to express the time required to transmit
m as

frag
nm
cov
ˆ
f
rag er
tn t
where cover t is the average inter-arrival time of cover-
PDU.
5. Prototypical Implementation for Wireless
Sensor Networks
In this section, a very basic implementation of the sce-
nario of a WSN covert channel is presented. The overt
task of the WSN deployed in this implementation (see
Figure 1) is to collect temperature information. To pro-
tect the network against theft of sensor nodes, a covert
channel is used to alert the operator if a node is moved.
This prototypical implementation is focused on 1) illus-
trating the utility of a covert channel for hidden network
supervision and 2) demonstrating the feasibility of the
infrastructural requirements of the NCCIM physical
layer in a WSN deployment. Hence, this covert channel
does not provide strong protection against detection or
modification of the covert information.
5.1. Hardware
The implementation is based on Crossbow MICAz
MPR2600 motes, which are a retail version of the MI-
CAz MPR2400. The following information is based on
the description of the MPR2400 mote in [7]. These
motes use a IEEE 802.15.4 compliant Chipcon CC2420
radio and are operated using a Atmega128L micro-con-
troller. For the temperature and acceleration measure-
ments, the Crossbow MTS400CA sensor board [8] is
added. The particular sensors used are the Sensirion
SHT11 (temperature) and the Analog Devices
ADXL202JE (acceleration). The motes were pro-
grammed using the Crossbow MIB520 USB Interface
Board.
5.2. Implementation Overview
The actual implementation is realized as software based
on TinyOS 2.1 and the BLIP. It consists of a mote pro-
gram, which measures temperature and detects node
movement by acceleration changes, and two distinct
programs running on the gateway host (see Figure 1).

16 B. STELTE ET AL.
Figure 1. Overview of the wireless sensor network setup.
Overtly, only the temperature and an internal counter
value are sent to the gateway using UDP packets. The
information about whether the node was moved or not is
encoded into a rudimentary covert channel. The IPBas-
eStation program and the ip-driver used to connect the
WSN to the host-only IPv6 network are provided by the
BLIP software, which is included in TinyOS 2.1.
5.3. Sensor Node Program
The IPBasicSensor progr am running on the sensor nodes
performs the measurement tasks and reports to the gate-
way host using UDP. It is written in NesC and uses sev-
eral components provided by TinyOS 2.1. Temperature
and acceleration are measured by the program in inter-
vals of 250 milliseconds. The temperature is stored for
later use, while the current acceleration is compared to
that measured before. If the difference between both
values is greater than a predefined tolerance, a node
movement is detected. Because the program is only in-
tended to be a proof of concept implementation, the false
positives or negatives resulting from this simple algo-
rithm are acceptable. Every five seconds, a UDP data-
gram containing a measurement report is sent to the
gateway host. A modified BLIP stack is used to send the
datagrams, which implements the encoding of covert
information into the overt measu rement reports.
Among other, the program uses the UDPShellC com-
ponent, which is also included in TinyOS 2.1, to provide
a simple CLI that can be accessed from IPv6 hosts using
UDP. The CLI is used for debugging purposes, because
it provides diagnostic utilities like a ping-command or
custom commands displaying internal data structures. In
addition to that, the predefined tolerance for the move-
ment detection can be adjusted using the CLI.
5.4. Gateway Server and Sniffer
In the implementation setup, there are two programs in-
tended to run on the server. basic_sensor_server is per-
forms the overt sensing task of the example WSN. The
program creates a socket, which binds to the UDP port
specified in the header file. As long as it is not inter-
rupted by the user, it receives the measurement reports
sent by the sensor node and prints these reports to the
command line.
basic_sensor_sniffer can be used to decode the covert
information from the traffic. The sniffer is using the
PCAP library to capture IPv6 traffic on the specified
interface. It displays a text message if the cover traffic
contains the information that a node movement was de-
tected by IPBasicSensor.
6. Covert Channel
Because this implementation serves solely for demon-
stration purposes, it does not implement the layer model
from Section 4. Instead, a basic covert channel data link
layer is sufficient because the channel is only used to
transmit an indication, whether the sensor node was
moved or not. On the covert channel physical layer, this
information is encoded in the IPv6 hop limit header field.
For the sake of simplicity, the overt channel in this sen-
sor node example involves significant overhead regard-
ing the use of IPv6 and UDP headers compared to 32 bit
sensor payload. In contrast, the covert channel introduces
no overhead, as the 8 bit frame is directly written to the
hop limit field, which is of the same size. This is why the
covert channel is easy to detect. Besides, it does not pro-
vide integr ity check and it does not enable loss d etection
or the tracking of associations between sensor and moni-
tor. This illustrates why a robust co vert channel based on
the model presented in Section 4 provides limited cap ac-
ity while requiring significant overhead at the same time.
7. Conclusions
As the presented proof-of-concept prototype in Section 5
illustrates, network covert channels can be used to hide
the integrity monitoring of a distributed WSN system. If
implemented properly, a covert channel does not merely
disguise that the distributed system is supervised, it also
avoids disclosing what event or status information is
transmitted and, given sufficient and continuous cover
traffic, in which intervals this is done.
The actual encoding of secret fragments into cover
traffic is subject to extensive research, which is to some
extent presented in Section 3. However, a deployment
of a covert channel in the context of integrity monitor-
ing requires a certain degree of robustness, which is
highly dependent on the deployment platform and the
particular type of cover traffic. This characteristic is not
provided by the majority of the proof of concept im-
plementations.
The model of a network covert channel presented in
Section 4 gives a modular description of the necessary
tasks to ensure robust covert communications between
sensor nodes and a monitor. The layer architecture of the
model provides flexibility for specific requirements of

B. STELTE ET AL.
17
different deployment platforms or different types of
cover traffic. From the description of several channel
characteristics it can be seen that there is a trade-off be-
tween robustness and capacity of a covert channel.
8. References
[1] C. Krauß, F. Stumpf and C. Eckert, “Detecting Node
Compromise in Hybrid Wireless Sensor Networks Using
Attestation Techniques,” Proceedings of the 4th Euro-
pean conference on Security and Privacy in Ad-Hoc and
Sensor Networks, 2007.
[2] T. G. Handel and M. T. Sandford, “Hiding Data in the
OSI Network Model,” Proceedings of the First Interna-
tional Workshop on Information Hiding, Vol. 1174, 1996,
pp. 23-38. doi: 10.1007/3-540-61996-8_29
[3] B. W. Lampson, “A Note on the Confinement Problem,”
Communications of the ACM, Vol. 16, No. 10, 1973.
doi:10.1145/362375.362389
[4] G. J. Simmons, “The Prisoner’s Problem and the Sub-
liminal Channel,” Workshop on Communications Security
(CRYPTO’83), 1984.
[5] F. A. P. Petitcolas, R. J. Anderson and M. G. Kuhn, “In-
formation Hiding — A Survey,” Proceedings of the IEEE,
Special Issue on Protection of Multimedia Content, 1999.
[6] National Computer Security Center, “A Guide to Under-
standing Covert Channel Analysis of Trusted Systems,”
1993.
[7] Crossbow Technology Inc., “MPR-MIB Users Manual,”
June 2006.
[8] Crossbow Technology Inc., “MTS/MDA Sensor Board
Users Manual,” June 2006.