Use of MPEG-21 for Security and Authentication in Biomedical Sensor Networks Wolfgang Leister and Truls Fretland Norsk Regnesentral Oslo, Norway email: {wolfgang.leister, truls.fretland}@nr.no
ABSTRACT Privacy and security are two major concerns in the ubiquitous deployment of wireless patient monitoring systems. Wireless sensor networks become an integral part of the monitoring process, where wireless sensors can enter or leave the monitoring situation randomly. As a tool to handle threats that may arise by the use of wireless sensors, we propose a new framework using MPEG-21. MPEG-21 is an architecture that can handle end-to-end management of content and network resources. In this paper we evaluate the use of the MPEG-21 architecture in a resource-constraint wireless sensor network, where different threats are evaluated and countermeasures are proposed. KEY WORDS MPEG-21, security, biomedical sensor networks, medical digital item
1
Introduction
Wireless technology has been increasingly used in healthcare to eliminate the use of cables in patient monitoring systems, giving advantages for patients and medical personnel. However, wireless communication can be intercepted easily. Threats to security goals like confidentiality, integrity, and availability of data may apply, and possible weaknesses in a system treating healthcare data could be exploited by potential attackers. Regulations for handling healthcare data are strict in most parts of the world. This is manifested by the relevant legislation in Norway [1] and the European Union [2]. Especially the issues of privacy and data integrity are stated in these documents. The security issues of wireless sensor networks (WSN) have become a highly relevant research topic. We base parts of our work on an overview of security goals, threats, attacks and countermeasures on all communication layers [3]. Biomedical sensor networks (BSN) can be considered as WSN with specific constraints regarding operational and
Ilangko Balasingham Interventional Center Rikshospitalet University Hospital Oslo, Norway email:
[email protected]
Figure 1. Generic system model from [8] with Channel A shown in detail.
security requirements. MPEG-21 [4, 5] provides a multimedia framework at the application level to enable transparent and augmented use of multimedia resources across a wide range of networks and devices. MPEG-21 addresses sharing and transferring digital media content, including management, adaptation of resources, protection of privacy, integrity, and digital rights. The contribution of this paper is a novel approach to secure the application layer of medical data in wireless biomedical sensor networks. While the approach of using MPEG-21 in healthcare has been proposed before [6, 7], we restrict our work to applying MPEG-21 for increasing security on wireless biomedical sensor networks. The paper is organised as follows: Section 2 gives an overview of security issues for wireless patient monitoring systems and biomedical sensor networks. Section 3 reviews the relevant parts of MPEG-21. We present our architecture in Section 4, and discuss it in Section 5 before concluding the paper.
2
Patient Monitoring Systems
Wireless patient monitoring systems and biomedical sensor networks can be applied in a variety of healthcare scenarios in a range of paramedic, diagnostic, surgical, and post-operative phases. Previously, we have developed and analysed a generic system model for the overall patient
monitoring system [8] identifying the components and communication channels. In this generic system model, shown in Figure 1, the patient data are generated by sensors attached to a patient. A biomedical sensor network consists of several sensor nodes. Data are sent over a wireless network (Channel A) to the sink of the wireless network, and to the patient data collector (PDC). The PDC collects different data streams for a patient, and forwards data to the healthcare information system at the hospital (Channel B), or to the patient data accessing unit giving data access to the medical staff on site (Channel E). Note that an ID data mapper functionality (Channel G) is necessary to handle patients where the identity might not be known, and that there is no real communication flow involved. Retrieval of patient data from the healthcare information system involves Channel D. Our main focus will be on Channel A, the sensors, and the PDC. The other channels and components are beyond the scope of this paper.
2.1
Biomedical sensor nodes work autonomously and have limited processing and transmission capabilities. These constraints include very limited resources (limited CPU speed, memory, storage space, and power limitation), unreliable communication (unreliable transfer, conflicts, latency), and unattended operation (exposure to physical attacks, remote management, no central management point) [3]. Note that several of the security considerations of a general WSN are not applicable to BSN. Especially, the unattended operation constraint does not apply for a BSN, since the sensors will be attached to patients that are conscious or supervised by healthcare personnel. Due to the wireless aspect of sensor networks it may become easy to eavesdrop on traffic, inject new messages, alter or replay previous messages, or apply other attacks.
2.3
We discuss the most relevant security requirements for BSN [3, 8], and identify where in the communication layers measures against possible threats and attacks can be placed. Security measures are usually placed in the presentation layer. In a BSN we consider the Dolev-Yao threat model [9], where the attacker can overhear, intercept, and synthesise any message, and is only limited by the constraints of the cryptographic methods used. While the source, and the sink are supposed to be trusted, Channel A, including possible transport nodes could be in the control of the attacker. The possible intrusion by an Dolev-Yao attacker implies that the existence of transfer nodes must be considered, also in a one-hop environment. A potential attacker could provide an extra node without anybody knowing about it. Data confidentiality and privacy are related. A standard approach to achieve data confidentiality is to encrypt data with a key, so that only the intended receiver, in our case the sink node or PDC, can understand these data. Since transfer nodes might be involved in the communication the protection must be applied in the transport layer, or above. Even if the sensor data are encrypted, the sensor encryption is lightweight and can be broken given sufficient time and resources. Hence, the data sent from the sensor to the PDC should not contain person-identifiable data such as a social security number. Instead, the sensor data should be linked to the corresponding person in the PDC, by using timestamp, node and stream identifier (authentication data) from the sensor and knowledge about which sensor is attached to which person. Person-identifiable data may be included at the PDC, since it has more resources available, and can implement stronger encryption algorithms and/or longer keys. Data integrity requires that the received data has not been tampered with or destroyed, and violations of this must
Biomedical data
While the healthcare information system must handle all types of medical data, we concentrate on medical data typically produced by BSN. The sensor nodes measure biomedical signals, process them and transmit the results to a sink node. Typical biomedical data measured by biomedical sensors can be electrocardiogram (ECG), electroencephalography (EEG), blood oxygen saturation, blood pressure, temperature, and sound1 . Most of these consist of data samples at a given sampling resolution and sampling rate with typical data rates from some few bits per second (bps) up to 12000 bps. The sampling rate and resolution are examples of biomedical metadata, that is, data that contain information about the biomedical measurements. The nature of biomedical data describes streamed multimedia data with corresponding requirements about confidentiality, integrity, availability, as well as service quality and adaptation.
2.2
BSN Security Requirements
Biomedical Sensor Networks
A BSN comprises of one or several sensor nodes, possibly several transfer nodes, and one or more sink nodes which are attached to the PDC. The communication from the sensor to the sink cannot be trusted since the transfer nodes, and wireless transmission in general cannot be trusted. We assume that the sensor itself is authenticated, that the sink node is assumed not to be compromised, and that the hospital infrastructure can be trusted. 1 Other types of sensor data include images and image sequences (video).
2
be detectable. This is also a fundamental requirement in order to provide data authenticity. Data authenticity ensures that the sensor data are linked to the correct patient. Note that linking data to the wrong patient could lead to wrong diagnosis and eventually mistreating the patient. An adversary shall not be able to inject data packets without these being detected. Also re-played data packets must be detected (data freshness). Note, that in some cases characteristics of routing and forwarding make it necessary to detect duplicate arriving packets. Therefore, duplicate packets must be detectable on the network layer or above by using counters or other identifying data. On the network layer attacks to WSN include attacks to routing and forwarding. On the upper network layers such attacks are recognisable by missing, defect, manipulated, duplicated, or delayed packets. While these attacks can be detected they cannot be prevented on the application layer. We assume that deploying a sensor, key distribution, assigning an identity to a sensor, and coupling the sensor node to a patient identity is done in a routine ahead of the normal operation of the sensor network; trusted medical personnel performs this operation, e.g., by coupling the sink and the sensor node. The sink node has rather large computation and communication properties in order to perform data aggregation, validity check, identity assignment, etc. Transfer nodes are not supposed to perform these tasks, and hence do not need keys to decrypt sensor data. In contrast to a general wireless sensor, the biomedical sensors are in a rather controlled environment, so that we do not consider destruction or tampering with the sensors. Possible revelation of keys shall only have the consequence that only the stream from the tampered node is affected without consequences for the rest of the network.
3
erences), and metadata that describe these resources. Attempts have been made to adapt the DI to the healthcare sector as medical digital item (MDI) [6]. To identify a DI, Part 3, Digital Item Identification (DII), offers a shell where users can choose their own relevant identifier regime, for example patient identity or sensor identity. A protected form of the DI is provided by the intellectual property management and protection (IPMP) components in Part 4 of MPEG-21. Parts of a DI can be encrypted and digitally signed, and hence confidentiality, authenticity and integrity of patient data can be provided assuming that the system (keys, protocols, algorithms) is secure. However, the specific tools to encrypt are not provided by the standard, and must therefore be implemented by the application or middleware components. Expressing the digital rights, i.e., the rights to access specific data under given circumstances, is governed by Parts 5 and 6 of MPEG-21, the rights expression language (REL) and the rights data dictionary (RDD), respectively. Combined with IPMP the usage of patient data can be restricted, e.g., by giving a specific nurse the permission to view a specific patient’s blood pressure during a specified time interval. In order to make the DIs available on networks and devices with different capabilities, and to users with different preferences in various environments Part 7 of MPEG21 defines the digital item adaptation (DIA). A user in this context could refer to a person, a group or an organisation. Adaptation can be useful in a healthcare environment, e.g, giving different views of the same data on terminals with different screen size and network bandwidth. The usage of DIA in a healthcare environment is proposed elsewhere [7]. Transmitting the DI as a (potentially) large XMLrepresentation is not convenient on a resource constrained network with bandwidth and resource constraints like in a BSN. Therefore Part 16 entitled “MPEG-21 binary format” gives the possibility to binary encode the XMLrepresentation in order to reduce the bit rate. In general, MPEG-21 is agnostic to which concrete algorithms are used; the digital items only refer to the algorithms, and contain the respective payload. An evaluation of different cryptographic algorithms for the use in WSN has been carried out elsewhere [10].
MPEG-21
The vision of MPEG-21, also known as ISO/IEC 21000, is to enable transparent and augmented use of multimedia resources across a wide range of networks and devices [5]. Since medical data qualify as multimedia resources this vision suits well within a hospital environment with its wired and wireless networks, portable and stationary devices, and a variety of multimedia resources. MPEG-21 also provides means to protect the content, so that the desirable level of privacy can be achieved. While not all of the eighteen parts of MPEG-21 are suited for our purpose, the most relevant parts will be presented in the following. The most fundamental concept in MPEG-21 is that of a digital item (DI), which is described in Part 2 of MPEG21. The DI is a structured object, represented as an XMLdescription, that contains the multimedia resources (or ref-
4
Proposed Architecture
Our architecture builds on the medical digital items (MDI) introduced in a healthcare environment [6], and suggested for BSN [7]. We employ MPEG-21 to package the biomedical data and relevant meta-data into MDI containers, and transfer these from the sensor node to the PDC. The architecture and data-flow is shown in Figure 2. 3
4.1
Initialisation of sensor nodes
Prior to deployment of the sensor nodes an initialisation phase will occur. In this phase the following tasks are completed: (1) key-agreement, (2) distribution of XMLgenerated code, (3) coupling sensor id with patient id. The key-agreement is envisioned as follows: The sensor and the PDC uses symmetric encryption, and thus a unique and shared (symmetric) key. This way, a node will only be able to read messages from the PDC, and not messages from other nodes. The key might be generated by the PDC or by a more powerful device which has a secure (encrypted) connection to the PDC. The key is then transferred with wireless communication from the PDC to the sensor by some protocol. This is obviously a weak spot where the key can be intercepted. One might consider using some kind of a Faraday cage to shield the electromagnetic signals so that a potential attacker is physically unable to intercept the key. The software to encode the MDI on a sensor is generated from the XML schema of the MDI, implemented in an automaton. Also the software to decode the MDI on the PDC is generated from the XML schema of the MDI. The software is deployed to the sensor node and PDC before operation of the network together with the initial key exchange, as shown in Figure 2. The PDC stores the sensor and stream identities2 and links them to the patient identity. Before attaching a sensor to a patient a manually initiated procedure assigns sensor and stream identities in order to identify each stream uniquely. Together with the stream initialisation the PDC attaches node and stream identities to the patient identification and identification of the examination. Thereby the patient identity and examination are linked to the sensor and streams. This information is resident in the sink node, and is communicated to the hospital infrastructure via an MDI.
4.2
Figure 2. Proposed architecture.
Figure 3. Encoding the µMDI. and encoded version to the PDC, possibly via other nodes. These will not be able to learn any of the contents since these are not in the possession of the decryption key. After the µMDI arrives at the PDC it is decoded and decrypted. All relevant context information, such as references to the XML-schema in use, is then added together with completed patient data to the µMDI to produce a full MDI. Data belonging to the same patient might be aggregated into one MDI before being sent further along the channels described in the generic system model. While the choice of encryption methods is outside the scope of both MPEG-21 and our architecture, we envision the use of lightweight implementations, e.g., Sizzle [11]. To maintain privacy the encryption must be between the source and sink, and therefore be placed at the transport layer or above.
Digital Item Data Flow
To keep the amount of data processed and sent from the sensor node at a minimum we introduce the concept of the lightweight MDI for the sensor (µMDI) that solely contains the necessary data and meta-data. After the sensor has been deployed the following workflow takes place: The sensor measures biomedical data from a patient. The biomedical data and metadata are concatenated with sensor id, stream id, timestamp and a sequence number into the µMDI which is signed and encrypted. The encryption uses the pre-distributed symmetric key that is shared only between the originating sensor and the PDC. This secured µMDI is then binary encoded using BiM, as illustrated in Figure 3. The sensor sends the encrypted
4.3
Encoding the µMDI
The representation of the µMDI in plain XML is not viable on BSN due to resource limitations. MPEG-21 Part 16
2 The stream id is needed for multi-sensors capable of handling several streams simultaneously.
4
5.2
provides a mechanism by which XML documents used in the MPEG-21 framework can be transmitted in binary, so that the bit-rate can be reduced significantly [4, 12]. The BiM encoding [13, 14] which was already introduced for MPEG-7 represents the data is in the form of a tree, where the tree nodes can be addressed, and operations can be applied. In our framework the µMDI container will be encoded binary using the BiM encoding. The data on the sensor node are encoded by an automaton, which can be generated from the XML schema describing the µMDI used on this sensor node. On the PDC, the code to decode the µMDI is generated from the same XML schema. No other sensor nodes are aware of the MDI schema. Not all meta-data need to be included in every packet. Descriptive meta-data could be sent out less often than, e.g., critical meta-data like time stamps, and stream id.
5
Since the sensor nodes are resource restricted the use of XML on the sensor nodes is not viable due to space constraints. On the sensor nodes parsing of message content is avoided. As a consequence, XML is processed only outside the sensor nodes. The code to BiM-encode the MDIs in the sensor node is generated outside the sensor node from XML schemas, e.g., on the PDC during the initialisation phase. The software is typically implemented as a simple automaton which has a small fingerprint. Since the µMDI structure is constant while operating a sensor node, a bitstream binding language [12] is not necessary. Compared to conventional messages from the sensor nodes, the BiM-encoded messages contain path information which increases the packet length. Benchmarks show that we can expect a considerable overhead for the general case [13]. Therefore the layout of the XML-tree to represent the µMDI will be carefully designed in order to minimise the overhead in the BiM-encoding. Also the ratio between payload, i.e., measured data, and the data necessary to secure the µMDI will be balanced. Since packet length and computation increase, more energy will be consumed, affecting the battery life time. The most critical factor is the increase of the packet length since transmitting longer packets contributes considerably to energy consumption. The additional processing time needed is rather small, and linear to the data size of the transmitted package.
Discussion
Our framework uses an international and open multimedia standard for end-to-end content management to meet the security goals of data privacy and integrity of medical data in a BSN.
5.1
Suitability for BSN
Security
Our framework applies to the threats at the application level, such as patient data eavesdropping, while threats at the communication level, such as routing attacks, are not addressed. Note that some information entities should be protected, also when the transport layer handles encryption; e.g., check sums of patient data and node/stream id should be encrypted so that tampering with data is not possible. In a BSN, a Dolev-Yao-attacker could be in the possession of a powerful sensor node, which could send or receive syntactically correct messages. The existence of messages, and additional knowledge that an attacker might have from the context (e.g., operation schedule in a hospital, access to an ambulance scenario) might unwantedly reveal a limited amount of information. Of the different attacks to BSN outlined previously eavesdropping the sensor data would require breaking the cryptographic algorithm. Altering and injection of messages would be detected since the DolevYao-attacker would not be able to correctly sign messages. Even if signatures are not used, only the source node and the PDC are able to encrypt and decrypt messages since only these are in the possession of the symmetric key. Routing attacks, DoS attacks, and physical disturbances of communication cannot be prevented using MPEG-21 alone. However, missing packets could be detected at the PDC, and proper action could be taken, like triggering alarms.
5.3
Relationship to other mechanisms
The now approved standard IEEE 1451.5 [15] envisions the encryption and security functionality in the presentation layer of sensor networks. Our framework using MPEG21 addresses functionality on the presentation layer, and could therefore be used for filling the presentation layer of IEEE 1451.5.
5.4
Towards an implementation
Currently, we are working on implementing our framework based on the MPEG-21 reference software [16] on ordinary PCs and IP networks. A lab consisting of PCs providing the MPEG-21 functionality for sensors, the PDC, and the hospital infrastructure is currently built. The experiments will show whether our framework is feasible, and give evidence on the size of the packets, the overhead from the encoding, and other resource requirements. The implementation of the necessary algorithms on motes running TinyOS will follow. 5
6
Conclusions
[6] M. Landén. An MPEG-21 approach to creating the first multimedia electronic patient journal system. Master’s thesis, NTNU, 2003.
We propose a framework for BSN that uses MPEG-21 for transmitting the biomedical data from sensor nodes to the hospital infrastructure. MPEG-21 has capabilities of encrypting the patient data and assigning detailed rights to them. In addition, it is suitable for handling multimedia data on different devices and networks, which can be used to enhance the user confined perceived QoS. By using the BiM-encoding technique we introduced a way to incorporate MPEG-21 in resource-constrained BSN. The scalability in terms of larger networks with many sensor nodes and user clients can easily be handled in the application (presentation) layer without additional cost. Furthermore, implementation of our framework with careful design of the µMDI will provide an efficient way of optimizing wireless data transmission, data processing, power consumption, and memory usage in the sensor nodes with adequate security mechanisms. Incorporating Part 7 of MPEG-21 in our security framework can be considered in future.
[7] A. Lie, K. Grythe, and I. Balasingham. On the use of the MPEG-21 framework in medical wireless sensor networks. Internal report, SINTEF ICT, Trondheim, Norway, 2008. [8] W. Leister, H. Abie, A.-K. Groven, T. Fretland, and I. Balasingham. Threat assessment of wireless patient monitoring systems. In Proc. ICTTA’08, Damascus, Syria, 2008. [9] D. Dolev and A.C. Yao. On the security of public key protocols. In Proc. of the IEEE 22nd Annual Symposium on Foundations of Computer Science, pages 350–357, 1981. [10] R. Roman, C. Alcaraz, and J. Lopez. A survey of cryptographic primitives and implementations for hardware-constrained sensor network nodes. Mobile Networks and Applications, 12(4):231–244, 2007. [11] V. Gupta, M. Millard, S. Fung, Zhu Yu, N. Gura, H. Eberle, and S.C. Shantz. Sizzle: a standards-based end-to-end security architecture for the embedded internet. In Third IEEE conf on Pervasive Computing and Communications, PerCom 2005, pages 247–256, 2005.
Acknowledgments This work is funded by the SAMPOS project in the VERDIKT programme of the Norwegian Research Council.
References
[12] J. Thomas-Kerr, I. Burnett, and P. Ciufo. Bitstream binding language - mapping XML multimedia containers into streams. In IEEE International conference on Multimedia and Expo, 2005, ICME 2005, pages 626–629, 2005.
[1] The Government of Norway. Act of 18 may 2001 no. 24 on personal health data filing systems and the processing of personal health data (personal health data filing system act). Stortinget, 2002.
[13] U. Niedermeier, J. Heuer, A. Hutter, W. Stechele, and A. Kaup. An MPEG-7 tool for compression and streaming of XML data. In Proc. 2002 IEEE Intl. Conf. on Multimedia and Expo, pages 521–524, 2002.
[2] Article 29 Data Protecting Working Party of Directive 95/46/EC. Working document on the processing of personal data relating to health in electronic health records (EHR), 2007. Adopted on 15 February 2007, European Commission, Directorate General Justice.
[14] S. Devillers, C. Timmerer, J. Heuer, and H. Hellwagner. Bitstream syntax description-based adaptation in streaming and constrained environments. IEEE Transactions on Multimedia, 7(3):463–470, June 2005.
[3] J.P. Walters, Z. Liang, W. Shi, and V. Chaudhary. Wireless sensor network security: A survey. In Yang Xiao, editor, Security in Distributed, Grid, and Pervasive Computing, chapter 17. Auerbach Publications, CRC Press, 2006.
[15] IEEE 1451.5 draft standard for a smart transducer interface for sensors and actuators - wireless communication protocols and transducer electronic data sheets (TEDS) formats, 2006. March 26, 2007.
[4] I. Burnett, F. Pereira, R. van de Walle, and R. Koenen, editors. The MPEG-21 Book. John Wiley & Sons, 2006. ISBN 0-47001011-8.
[16] ISO/IEC TR 21000-8: 2004. information technology - multimedia framework (MPEG-21) - part 8: Reference software, 2008.
[5] ISO/IEC TR 21000-1: 2004. information technology - multimedia framework (MPEG-21) - part 1: Vision, technologies and strategy, November 2004. 6
