A Cloud Design for User-controlled Storage and Processing of Sensor Data

René Hummen∗ , Martin Henze∗ , Daniel Catrein† , Klaus Wehrle∗

∗ Communication and Distributed Systems, RWTH Aachen University, Germany
Email: {lastname}@[Link]
† QSC AG, Germany
Email: {[Link]}@[Link]

Abstract—Ubiquitous sensing environments such as sensor forecast for a specific region. This forecast is then fed back
networks collect large amounts of data. This data volume is to the private weather stations in order to provide its owner
destined to grow even further with the vision of the Internet with an added value service.
of Things. Cloud computing promises to elastically store and
process such sensor data. As an additional benefit, storage and Cloud-based services that operate on sensor data would
processing in the Cloud enables the efficient aggregation and largely contribute to enriching or creating new services such
analysis of information from different data sources. However, as the one described above. However, sensor data often
sensor data often contains privacy-relevant or otherwise sensi- contains privacy or otherwise sensitive (meta-)information.
tive information. For current Cloud platforms, the data owner For example, the weather forecast service may require the
looses control over her data once it enters the Cloud. This
imposes adoption barriers due to legal or privacy concerns. sensor data owner to reveal her location in addition to the
Hence, a Cloud design is required that the data owner can trust raw, insensitive temperature values. While the data owner
to handle her sensitive data securely. In this paper, we analyze may be willing to share this sensitive information with
and define properties that a trusted Cloud design has to fulfill. services that she authorized, she oftentimes does not trust
Based on this analysis, we present the security architecture the Cloud provider or other services to handle her sensitive
of SensorCloud. Our proposed security architecture enforces
end-to-end data access control by the data owner reaching data securely. Therefore, she may refrain completely from
from the sensor network to the Cloud storage and processing using Cloud-services that are based on her sensor data.
subsystems as well as strict isolation up to the service-level. This dilemma highlights the adoption barriers for Cloud
We evaluate the validity and feasibility of our Cloud design computing on sensor data. These adoption barriers arise due
with an analysis of our early prototype. Our results show that to the loss of control of the data owner over her data as
our proposed security architecture is a promising extension of
today’s Cloud offers. previously identified for related scenarios [2], [3].
There exist a number of approaches that aim at providing
Keywords-Cloud, WSN, Security, Architecture secure data storage and computation in the Cloud. These
approaches typically focus on providing hard security guar-
I. I NTRODUCTION antees by using cryptographic primitives such as trusted
Today, the boundaries between the physical world and the platform modules or homomorphic encryption [4], [5], [6].
digital world continue to blur due to advances in the areas of However, the proposed approaches are inadequate for the
ubiquitous computing and wireless sensor networks [1]. At purpose of storing sensitive sensor data in today’s Cloud
the same time, the Cloud computing paradigm has become environments. They either do not provide the necessary
an established alternative to dedicated on premises data user control over outsourced data in the Cloud or they
storage and computation resources. Both trends, ubiquitous introduce excessive encryption overhead when applied to
sensing and Cloud computing, complement each other in comparably small sensor data [7]. Hence, we see the need
a natural way. Sensor networks collect information about for a practically viable approach to storing and processing
the physical environment, but typically lack the resources sensor data in the Cloud.
to store and process the collected data over long periods Our contribution is as follows: Firstly, we analyze the
of time. Cloud computing elastically provides the missing specific threats and security requirements that arise when
storage and computing resources. Specifically, it allows to outsourcing storage and processing of possibly sensitive
store, process, and access the collected sensor data ef- sensor data to the Cloud. Secondly, we discuss how these
fectively via Cloud-based services. To illustrate this fact, properties can be assured and communicated to the user in
consider the following example: Private weather stations do brief. Based on this discussion, we propose the security ar-
not only provide a local view on current sensor readings, chitecture of SensorCloud. SensorCloud provides a platform
but additionally transmit their measurements to forecast (PaaS) for the execution of services that operate on sensor
services running in the Cloud. The Cloud services process data while satisfying and ensuring the derived trust and
and aggregate the received sensor readings and use them in security requirements. Our proposed security architecture
a Cloud-based weather simulation that generates an accurate implements i) early protection of sensor data already in
 Data Owner analysis follows the high-level security objectives identified
