You will be presented with the full text of a science research paper. Please write an abstract for this paper. Your response should include the abstract and no additional text.

Paper text:
recent advances in ubiquitous computing and wireless sensor networks continue to obliterate the boundaries between the physical and the digital world  @xcite .
sensor networks can be utilized in a large variety of deployments , ranging from personal homes over offices and cars to industrial facilities and public areas  @xcite . to cope with the resulting increase in demands for storing and processing sensor data , cloud computing elastically
provides the necessary computation and storage resources  @xcite .
cloud computing allows the collection , processing , and storage of sensor data at large scales and as well enables the world - wide sharing of said data  @xcite . in the context of the sensorcloud project  @xcite
, we consider a scenario in which operators of sensor networks ( i.e. , private users , companies , or public institutions ) connect their sensor networks to the cloud  @xcite , where collected sensor data is processed by cloud services selected by the sensor network operator  @xcite . besides the remarkable advantages of cloud computing , it is important to note that sensor data often contains sensitive information .
hence , when transferring this sensitive data to entities outside of trusted sensor networks , it might , e.g. , be unintentionally forwarded to third parties or used for non - authorized purposes  @xcite .
furthermore , data stored and processed in the cloud might be subject to access by the cloud provider or governmental agencies  @xcite .
thus , one major challenge when interconnecting sensor networks with the cloud is to account for the aforementioned security and privacy concerns .    as part of the efforts of the sensorcloud project
, we developed a trust point - based security architecture for outsourcing sensor data to the cloud and the sensorcloud security library  @xcite .
one important challenge in securely outsourcing sensor data to the cloud lies in the representation of sensor data and the corresponding security measures taken to protect the sensor data . in this paper
, we report on the sensorcloud protocol , which has jointly been developed within the sensorcloud project to represent sensor data and actuator commands using json and subsequently secure this data using object security mechanisms . to this end
, we rely on mechanisms that have been or currently are in the process of being standardized at the ietf and provide a best practice on how to utilize and combine them in an actual system .    the remainder of this document is structured as follows . in section  [ sec : scenario ] , we present the sensorcloud scenario in more detail and provide references to more detailed descriptions of the overall security architecture . section  [ sec : json - representation ] defines the json - based representation of sensor data and actuator commands in sensorcloud . in section  [ sec : security - extensions ] , we describe the security extensions to this representation to realize the secure outsourcing of sensor data to the cloud .
we conclude this paper in section  [ sec : conclusion ] .
in sensorcloud , we consider a scenario where each sensor network ( with an arbitrary number of sensor nodes ) is connected to the cloud via a dedicated gateway as depicted in figure  [ fig : scenario ] .
our goal is to store data securely in the cloud such that it can only be processed by authorized cloud services . to this end , the gateway encrypts sensitive sensor readings using a symmetric cipher before uploading it to the cloud .
the encryption process is influenced by a user - configurable access control list containing services that are authorized to ( partially ) obtain and process the user s sensor data .
now , only entities in possession of the symmetric key used for encrypting a piece of sensor data ( referred to as a data item ) have access to this specific data item .
hence , to grant a cloud service access to a given data item the gateway has to provide this cloud service with the corresponding key .
to this end , the gateway asymmetrically encrypts the corresponding symmetric key with the public key of the cloud service that should gain access to the sensor data and forwards the resulting encrypted key to the respective cloud service .
more details , especially with respect to the design and implementation of the underlying security architecture as well as our choice of cryptographic primitives , can be found in the corresponding publications  @xcite .
notably , sensor data originating from a single ( possibly virtual ) sensor node can contain multiple sensor readings from different sensors .
for example , one data item measured by a meteorological sensor might consist of multiple single sensor readings such as humidity and temperature .
hence , sensorcloud supports the transmission of multiple sensor readings of one sensor node in a single message  @xcite . as a cloud service
might only be granted access to parts of the sensor readings , sensorcloud supports the encryption of individual parts of sensor data , thus realizing fine - grained access control .
the processing of sensor data by a cloud service requires the verification of the integrity of received data , the decryption of the symmetric key , and finally the decryption of the actual sensor data .
these operations have been implemented in the sensorcloud security library , which allows the transparent decryption of sensor data and the verification of its integrity by a cloud service  @xcite .
it is available as open source software under the mit license .
the remainder of this document defines the json - based messages used by the sensorcloud protocol to encode data items as well as additional configuration messages .
more precisely , the json - based message layout defined by this document is used for both internal communication within the gateway and cloud , respectively , and for communication between those entities .
the field ` ver ` contains the version number of the protocol , which defines the structure of the remainder of the message .
hence , whenever the message structure or encapsulated payloads are subject to changes , the version number must be increased .
the receiving peer must support the indicated version number . otherwise , it should notify the sending peer that the message was dropped .
the version number is a positive integer and is currently defined as ` 1 ` .
the sequence number ` seq ` is currently unused and must therefore be set to ` 0 ` .
however , it enables end - to - end acknowledgments at the application layer .
the corresponding retransmission mechanism will need to be developed in the future .
if used , ` seq ` is a positive integer that must be increased by one for each json message header sent . a potential wrap - around of
the sequence number is to be expected and implementations must interpret this case as an incrementation of the sequence number .
the messages to be transmitted using one header are stored within an array in the field ` pl ` .
section  [ sec : payload - types ] defines a list of message types supported by sensorcloud .
additional message types can be defined as necessary .
messages must contain the field ` typ ` to indicate their message type for message processing purposes .
moreover , they must include the ` gw ` field to indicate the gateway device that participates in the communication . among other aspects ,
this information is required for applying object security measures .
note that multiple messages of different types can be batched using one message header in order to reduce the overall communication overhead .
each message indicates its message type via the field ` typ ` , which must be included in any message .
the message type is a positive integer value and can currently take one of the values described in table  [ tab : msg - types ] .
the increasing deployment of sensor networks , ranging from home networks to industrial automation , leads to a similarly growing demand for storing and processing the collected sensor data . to satisfy this demand , the most promising approach to date 
 is the utilization of the dynamically scalable , on - demand resources made available via the cloud computing paradigm . 
 however , prevalent security and privacy concerns are a huge obstacle for the outsourcing of sensor data to the cloud . 
 hence , sensor data needs to be secured properly before it can be outsourced to the cloud .    
 when securing the outsourcing of sensor data to the cloud , one important challenge lies in the representation of sensor data and the choice of security measures applied to it . in this paper 
 , we present the sensorcloud protocol , which enables the representation of sensor data and actuator commands using json as well as the encoding of the object security mechanisms applied to a given sensor data item . 
 notably , we solely utilize mechanisms that have been or currently are in the process of being standardized at the ietf to aid the wide applicability of our approach .