Cloud PaaS
by NIST [8]. These objectives are confidentiality, integrity,
Service availability, accountability, and assurance. We focus our
Gateway
discussion on threats specific to the SensorCloud scenario.
Data Service
Data Data
Data
Generic threats for Cloud computing (e.g., infrastructure
Internet
Data availability) are also relevant. However, these have already
Data Flow been studied extensively in [3], [9], [10], [11].
Sensor Network Cloud IaaS
Data confidentiality and integrity: Unprotected sensor data
transmitted to the Cloud for storage and processing can
Figure 1. Abstract overview of a generalized Cloud scenario when be accessed or altered by entities other than the legitimate
outsourcing storage and processing of sensor data to the Cloud. Data flows stakeholders involved in the respective operations. Data in
originate from individual sensors and are forwarded by the gateway to the
Cloud. Within the Cloud, data traverses the IaaS, PaaS, and SaaS layers. transit between the sensor network and the Cloud infras-
tructure may be acquired or deliberately modified by an
the sensor network, ii) user-controlled granting of access to
attacker that is located on or besides the communication
user-selected Cloud services, and iii) strict service isolation
path. Furthermore, sensor data in the Cloud is exposed
within the Cloud platform. These properties enable the data
to potential access or modification by privileged staff of
owner to stay in control over which entities may access her
the Cloud provider (IaaS or PaaS provider). Finally, Cloud
data in the Cloud and, thus, make Cloud-based services on
storage and computing resources are typically shared by a
sensor data viable.
multitude of users and services that are unknown to each
II. S ENSOR C LOUD SCENARIO AND SECURITY CONCERNS other. Thus, unauthorized users or services may gain access
or modify information if the isolation mechanisms of the
Sensor networks typically are dedicated and isolated net- Cloud platform are insufficient.
works that collect information about their environment. The
sensed raw data is commonly collected by a sink node that Data accountability: Once sensor data enters the Cloud
may either pre-process the raw data on-site or forward it platform, the data owner loses control over who can access
directly to its actual consumer. In either case, the recipient of her data. Specifically, the IaaS or PaaS provider (including
the collected information is known at the data sink. Hence, their employees) may forward stored data to unauthorized
the collected data only leaves the network domain of the third parties without the data owner acknowledging or even
data owner on distinct and controlled paths. recognizing this transfer. Likewise, a Cloud service may pass
data that it is authorized to process to a third party unnoticed
However, when the data owner outsources storage and
by the data owner. Consequently, sensitive information may
processing of sensor data to the Cloud, the paths that this
potentially spread across Cloud platform boundaries without
data takes become ambiguous as multiple entities contribute
the knowledge of the data owner.
to the overall service provisioning. More precisely, data
sent by the sensor gateway towards the Cloud traverses Service Availability: The data owner becomes dependent
the IaaS and PaaS layers before being processed by a on the SaaS provider when transferring her sensor data to
service (see Figure 1). The IaaS layer virtualizes its available the Cloud for subsequent processing. This is particularly
physical resources and offers these to multiple IaaS users. true when the result of the processing is time critical,
The PaaS layer is one of these users. It implements the e.g., to trigger an actor or raise an alarm. Hence, the data
run-time environments and APIs that grant a multitude of owner requires a certain service availability guarantee from
services access to the received and stored sensor data. As the SaaS provider. The SaaS provider, in turn, can only
a result of this layered architecture and the inherent use fulfill its guaranteed availability if the PaaS provider can
of multi-tenancy, potentially sensitive sensor data traverses ensure availability of its platform and the IaaS provider can
an unknown set of systems. To overcome adoption barriers ensure the availability of its physical resources. Thus, the
arising from this uncertainty, a trusted Cloud design must disruption of Cloud service by a malicious Cloud user, e.g.,
prevent access to information by the Cloud provider and by imposing high load on the shared physical infrastructure,
third parties, unless the data owner explicitly agrees to share is highly intolerable on any Cloud layer.
it. We now analyze the specific threats when outsourcing Assurance: Assurance denotes the confidence that technical
sensor data to the Cloud in order to identify the issues that and operational security measures work as intended to meet
a trusted Cloud design needs to protect against. the objectives discussed above. Both false positive and false
negative assurances impose risks. A data owner may falsely
A. Threats for Outsourced Data in the Cloud conclude that all the required security measures are in place
Due to the involvement of multiple stakeholders, there ex- as she is not an expert in the domain of Cloud security and
ists a number of threats that are specific to outsourcing data it is beyond her technical capability to verify the measures
to the Cloud. To address these threats in a structured way, our in detail. As a consequence, while she assumes her data
to be secure, one or more of the threats associated with the SensorCloud security architecture primarily has to meet
the objectives discussed above persist. Likewise, the lack the following high-level requirements.
of transparency regarding the measures used in the Cloud Data confidentiality and accountability: The data owner
platform to secure the data storage and processing may must be able to control who can access her data in- and
effectively cause the platform to be perceived by the data outside the Cloud platform.
owner as insecure as today’s Cloud platforms. As a result,
Data integrity: The data owner and Cloud services must be
the data owner would consider the overhead of the employed
able to verify that the stored data has not been manipulated.
security mechanisms as additional costs. These costs may
drive her to cheaper but less secure Cloud competitors. Service availability: The Cloud PaaS provider must ensure
that the Cloud IaaS layer is available and that Cloud services
We now give a brief overview of the principal building
are accessible.
blocks that are at our disposal in order to solve the identified
threats in a complex system such as a public Cloud platform. With respect to assurance, we assume that the IaaS
and PaaS provider ensure compliance to security standards
B. Building Blocks of a Trusted Cloud such as the Common Criteria for Information Technology
There exist three high-level instruments that support Security Evaluation (CC) or ISO/IEC 27001 by means of
the stakeholders of a Cloud system in counteracting the independent audits and certifications. These audits and cer-
threats discussed above: legal agreements, processes, and tifications allow to assure the Cloud users that the required
technology. Legal agreements allow the IaaS, PaaS, and security guarantees have been considered and met already
SaaS providers as well as the data owner to make binding since the early development processes of the Cloud platform.
statements about their service requirements and provisioned Additionally, we make the following assumption while
service properties. An often-cited example are service level addressing our high-level requirements. Within the bound-
agreements stating technical properties such as a service aries of the sensor network, we assume that data is trans-
availability of 99.999%. Furthermore, legal agreements can ferred securely to the gateway according to its sensitivity.
also refer to processes, e.g., regular certification or audits This involves confidentiality and integrity protection where
of the Cloud platform. To ensure the commitment of the necessary. Considering the gateway, we assume that its
contract partners, legal agreements commonly introduce configuration is secure and access control mechanisms are
fines when not obeying the agreed obligations. implemented properly. Additionally, the gateway is able to
Processes allow the contract partners to determine and uniquely match incoming sensor data to the corresponding
ensure that legal obligations are met. In the context of sensing device. With respect to the Cloud platform, we
a trusted Cloud platform, processes can be used by the assume that the Cloud providers themselves are not hostile.
Cloud provider to prove, e.g., that the technology applied Specifically, the IaaS and PaaS provider operate technology,
to provide security guarantees is correctly implemented and services, and interfaces as contractually agreed. Furthermore,
used. Correspondingly, processes cover the development, we assume that the IaaS cloud is reliable and cleanly
operation, and certification or audit of a Cloud platform. separates different users. Thus, other IaaS users can neither
Technology represents the foundation of a trusted Cloud influence the operation of the PaaS platform nor access data
platform. With respect to outsourcing storage and processing and services while they are processed in the PaaS. Finally, a
of sensor data to the Cloud, technology needs to provide the Cloud service that is authorized by the data owner to process
means to protect the privacy and security of sensitive sensor her data holds to its appropriation as agreed with the data
data in a multi-tenant system outside the trust domain of owner. Most importantly, the Cloud service does not hand
the data owner. The main technologies used today for this data over to an unauthorized third party.
purpose are cryptography and separation of concerns, e.g.,
A. Bridging the Sensor Network and Cloud Domains
via virtualization.
We briefly discuss the role of processes and legal agree- We reason that the gateway connecting the sensor network
ments in the following description of our Cloud security with the external network (e.g., the Internet) is the common
architecture. However, due to space restrictions, the main point of control for all data leaving the data owner’s trust
focus of this paper lies on the technological aspects of a domain. Hence, we realize our control and security mech-
trusted Cloud platform that form the underlying basis for anisms at this border of the sensor network. Specifically,
processes and legal agreements. We now proceed with the we introduce the Trust Point as a new logical entity that
description of our proposed security architecture. is situated on the gateway. It acts as a bridge between the
security domain of the sensor network and the Cloud and
III. S ENSOR C LOUD S ECURITY A RCHITECTURE performs the following three tasks. First, it forwards the
The SensorCloud security architecture emphasizes control sensor data to the Cloud platform on behalf of the data
of the data owner over her sensor data when outsourcing owner. Second, it protects the confidentiality and integrity
storage and processing to the Cloud. To enable this control, of the forwarded data during the transmission to the Cloud.
 Data Owner! Enc. Key
Data
2) Redirect, Login, Grant! Type ID

1) Login,! Data Data Data Data!

Bind! 3) Redirect,! ICS
User Management! Field Field Field Field!
Token!
Data! Keys: K0 K1 K2 K3 PKTP
Data! 4) Token!
Data Item
Cloud PaaS!
Trust Point!
Figure 3. Object security consists of encryption of individual data fields
(representing meta-data and raw data) and an integrity checksum (ICS)
Figure 2. OAuth protocol flow in SensorCloud. The data owner triggers covering the complete data item. Each data field may be encoded using
the binding procedure at the Trust Point and is redirected to the Cloud a key with a different ID and a different algorithm allowing for different
platform. She then authenticates and authorizes the Trust Point. After the confidentiality mechanisms to be used on individual data fields.
redirection to the Trust Point, a secure connection is established between
the Trust Point and the Cloud platform. B. Object Security from Trust Point to Service
Third, it applies per-data item security measures in order Transport security is terminated when sensor data is
to establish control of the data owner over her data even received in the Cloud. As a result, the transport security
after the transport protection is terminated in the Cloud. We mechanisms are stripped from the sensor data and plain data
discuss these tasks in the following sections. would reside unprotected within the Cloud platform. This
The PaaS provider offers storage resources for sensor data leaves the data stored in the Cloud open to several forms of
to the data owner. For reasons of accountability, we require attacks as discussed in Section II.
the data owner to register with the Cloud platform. As the To achieve end-to-end security from the Trust Point to
Trust Point stores data in the Cloud on behalf of the data an authorized service and during storage, the Trust Point
owner, we need to bind its identity to the data owner’s complements sensor data with additional object security
identity in the Cloud. We do not directly use the owner’s mechanisms before transmitting them securely to the Cloud.
credentials (e.g., username and password) on the Trust Point In consequence, the plain information of sensor data can
as a data owner may own several Trust Points for different neither be accessed nor modified undetectably by an unau-
sensor networks. Instead, we identify the Trust Point by thorized third party. Furthermore, the employed integrity
means of public key cryptography. To bind the data owner’s protection cryptographically ensures the accountability of
credentials to the public key of the Trust Point, we use the sensor data to a specific data owner even after stripping
OAuth protocol [12]. The data owner takes the role of the the transport security mechanisms. Our approach to ob-
OAuth resource owner, whereas the Trust Point is the client ject security is comparable to Digital Rights Management
and the Cloud PaaS represents the server (see Figure 2). (DRM) [13] when treating the Cloud service as end-user
To trigger the binding process, the data owner sets up a devices in the DRM case. However, the main difference to
secured connection with the Trust Point via TLS. The Trust our solution is that we do not require enforcement of data
Point then redirects her to the Cloud platform. However, access control on the service side.
the Cloud platform lacks an identity of the Trust Point that Typically, a data item generated by a single sensor reading
it can authorize for subsequent access, as the Trust Point comprises of multiple data fields, i.e., raw measurement
is unknown to the Cloud platform at this time. Hence, the values and meta data such as location and time. These
Trust Point encodes the fingerprint of its public key (i.e., different fields can demand for different levels of protection.
its hash digest) in the redirect of the data owner to the For example, the raw temperature readings of a private
Cloud platform. This enables the Cloud platform to store a weather station may not require confidentiality protection
mapping from the data owner’s username to the public key while sensitive meta-data such as location information does.
fingerprint of the Trust Point, if the data owner authorizes We design for this fact by supporting different protection
the Trust Point at the Cloud platform. After the authorization schemes for the different data fields of a data item (see Fig-
procedure in the Cloud platform has been completed, the ure 3). To realize fine-grained access control, individual
platform refers the data owner back to the Trust Point. protection keys can be used for different time spans (e.g.,
As a result of this second redirect, the Trust Point estab- hourly, daily, and monthly).
lishes a secure connection with the Cloud platform using In its simplest form, confidentiality protection is achieved
its public key that corresponds to the previously exchanged with symmetric key encryption such as AES. To support
fingerprint. The use of the mutual authentication variant of search and sort operations on stored data, e.g., on time
the TLS handshake in this connection establishment enables stamps, our object security design also allows the use of
the Cloud platform to verify that the Trust Point has been deterministic and order-preserving encryption [14], [15].
correctly bound and authorized by the data owner before. Likewise, it supports the use of efficient forms of homomor-
Only then the Cloud platform accepts sensor data forwarded phic encryption for selected operations on encrypted data
by this Trust Point. (e.g., sum or average) [14].
 Data Owner!
! Service Public
Signature
Service Service
Description Key
1) Lo
ok-up
SEE SEE SEE
Cloud Service!
Marketplace!
Data!
VM VM VM
3) Store Encryption!
Data! Key-store!
Cloud PaaS!
IaaS Infrastructure
Trust Point!
Figure 5. Multi-layer tenant separation by Secure Execution Environment
Figure 4. Service authorization by the data owner. The data owner looks up (SEE) in the Cloud PaaS layer (dashed line) and by Virtual Machines (VMs)
a service and its service description in the Cloud Service Marketplace. She in the Cloud IaaS layer (solid line).
then instructs her Trust Point to encrypt her data for the selected service.
The Trust Point stores the encryption keys for this service in the encryption depicted in Figure 5. The SEEs are the only place where
key-store. data items are unencrypted inside the Cloud platform. They
Integrity protection in SensorCloud is based on asymmet- ensure that services are not able to leave their SEE or
ric key cryptography. Specifically, the Trust Point signs each interfere with services in other SEEs.
data item with its private key. Hence, while object encryption One requirement for our SEE design is that the platform
is performed on data fields, integrity protection spans the guarantees tenant separation while scaling the number of
complete data item. services in a wide range. Typically, individual services for
C. Service Assurance and Data Access Granting a few thousand data owners will be served from separate
SEEs on the same physical machine. Likewise, the joined
The object security mechanisms employed in SensorCloud
computing power of many physical machines will be re-
prevent access to the data owner’s data items in the Cloud.
quired if services operate on huge amounts of data from
Thus, she needs to authorize services if she wants them to
various data owners.
process her data. To enable the data owner to perform an in-
formed decision regarding which service to authorize, Cloud Tenant separation relying purely on virtualization at the
services provide a service description about themselves (e.g., IaaS layer does not achieve this scalability. Due to memory
in a Cloud service market-place) as depicted in Figure 4. restrictions, typical hypervisors can execute some tenth of
This description contains high-level information about the virtual machines (VMs) on the same physical hardware.
kind of data it operates on and the purpose of the service. When the same application is run in parallel, aggressive
The conformance of the service to the service description memory sharing can be used to reduce the memory overhead
must be verified by the Cloud provider or a trusted third of each VM. However, even then the total number of
party before approving the service to the Cloud platform VMs on the same physical hardware is limited to a few
similar to current practices on the smart phone market. If the hundreds [17]. Thus, implementing the SEE as a VM and
data owner agrees with the service description, she needs to having one VM per service is not feasible for a scenario
provide the encryption keys used for the protection of the with several thousand instances. Hence, the SEEs need to
data fields that she wants to share. This is done by instructing be implemented by our SensorCloud platform on top of
the Trust Point to encrypt the respective encryption keys with an operating system running on instances (typically VMs)
the public key of the service and to transmit this secured offered by the IaaS. We still rely on tenant separation by
information to the encryption key store located in the Cloud. the computing part of the IaaS to isolate the SensorCloud
The required public key of the service is provided as a part PaaS provider from other IaaS users. Technically, this can be
of the service description. Authorized services request the realized with a trusted hypervisor or simply by a process that
encryption keys from the key store and decrypt them with only deploys VMs of the SensorCloud PaaS provider on the
their private keys. Similarly, new keys for all authorized same physical hardware. The PaaS provider should ensure
services are pushed to the key store by the Trust Point the adherence of the IaaS provider to this requirement, e.g.,
whenever the encryption keys change. via regular audits required by legal agreements. As data
in transit and storage is protected by the object security
D. Multi-layer Tenancy Separation mechanisms, there are no specific separation requirements
The transport and object-based encryption mechanisms for the storage and networking subsystems of the IaaS layer.
ensure separation of sensor data from multiple tenants during Because implementing SEEs as VMs is not feasible in our
transmission and storage. As the run-time context of a scenario, we have to look for a more fine-grained approach.
service contains sensitive information (e.g., decryption keys Given Java as a language for service development on the
and the data owner’s decrypted sensor data), encryption does platform, one option would be to leave tenant separation to
not suffice to separate the tenant data during processing [16]. the Java VM (JVM) layer. However, neither typical JVMs
Thus, our platform isolates different tenants securely and by nor Java EE application servers guarantee separation of
default in secure Service Execution Environments (SEE), as executed applications. Security and isolation weaknesses
of JVMs were investigated, e.g., within the context of 106
200
OSGi [18]. Recent research projects like I-JVM [19] are
addressing these issues and are promising approaches for 105

Data Items / sec

Data Items / sec

150
the future. However, we believe that currently the kernel
104
and the operating system are the best means for enforcing
tenant separation. Hence, our design is based on a multitude 100
103
of JVMs running in parallel in isolated containers as dif- 1 Service p = 1
ferent system processes for different tenants. The containers 50 10 Services 102 p = 0.1
guarantee access to and oversee usage of system resources 50 Services p = 0.01
100 Services p = 0.001
such as CPU, memory, and I/O. They can be implemented 101
0
as BSD jails or Linux control groups. 0 2 4 6 8 10 0 2 4 6 8 10
To enforce the usage of object security mechanisms by Key Change Interval (sec) Key Change Interval (sec)
services, a dedicated object I/O API for services is defined in (a) Gateway performance (b) Cloud service performance
the SEE while forbidding any other network and storage I/O.
Furthermore, the decryption of incoming and the encryption Figure 6. The left figure shows the data throughput of the gateway
depending on the number of authorized services and the key change interval.
of outgoing data is provided as an (open source) library In the right figure, the performance of a Cloud service depending on the
functionality that is used within the run-time context of integrity validation probability p and the key change interval is shown.
the actual service. This architecture eases the development
the ECDSA scheme with NIST curve P-224. Finally, the
of secure services as it relieves the programmer from the
Trust Point encrypts data encryption keys with RSA using
burden of manual key and encryption handling.
2048 bit keys as RSA provides us with an advantageous
IV. E VALUATION performance asymmetry for public-key operations. However,
For the performance estimation of our design, we imple- future revisions of our architecture may replace RSA by
mented a basic prototype that consists of a Trust Point and elliptic curve encryption mechanisms such as ECIES.
a Cloud platform. The Trust Point is a Linksys WRT160nl Performance overhead: The performance overhead of the
commodity router with 400 MHz that runs the Linux- transport security mechanisms employed in SensorCloud
based operating system OpenWRT. To allow for independent have been well studied [21]. Hence, we focus our evalu-
verification of our results, we use the Amazon EC2 IaaS ation on the object security mechanisms of SensorCloud.
platform with 64-bit instances of type large and Ubuntu Our object security mechanisms introduces a computational
12.04 as the operating system for our Cloud measurements. overhead on both the Trust Point and the Cloud platform.
Note that Amazon EC2 currently does not guarantee the This overhead is introduced by the per-data field encryption
desired level of user isolation. However, it can be achieved and the per-data item integrity protection at the Trust Point.
in our early IaaS prototype based on OpenStack by using Likewise, services must decrypt encrypted data fields before
corresponding policies for the filter scheduler. processing them and may need to verify the integrity of
Regarding the Trust Point-based architecture, Sensor- stored data upon look-up. Moreover, the Trust Point changes
Cloud involves performance trade-offs with respect to com- the encryption keys periodically based on the desired granu-
putations and storage. Furthermore, the multi-layer tenancy larity of the data access control. Accordingly, services need
separation at the Service Execution Environment-level re- to decrypt the data encryption keys with their private key
quires additional memory resources compared to pure vir- after each key change. The performance estimates of these
tualization on the IaaS layer. We now quantify and analyze operations are based on the OpenSSL implementation.
these overheads. The results indicate that already at an access granularity
Choice of cryptographic primitives: For our evaluation, we of 2 seconds, our low-end Trust Point can process about
chose cryptographic primitives with at least 112 bit security 160 data items per second if 50 services are authorized to
providing data security up to the year 2030 according to access these items (see star in Figure 6(a)). Only access
NIST [20]. Furthermore, our cipher choice was guided by granularities in the order of several hundred milliseconds
the aim to lower the computational burden on the Trust (see Figure 6(a) with a key change interval close to 0 sec-
Point. The Trust Point constantly performs three types of onds) are infeasible. To bring these numbers into perspective,
cryptographic operations: i) per-data field encryption, ii) per- assume a per-sensor sampling rate of 1 measurement per
data item signing, and iii) per-authorized service encryption second. In this case, the SensorCloud security architecture
of data encryption keys. For the data field encryption, we allows a low-end Trust Point to protect sensor data for over
use AES with 128 bit keys in CBC mode. Unless specified 150 nodes. If higher sampling rates or larger network sizes
otherwise, we restrict our analysis to sensor data with a need to be supported, the hardware of the Trust Point can
single data field, as the AES operations only represent a easily be scaled up or hardware support for the cryptographic
marginal overhead in our system. For signatures, we use algorithms could be added in order to achieve throughputs
 250 Key Change Interval
plain
1 second 1 minute 1 hour 1 day 1 week 1 month
encryption
200
integrity
Size (bytes)

Data Fields
1 4.33GB 0.07GB 1.23MB 0.05MB 7.50KB 1.75KB
150
5 21.63GB 0.36GB 6.15MB 0.26MB 37.50KB 8.75KB
100 10 43.26GB 0.72GB 12.30MB 0.51MB 75.00KB 17.50KB

50
Table I
0 K EY S TORAGE OVERHEAD
1 2 3 4 5 6 7 8 9 10
Number Data Fields
Figure 7. The storage overhead of the object security mechanism for each
the pure overhead of the cryptographic ciphers and assume
data item stays constant for an increasing number of data fields. data fields that fit into a single 16 byte block. The specific
storage overhead strongly depends on the exact encoding of
that are 1 − 2 orders of magnitude higher. Specifically, the data fields and their respective information.
the calculation of the data integrity mechanism denotes the The calculated storage overhead of our proposed object
limiting factor of the sensor data processing at the Trust security mechanism is shown in Figure 7. The overhead
Point. Modern multi-core CPUs allow to perform these cal- consists of a 16 byte initialization vector per-data item for
culations in parallel and at higher core speeds compared to the data field encryption and a 64 byte integrity protection
a commodity router. Moreover, the number of data fields per checksum. The encryption of the individual data fields does
data item only have a marginal influence on the maximum not add further overhead. Consequently, the cryptographic
throughput of the Trust Point as symmetric encryption can storage overhead of each data item is constant and amounts
be computed efficiently at 0.004 ms per data field. Hence, to 80 byte in addition to the actual sensor data. This overhead
the SensorCloud security architecture also scales well with is well manageable with the elastic storage resources of
an increasing number of data fields. today’s Cloud offers.
A Cloud service may either access a live stream of a The Cloud platform securely stores the encryption keys
specific sensor or process sensor data that is stored in of protected data items in its dedicated key store for each
the Cloud (e.g., for services based on histories of sensor service that is authorized to access a data item. Hence,
data). A service may likewise aggregate data from multiple the encryption key storage overhead in the Cloud strongly
sensors. Our results suggest that a service can process about depends on the key granularity as well as the number of
1000 data items per second if it verifies the integrity of connected sensors and services that are authorized to access
all items (see Figure 6(b) for p = 1). This throughput the data of the sensor. Tab. I depicts the calculated per-
suffices for small-scale services that operate on live data. sensor storage overhead for different key granularities for
However, large-scale services that aggregate data from multi- one month worth of sensor data. Similar to the processing
ple sensors require higher throughputs. Data throughput can overhead of the employed object security mechanisms at the
be increased considerably, if the Cloud provider is trusted Trust Point, the key storage overhead approaches practical
to a large extend. In this case, a Cloud service may only sizes with decreasing data access granularities, e.g., 70 MB
need to verify the data integrity for a random sample. For at a per minute granularity for each data field. Note that
example, the data throughput increases to about 9900 or old sensor data may be stale or may not have the same
96300 if the service randomly validates the integrity of informational value for the data owner or her authorized
p = 0.1 or p = 0.01 of the processed items respectively. services when compared to recently collected data. Hence,
In contrast, if deterministic verification is required for an the data owner may delete or aggregate old data in order to
untrusted Cloud storage provider, the data owner may use decrease the total storage overhead in the Cloud with respect
a dedicated third-party service that runs in the background to sensor data, object security, and encryption key storage.
and continuously verifies the data integrity. This allows for We conclude that the storage overhead of SensorCloud is
a continuous data integrity verification without the need to well manageable by the elastic storage capabilities provided
download the sensor data from the Cloud. Overall, the results by a Cloud platform.
show that the performance of our design scales as intended SEE memory overhead: We developed an early SEE pro-
for our scenario. totype for the evaluation of the memory overhead for the
Storage overhead: We distinguish two kinds of storage service isolation. An SEE consists of a dedicated OpenJDK
overhead in our evaluation. The first type of overhead is JVM that is executed inside an application-level Linux
generated by the object security mechanisms themselves, Secure Container (LXC). LXC guarantees secure isolation of
i.e., sensor data encryption and integrity protection. The the processes (i.e., the JVMs) and allows to define quotas for
second type results from the encryption key storage in the processing, memory, and I/O usage. As we are interested in
Cloud. We restrict our estimation of the storage overhead to the memory overhead of the SEE itself, we used a minimal
test service written in Java for our evaluation. The memory The field of secure data querying focuses on retrieving
consumed by one SEE instance and the test service together encrypted data in a structured way in order to allow, e.g.,
amounts to roughly 7 MB. Consequently, we were able to range queries or keyword searches [14], [24], [15]. In
launch more than 1000 SEEs in parallel on one EC2 large contrast, secure computations allow for direct computations
instance with 7.5 GB of RAM. As IaaS environments like on encrypted data. A prominent example of the latter cryp-
Amazon provide instances with up to about 70 GB of RAM, tographic primitive is (fully) homomorphic encryption [6],
we can safely assume that we can run more than 10,000 [14]. However, especially fully homomorphic encryption still
SEEs with different services at the desired level of separation is highly inefficient regarding the computational overhead
on a single physical machine. and key sizes [7]. As described in Section III-B, our flex-
ible design of data object security mechanisms allows to
V. R ELATED W ORK incorporate efficient approaches for querying and processing
For our discussion of related work, we distinguish the encrypted data.
following three research directions: i) architectures involving A number of other related approaches to secure Cloud
a trusted third-party, ii) secure operations on outsourced data, computing have been proposed in the past. They either build
and iii) other related approaches to secure Cloud computing. on the fundamental idea of using trusted hardware com-
Architectures utilizing a trusted third-party similar to our ponents in Cloud environments [27], [4] or of performing
Trust Point have been proposed in a wide range of scenarios. data processing locally. However, TPM-based approaches
In the context of Wi-Fi-sharing communities, a trusted require hardware support by the IaaS layer, whereas the
relay can be used to mitigate security, privacy, and legal IaaS requirements of our architecture can be implemented at
issues [22]. However, such data flow-focused approaches the management level. Furthermore, the binding of trusted
typically restrict themselves to the use of transport security components to specific hardware makes the migration of
and do not consider the object security that is necessary in virtual instances across multiple hardware platforms chal-
our scenario. To guarantee privacy in intelligent energy net- lenging [5]. When performing data processing locally, the
works in Germany, a trusted gateway has been specified [23]. Cloud is merely used as a storage device [24], [11] and
Although our security architecture shows similarities to computations are done outside the Cloud within the trusted
this approach, its PKI-based approach does not allow for domain of the data owner [7]. In contrast to our approach,
similarly fine-granular access control on sensor data. these solutions do not take advantage from the elastic
A number of architectures involving a trusted third-party computational resources that are offered by the Cloud.
have been proposed in the context of Cloud computing.
Kamara et al. [24] propose an architecture that resembles VI. C ONCLUSION
ours with respect to fact that a trusted gateway encrypts
outbound data and manages access policies. However, the When outsourcing storage and processing of sensor data
authors do not consider the secure computation of data by to the Cloud, multiple possibly unknown or untrusted stake-
Cloud services and require the data consumer to request holders become involved. In this paper, we identified the
access tokens from the gateway. Hence, their approach specific threats that arise from this uncertain involvement.
does not consider the necessary Cloud service isolation. Our proposed SensorCloud security architecture counters
Furthermore, data stored in the Cloud becomes unavailable these threats by allowing the data owner to stay in control
if the gateway is offline. The Twin Clouds architecture [25] over her data even in a Cloud scenario. To this end, we
uses Garbled Circuits to encrypt both outsourced data and introduce a Trust Point as a new logical entity that is
programs in a trusted (private) Cloud. After this demanding located at the border of the sensor network and acts as a
per-data item setup phase, computations can be performed bridge between the security domain of the sensor network
on an untrusted public Cloud platform. However, encrypted and the Cloud. The Trust Point i) implements transport
programs only perform simple operations and need to be security mechanisms for communication with the Cloud,
re-encrypted after each execution. Similar to our security ii) applies object security mechanisms to outbound data
architecture, Pearson et al. [26] introduce a Cloud design that items, and iii) performs key management for authorized
focuses on fine-grained access control for outsourced data services. To mitigate leakage of sensitive information from
by the data owner. However, while their approach focuses the run-time contexts of services, we additionally propose
on sticky policies that are enforced by an external trust the use of isolation mechanisms all the way up to the service-
authority, our contribution includes the introduction of the level. Our evaluation shows that our proposed SensorCloud
Trust Point and its binding with the Cloud, a flexible design security architecture has an adequate performance for the
for object security on sensor data, and the incorporation of intended scenario and that the involved storage and memory
isolation mechanisms in the Cloud at the service-level. overheads can be handled effectively. This makes the user-
Secure operations on outsourced data can further be controlled storage and processing of sensor data a promising
classified into secure data querying and secure computations. extension of today’s Cloud offers.
 ACKNOWLEDGMENT [13] E. Becker, W. Buhse, D. Günnewig, and N. Rump, Eds.,
Digital Rights Management. Springer, 2003.
The authors would like to thank the members of the
SensorCloud consortium for the inspiring discussions on the [14] R. A. Popa, C. M. S. Redfield, N. Zeldovich, and H. Balakr-
concepts described in this paper. The SensorCloud project ishnan, “CryptDB: Protecting Confidentiality with Encrypted
is funded by the german Federal Ministry of Economics Query Processing,” in Proc. ACM SOSP, 2011.
and Technology under the project funding reference number
[15] D. Boneh and B. Waters, “Conjunctive, Subset, and Range
01MD11049. The responsibility for the content of this Queries on Encrypted Data,” in Proc. TCC, 2007, LNCS
publication lies with the authors. 4392.
R EFERENCES [16] M. Van Dijk and A. Juels, “On the Impossibility of Cryp-
[1] I. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, tography Alone for Privacy-Preserving Cloud Computing,” in
“A Survey on Sensor Networks,” IEEE Comm. Mag., vol. 40, Proc. USENIX HotSec, 2010.
no. 8, 2002.
[17] L. Martignoni, P. Poosankam, M. Zaharia, J. Han, S. McCa-
[2] S. Pearson and A. Benameur, “Privacy, Security and Trust mant, D. Song, V. Paxson, A. Perrig, S. Shenker, and I. Stoica,
Issues Arising from Cloud Computing,” in Proc. IEEE Cloud- “Cloud Terminal: Secure Access to Sensitive Applications
Com, 2010. from Untrusted Systems,” in Proc. USENIX ATC, 2012.

[3] R. Chow, P. Golle, M. Jakobsson, E. Shi, J. Staddon, R. Ma- [18] P. Parrend and S. Frenot, “Security benchmarks of OSGi
suoka, and J. Molina, “Controlling Data in the Cloud: Out- platforms: toward Hardened OSGi,” Softw: Pract. Exper,
sourcing Computation without Outsourcing Control,” in Proc. vol. 39, 2009.
ACM CCSW, 2009.
[19] N. Geoffray, G. Thomas, G. Muller, P. Parrend, S. Frénot, and
[4] N. Santos, K. P. Gummadi, and R. Rodrigues, “Towards B. Folliot, “I-JVM: a Java Virtual Machine for Component
Trusted Cloud Computing,” in Proc. USENIX HotCloud, Isolation in OSGi,” in Proc. IEEE/IFIP DSN, 2009.
2009.
[20] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid,
[5] D. Wallom, M. Turilli, G. Taylor, N. Hargreaves, A. Mar- “Recommendation for Key Management – Part 1: General
tin, A. Raun, and A. McMoran, “myTrustedCloud: Trusted (Revision 3),” NIST Special Publication 800-57, National
Cloud Infrastructure for Security-critical Computation and Institute of Standards and Technology, 2012.
Data Managment,” in Proc. IEEE CloudCom, 2011.
[21] C. Coarfa, P. Druschel, and D. S. Wallach, “Performance
[6] C. Gentry, “Computing Arbitrary Functions of Encrypted Analysis of TLS Web servers,” ACM Trans. Comput. Syst.,
Data,” Commun. ACM, vol. 53, no. 3, 2010. vol. 24, no. 1, 2006.

[7] G. Danezis and B. Livshits, “Towards Ensuring Client-Side [22] T. Heer, T. Jansen, R. Hummen, S. Götz, H. Wirtz, E. We-
Computational Integrity,” in Proc. ACM CCSW, 2011. ingärtner, and K. Wehrle, “PiSA-SA: Municipal Wi-Fi Based
on Wi-Fi Sharing,” in Proc. ICCCN, 2010.
[8] G. Stoneburner, “Underlying Technical Models for Informa-
tion Technology Security,” NIST Special Publication 800-33, [23] “Protection Profile for the Gateway of a Smart Metering Sys-
National Institute of Standards and Technology, 2001. tem,” v01.01.01(final draft), Federal Office for Information
Security, Germany, 2011.
[9] M. Jensen, J. Schwenk, N. Gruschka, and L. Iacono, “On
Technical Security Issues in Cloud Computing,” in Proc. [24] S. Kamara and K. Lauter, “Cryptographic Cloud Storage,” in
IEEE CLOUD, 2009. Proc. RLCPS, 2010, LNCS 6054.

[10] T. Ristenpart, E. Tromer, H. Shacham, and S. Savage, “Hey, [25] S. Bugiel, S. Nürnberger, A.-R. Sadeghi, and T. Schneider,
You, Get Off of My Cloud: Exploring Information Leakage “Twin Clouds: Secure Cloud Computing with Low Latency,”
in Third-Party Compute Clouds,” in Proc. CCS, 2009. in Proc. IFIP CMS, 2011, LNCS 7025.

[11] K. D. Bowers, A. Juels, and A. Oprea, “HAIL: A High- [26] S. Pearson, M. Mont, L. Chen, and A. Reed, “End-to-End
Availability and Integrity Layer for Cloud Storage,” in Proc. Policy-Based Encryption and Management of Data in the
ACM CCS, 2009. Cloud,” in Proc. IEEE CloudCom, 2011.

[12] E. Hammer-Lahav, “The OAuth 1.0 Protocol,” RFC 5849 [27] W. Itani, A. Kayssi, and A. Chehab, “Privacy as a Service:
(Informational), IETF, 2010. Privacy-Aware Data Storage and Processing in Cloud Com-
puting Architectures,” in Proc. IEEE DASC, 2009.