Alevtina Dubovitskaya

Visara Urovi

Matteo Vasirani

Karl Aberer

Michael I Schumacher

A Cloud-based eHealth Architecture for Privacy Preserving Data Integration

Keywords: Access Control, Interoperability, Point-of-Care System

In this paper, we address the problem of building an anonymized medical database from multiple sources. Our proposed solution defines how to achieve data integration in a heterogeneous network of many clinical institutions, while preserving data utility and patients' privacy. The contribution of the paper is twofold: Firstly, we propose a secure and scalable cloud eHealth architecture to store and exchange patients' data for the treatment. Secondly, we present an algorithm for e cient aggregation of the health data for the research purposes from multiple sources independently.

Introduction

While building an anonymized database from multiple sources of individuals' sensitive data the privacy of a person may be violated. Even if the data are locally anonymized, their aggregation can still reveal sensitive information, especially if the data about an individual are distributed between di↵erent local databases [START_REF] Baig | Cloning for privacy protection in multiple independent data publications[END_REF][START_REF] Benoist | How to Collect Consent for an Anonymous Medical Database[END_REF]. Several models in the area of distributed privacy-preserving data publishing have already been proposed (i.e., pseudonymization [START_REF] Elger | Strategies for health data exchange for secondary, cross-institutional clinical research[END_REF][START_REF] Xu | A Decentralized Pseudonym Scheme for Cloud-based eHealth Systems[END_REF], secure multi-party computations (SMC) [START_REF] Clifton | Information Assurance and Security Privacy-Preserving Distributed k -Anonymity[END_REF], microaggregation [START_REF] Solanas | Distributed architecture with double-phase microaggregation for the private sharing of biomedical data in mobile health[END_REF], cloning [START_REF] Baig | Cloning for privacy protection in multiple independent data publications[END_REF]). However, those models significantly a↵ect the utility of the data, and, therefore, an e cient independent release of the data from multiple sources and their aggregation without violation of privacy remains an open problem [START_REF] Gkoulalas-Divanis | Anonymization of Electronic Medical Records to Support Clinical Analysis[END_REF].

This problem is of great interest especially in the case of secondary use of medical data. This includes the analysis of patients healthcare data in order to enhance their health care experiences and the expansion of knowledge about di↵erent diseases and appropriate treatment. Datasets containing health related information about an individual are increasingly becoming "open". In this paper, we focus on the medical data to address the following question: How is it possible to share and aggregate medical data for research purposes?

Collecting medical data raises privacy concerns as these data are of a personal nature to the patient. Additionally, in medical settings, the following requirements have to be considered: the ability to update the data about a patient (without creating multiple entries corresponding to the same person), and the possibility to recontact the patient through the caregiver that uploaded the data.

Our aim is to create an infrastructure for medical data management that allows the healthcare professionals to release patients' data for research purposes while insuring patients' privacy. To achieve this we employ generalization and pseudonymization techniques. We use binary trees to represent the data generalization and multi-key searchable encryption for generating pseudonyms.

The contribution of this paper is the following: we propose a secure framework for independently and asynchronously sharing, aggregating and searching health data in the cloud, therefore without trust to the server that stores the health data. We have chosen the cloud-based approach because it allows patients and caregivers to access aggregated healthcare data from everywhere anytime (according to the access control policy specified by the patient). Moreover, it facilitates the aggregation of the data and the creation of the database for the research purposes (RSDB).

The rest of the paper is organized as follows. In Section 2 we present a use case scenario, in Section 3 we provide the knowledge about encryption scheme and anonymity approach that we use in our work, and we compare our solution with the existing approaches. In Section 4 we describe the architecture of our proposed eHealth system, the protocol for sharing and accessing patients' data in the cloud, and our algorithm for constructing research database. In Section 5 we discuss privacy threats and countermeasures. We present the conclusion and future work in Section 6 of the paper.

Use Case Scenario

The treatment of certain diseases, such as cancer, HIV, or other serious medical conditions, relies on the administration of critical drugs used to keep those lifethreatening diseases under control. Those drugs (e.g. Efavirenzum, Imatinib) have a narrow therapeutic range and a poorly predictable relationship between the dose and the drug concentration in the blood, which may greatly vary among individuals. Therapeutic Drug Monitoring (TDM) aims at improving patient care by monitoring drug levels in the blood and adjust a dosage individually.

In order to ensure a better prediction of the relationship between dose and drug concentration a Bayesian TDM approach [START_REF] Gotta | Therapeutic drug monitoring of imatinib[END_REF] has been developed. This approach requires population health data to be collected and analyzed by researchers, therefore, building databases for medical research is of a high importance [START_REF] Dubovitskaya | Privacy preserving interoperability for personalized medicine[END_REF]. We consider a patient, P, who visits several caregivers during the treatment (e.g., when there is a need for a consultation from particular specialists, in case of traveling, or if patient has moved). We expect that the patient P is able to access his healthcare information and to decide with whom to share it. Storing data in the cloud allows an access from anywhere anytime. However, the question of privacy has to be addressed.

A widespread use of the the electronic identity cards and the cards provided by the insurance companies shows that having a smartcard is not a burden in everyday life. Therefore, we assume that a patient could use a smartcard to store a set of cryptographic keys for encryption/decryption of the sensitive data (contained in EHR) in order to prevent an un-authorised access.

For example, as it is shown on Figure 1, a set of the Electronic Health Records (EHRs) may belong to the same patient but could be generated by di↵erent caregivers. Each EHR then will be encrypted with the key shared between the patient and the caregiver that generated this EHR. The access control policy can be based on sharing the keys with the caregivers to allow access to the data for the treatment. Patients' data can also be collected for the secondary use. Anonymization algorithms are required to preserve patient privacy.

Related Work

In this section, first, we recall the details of multi-key searchable encryption scheme [START_REF] Popa | Multi-key searchable encryption[END_REF] that we employ in our solution to generate pseudonyms and annotate EHRs. Second, we describe (k, k m ) anonymity property [START_REF] Poulis | Anonymizing data with relational and transaction attributes[END_REF] that we impose on the research database and preserve while updating RSDB in the distributed environment. Finally, we present an overview of the related work and specify how they di↵er from our approach.

Multi-key Searchable Encryption

Without loss of generality we can assume that the server stores documents (a set of EHRs) encrypted with m di↵erent keys k 1 , ...k m , and a user (patient, or caregiver) that possesses n keys (n  m) wants to search for T words (e.g., diagnosis, date of visit, etc.) w 1 , ...w T in the documents.

According to the prior work [START_REF] Boneh | Public key encryption with keyword search[END_REF][START_REF] Song | Practical techniques for searches on encrypted data[END_REF], in order to perform the search of a word over the documents encrypted using di↵erent keys a user has to compute a token for each word under every key. In this case the complexity of the search will be O (nT ). However, with an approach proposed in [START_REF] Popa | Multi-key searchable encryption[END_REF] the complexity of the multi-key search over encrypted data does not exceed O (n+T ). The multi-key searchable scheme is constructed using bilinear maps on elliptic curves [START_REF] Blake | Advances in Elliptic Curve Cryptography[END_REF]. The pseudocode for the multi-key searchable encryption scheme and its implementation can be found in [START_REF] Helfer | Building web applications on top of encrypted data using Mylar[END_REF].

According to the scheme if a user has an access to the keys k 1 , ...k m in order to search for a word w he needs to compute only a single search token for this word: tk ki w using the key k i , and deltas, { ki!kj }, an additional information that allows to adjust the token (tk ki w ), computed with the key k i , to the tokens corresponding to the keys k 1 , ...k m ({tk kj w : j 6 = i, j 2 {1...m}}). These deltas represent the user's access to the documents, and, most important, these deltas can be reused for every search, so the user needs to generate them only once. E ciency of the scheme has been evaluated and it was shown that performance overheads of using multi-key searchable encryption scheme are modest [START_REF] Helfer | Building web applications on top of encrypted data using Mylar[END_REF].

In the paper [START_REF] Popa | Multi-key searchable encryption[END_REF] the authors use graphs to represent an access to the shared key. We modify the structure of the access graph by using the labeled graph instead. This allows us to reduce the complexity of the graph. For p patients and c caregivers access graph according to the approach used in [START_REF] Popa | Multi-key searchable encryption[END_REF] will contain at most p+c+p⇤c nodes and p⇤(1+c) edges, while in case of using labeled graph it will take as most p+c nodes and p⇤c edges for the complete access graph. This makes access control policy easier to interpret and manage. Each node of the graph represents a patient or a caregiver. Figure 2 shows an example of access graph. The edge (between P i and C j ) shows that P i visited C j (e.g., P 1 visited caregivers C 1 , C 2 and C 3 ), therefore patient P i and caregiver C j connected with the edge share the key that C j will use to create a pseudonym and encrypt the data about P i . Labels on the edge shows the keys P i shared with the caregiver C j , (e.g., P 1 shares with C 1 the keys P 1 generated together with C 2 and C 3 , therefore allowing C 1 access the data about P 1 generated by C 2 and and C 3 ,), however no label on the edge between P 1 and C 3 indicates that the only data about P 1 that C 3 can access are the data generated by C 3 .

Anonymity of medical data

A variety of models, (e.g., ✏-di↵erential privacy, k anonymity [START_REF] Sweeney | K-anonymity: A model for protecting privacy[END_REF], (k m ) anonymity, l diversity, etc. [START_REF] Gkoulalas-Divanis | Publishing data from electronic health records while preserving privacy: A survey of algorithms[END_REF]) can be used for privacy preserving data publishing. However, Poulis et al. show that all these methods are not appropriate for the anonymization of the datasets containing both relational (i.e., singlevalued) and transaction (i.e., set-valued) attributes, such as medical datasets that contain patient demographics and diagnosis information together [START_REF] Poulis | Anonymizing data with relational and transaction attributes[END_REF].

(k, k m ) anonymity proposed in [START_REF] Poulis | Anonymizing data with relational and transaction attributes[END_REF] ensures that for any record r in the dataset and any set of m or less items in transaction attribute of r, there should be at least (k 1) records that are indistinguishable from record r. However, k anonymity for relational attributes (i.e., existence of at least (k 1) records that are indistinguishable from record r with respect to relational attributes of the record r) and (k m ) anonymity for transaction attribute do not imply (k, k m ) anonymity. Poulis et al. developed two frameworks that produce (k, k m ) anonymous datasets with bounded information loss in one attribute type (relational or transaction) and minimal information loss in the other (transaction or relational). Our algorithmic solution (presented in the Section 4) addresses the problem of maintaining (k, k m ) anonymization property in a distributed environment.

Existing Approaches

Using encryption combined with pseudonymization techniques [START_REF] Li | A secure electronic medical record sharing mechanism in the cloud computing platform[END_REF][START_REF] Elger | Strategies for health data exchange for secondary, cross-institutional clinical research[END_REF][START_REF] Xu | A Decentralized Pseudonym Scheme for Cloud-based eHealth Systems[END_REF] has been proposed recently for building eHealth system in the cloud. There exist also a number of architectures that employ Attribute-Based encryption (ABE) scheme [START_REF] Sh | Achieving Secure, Scalable, and Finegrained Data Access Control in Cloud Computing[END_REF][START_REF] Ibraimi | Secure Management of Personal Health Records by Applying Attribute-Based Encryption[END_REF][START_REF] Li | Securing Personal Health Records in Cloud Computing: Patient-Centric and Fine-Grained Data Access Control in Multi-owner Settings[END_REF][START_REF] Li | Scalable and Secure Sharing of Personal Health Records in Cloud Computing Using Attribute-Based Encryption[END_REF][START_REF] Lounis | Secure Medical Architecture on the Cloud Using Wireless Sensor Networks for Emergency Management[END_REF]]. However, these approaches have several limitations. ABE still can leak information from the access control policy. Encryption, in general, may a↵ect the system performance especially when there is a need to search over encrypted data for a particular information. In our work we use multi-key searchable encryption scheme [START_REF] Popa | Multi-key searchable encryption[END_REF], for which it was shown that performance overheads of using this scheme are modest [START_REF] Helfer | Building web applications on top of encrypted data using Mylar[END_REF]. In [START_REF] Xu | A Decentralized Pseudonym Scheme for Cloud-based eHealth Systems[END_REF][START_REF] Li | A secure electronic medical record sharing mechanism in the cloud computing platform[END_REF] the authors suggest a patient-centric architecture and propose to use the smartcards for the key management. if the smartcard is lost it is very di cult to recover the keys. However, in our solution the keys can be recovered through the caregivers.

Urovi et al. in [START_REF] Urovi | Secure P2P cross-community health record exchange in IHE compatible systems[END_REF] proposed a secure mechanism for EHR exchange over a Peer to Peer (P2P) agent based coordination framework. In this approach the encrypted heterogeneous data are exposed over a P2P network. The authors provide the algorithms for searching and for publishing the EHRs in the untrusted P2P network without compromising the privacy, integrity and the authenticity of the shared data. This work, however, does not cover the aggregation of the data for the research purposes, as we propose here.

Using unambiguous pseudonym for the patient [START_REF] Iacono | Multi-centric universal pseudonymisation for secondary use of the EHR[END_REF] allows one to infer additional information about a patient by linking the data from di↵erent sources. In case of using multiple pseudonyms, as in [START_REF] Xu | A Decentralized Pseudonym Scheme for Cloud-based eHealth Systems[END_REF], their e cient management is problematic. To solve these issues we generate patients' pseudonyms with the means of the multi-key searchable encryption scheme proposed in [START_REF] Popa | Multi-key searchable encryption[END_REF]. We also use this scheme to enable e cient search over the EHRs.

In [START_REF] Clifton | Information Assurance and Security Privacy-Preserving Distributed k -Anonymity[END_REF] the authors describe privacy-preserving distributed k anonymity algorithm that allows merging two local k anonymous datasets while preserving k anonymity property in the resulting dataset. However, the solution is not scalable and requires using SMC, sharing data is not independent among different sources contributing to the RSDB. Baig et al. [START_REF] Baig | Cloning for privacy protection in multiple independent data publications[END_REF] suggest a model called ✏-cloning for privacy protection in multiple independent data publications. However, it cannot be applied in our settings because it significantly a↵ects the utility of the data. In [START_REF] Benoist | How to Collect Consent for an Anonymous Medical Database[END_REF] the authors proposed an architecture that allows collecting the patients consents for sharing their data for the research in an anonymous way. However, the authors assume that the data are already anonymized.

Proposed e-Health Architecture

In this section, we describe our proposed eHealth system. Figure 3 shows an architecture that consists of the following entities: Databases (Local Database, on the client side and Data Repository and Research Database, both hosted on the cloud server); Cryptographic Module on the side of the client; Anonymization Module (on both sides); and standalone Certification Authority. Local Database, LDB, belongs to the caregiver and contains healthcare data about the patients that receive treatment from this caregiver. Data Repository, DR, is hosted on the untrusted cloud server and stores EHR generated in di↵erent medical institutions. Anonymized patients data for the research purposes are stored on the cloud server in Research Database, RSDB. Cryptographic Module consists of three parts and its functionalities are the following: to perform multi-key searchable encryption; to encrypt EHR before uploading to the cloud server in order to share with the other caregivers, as well as to decrypt when accessing EHR according to the access control policy specified by the patient; and, to generate the signature to ensure the authenticity of the data. Anonymization Module is a realization of the algorithm for medical data anonymization presented further in this paper. Certification Authority, CA, is a service that is responsible for issuing certificates of public keys and smartcads for storing private keys that are protected with the PIN known only to the owner of the smartcard.

Data Structure

Hereafter we describe the structure of the data that are stored in the databases.

-Pseudonym(s) -a set of uniquely identifiable patient data, ID P , (such as combination of date of birth, place of birth and the name) that is encrypted using multi-key searchable encryption scheme proposed in [START_REF] Popa | Multi-key searchable encryption[END_REF], stored in all databases: DR, LDB and RSDB.

-QID -quasi-identifiers -a set of the attributes ({qid}) that in combination can uniquely identify the person (e.g., single-valued qid, such as age, gender, address (i.e., ZIP code) and set-valued qid, such as diagnosis codes), gnrlQID -a combination of generalized qid (in a form of a binary string), with which the data about P have been uploaded to the RSDB.

-Healthcare data -drug intakes (time, dosage, drug name), co-medications, concentration measurements (time, measurement) -multiple attributes, that can be set-, or single-valued)).

-Cryprographic keys and deltas -a set of the deltas for the keys (K S P,Cj , j 2 1, N , i 6 = j) related to the patient and shared with C i (see Subection 3.1 for more details).

-Encrypted data -health data, or, EHR, encrypted with symmetric cipher (e.g., AES).

-Searchable data -EHR or a list of the attributes that describe the content of the EHR (encrypted using multi-key searchable encryption scheme).

-Anonymized data -consist of generalized QID (gnrlQID) and a subset of healthcare data from LDB.

StRSDB -is a table that characterizes the current state of the (k, k m ) anonymous RSDB. For each combination of qid that are presented in RSDB, StRSDB stores the following information: PsNumber -a number of di↵erent pseudonyms from RSDB associated with the same QID set and the sources of data (C i that uploaded the data, and PsNumber i , a number of pseudonyms associated with this QID). One has to notice that as RSDB is (k, k m ) anonymous, PsNumber k and P i21,N PsNumber i = PsNumber. Figure 4(c) presents an example of StRSDB.

We also assume that each database stores date/time of inserting a record; in DR and RSDB the signature of every record is stored together with PK C of a caregiver that uploaded the data and sigh them. Figure 4 shows the examples of LDB (a), RSDB (b) and the representation of the metadata of RSDB, StRSDB, on Figure 4(c). The data from this particular example show the dosage of the drug and its actual concentration in the blood for a group of patients.

Sharing and Accessing Patient's Data for the Treatment

Hereafter we present a protocol for storing and accessing patients' data in DR.

-Step 1. Patient generates a shared key (using a hash-function H and a random number r 1 0 ) with Caregiver (C 1 ) he visits, this key will to be used for multi-key searchable encryption scheme: K S P,C1 = H SK P k r 1 0 . Since this scheme does not support decryption, the data need to be encrypted twice: once for searching, and once with a traditional encryption scheme like AES, for decryption. Unique AES encryption key (K D P,C1 ) also has to be generated for the caregiver by the patient: The keys are generated from the Patient's secret key with the use of a smartcard or a mobile device.

-Step 2. At the Caregiver's o ce Patient has to transmit the keys to Caregiver's machine using card-reader device in the Caregiver's o ce or through a secured channel in the encrypted form:

CT 1 = Enc ⇣ K S P,C1 , K D P,C1 ⌘ PK C 1 .
To ensure integrity Patient's signature (Sign (CT 1 ) SK P ) and Patient's public key (PK P ) for verification are also required.

-Step 3. When the EHR is generated the content is encrypted with the shared keys (CT 2 ) and signed with the secret key of Caregiver (Sign (CT 2 ) SK C 1 ): To improve e ciency the indexable version of the encryption scheme proposed in [START_REF] Helfer | Building web applications on top of encrypted data using Mylar[END_REF] can be used. One can also apply encryption algorithm for searching only to the list of the keywords that describes the content of the EHR, such as patient's ID (ID P ), caregiver's qualification, date of the visit, symptoms, etc. Pseudonym, with which EHR can be associated in LDB of C 1 :

CT 2 = hEnc S (EHR) K S P,C 1 , Enc (EHR) K D P,C 1 i.
PS 1 P = (Enc S (ID P ) K S P,C 1 )
is generated using patient's set of uniquely identifiable patient data encrypted with the shared key for search. Therefore, a Caregiver will be able to find and update the data about Patient in an e cient way. Visiting a caregiver Patient can decide what data stored at DR he wants to share. For instance, to provide Caregiver 1 an access to the EHR generated by Caregiver 2, he only needs to share with Caregiver 1 the keys shared between Caregiver 2 and Patient:

⇣ K S P,C2 , K D P,C2 ⌘
. To be able to retrieve Patient's EHR(s) based on the pseudonyms (or an attribute of EHR) a caregiver has to submit to Cloud Platform, CP, a token generated for the ID P (or an attribute), as well as the deltas for other keys related to the patient, in order to let CP adjust the token. Token and deltas are to be computed according to the scheme described in [START_REF] Popa | Multi-key searchable encryption[END_REF].

Anonymization of Patients' data for Research Purposes

In this subsection we present a description of the algorithm that allows to release medical data for the research purposes from di↵erent LDBs independently, while preserving the anonymity property of RSDB. We ensure that given the consent of the patient caregivers will be able to update RSDB with the data about the patient without creating multiple entries that correspond to the same person. Our solution also provides a possibility to recontact the patient through a caregiver that uploads the data.

We consider N Caregivers that may upload the data to RSDB. We assume that RSDB is initialized as (k, k m ) anonymous, i.e., an algorithm to achieve (k, k m ) anonymity proposed in [START_REF] Poulis | Anonymizing data with relational and transaction attributes[END_REF] had been applied to the local dataset to build the initial version of RSDB. For each qid there exist a binary tree, according to which generalization is performed. Figure 5 presents an example of binary trees that are constructed for the single-valued QID: age and gender (Figure 5(a)) and also shows an example of representing a set-valued attribute (Figure 5(b)). Our algorithm scales for any number of qids.

procedure Gener(QID)

V IEW StRSDB Figure 6 shows the pseudocode of the RSDB update algorithm and the generalization procedure used in the algorithm. The algorithm for RSDB update has to be executed every time a caregiver C i wants to update RSDB with the data about patient P. First, C i has to check whether he already uploaded the data about P to the RSDB. He can query his LDB with the patient pseudonym PS i P , generated using the shared between P and C i key K S P,Ci . If the value in a column gnrlQID in a raw that corresponds to the PS i P is not empty, than some data about P are already presented in RSDB with a combination of generalized QID that is described by the vector of binary strings, each represents gnrlqid. In this case C i associates the data of P with these gnrlQID that corresponds to PS i P (lines 3,4 of the algorithm presented in Figure 6)(a)). Otherwise, C i has to perform a SearchOver procedure to check whether there are some data about P that had been upload to RSDB by another caregiver C j , j 6 = i (line 6 ). However, this is only possible if P trusts C i to check this (i.e., if P gave C i an access to the K S P,Cj -key shared between P and C j ). If SearchOver procedure returns a single pseudonym, C i will update RSDB with the P' data with gnrlQID that corresponds to PS j P (lines 8-10 ). If the result of SearchOver contains more than one pseudonym, C i checks whether there is a possibility to merge the pseudonyms related to P by applying MergePseud procedure (line 12 ). Afterwards, C i will update RSDB by uploading the data of P with (the least generalized) gnrlQID that corresponds to PS j P . If SearchOver procedure returns empty set, then the Gener procedure is performed (line 15 ), and as its output, a combination of the least generalized gnrlQID is generated based on the StRSDB and the P's QID.

for i = 0; i < (k QID k 1); i + + do di = 0 depthi = qid.length() newT qid = ✏ newF qid = ✏ while (di 6 = depthi) _ (9gnrlqid T , gnrlqid F : (gnrlqid T = V IEW.QID[i]) _ (gnrlqid F = V IEW.QID[i]) _ (newT qid is a prefix of gnrlqid T ) _ (newF qid is a prefix of gnrlqid F )) do newF qid = newT qid+qQID[i].substring(d, d + 1) newT qid = newT qid+QID[i].substring(d, d+1) di = di + 1 end while V IEW V IEW _ (V IEW.QID[i] = newF qid.
SearchOver(PS P , { K S P,C i !K S P,C j }) procedure takes as an input the following data: patient's pseudonym (PS P ) generated with the key shared between the patient and caregiver C i (K S P,Ci ); and a set of the deltas ({

K S P,C i !K S P,C j })
-values generated for the keys ({K S P,Cj , j 2 1, N , i 6 = j}) related to the patient and shared with the caregiver C i . Then, according to the schema proposed in [START_REF] Popa | Multi-key searchable encryption[END_REF], a server, which hosts RSDB, can perform a search for all the pseudonyms ({PS P }) generated by di↵erent caregivers with their keys (K S P,Cj , j 2 1, N ) (adjusting a pseudonym generated by the caregiver C i with key (K S P,Ci ) to the one generated by the caregiver C j with key ( K S P,Cj ) without learning neither identity of the P, nor the key K S P,C ) over the column that stores pseudonyms in RSDB. As a result a set of pseudonyms together with gnrlQID that corresponds to each pseudonyms are being returned.

MergePseud(k, tempPS) allows to check whether it is possible to merge pseudonyms that correspond to the same patients but generated by di↵erent caregivers. It returns the least generalized gnrlQID and merges pseudonyms if does not violate anonymity property of RSDB. The input is a parameter k and a set of pseudonyms discovered at the previous step.

Figure 6(c) shows the pseudocode for Gener(QID) procedure that is performed to create the least generalized gnrlQID for the QID of the patient whose data have not been yet upload to RSDB (or the data about the patient P might have been uploaded by the caregiver C j , but a caregiver C i that wants to upload the data about patient P for the first time does not possess the key K S P,Cj ). Input of the procedure is QID -an array of binary strings, each corresponds to one qid. Binary strings are constructed according to the representation of the QID using binary trees. During the execution each qid is considered one after another (the order is based on the importance of the qid) and generalized qid is formed by querying first gnrlQID column of StRSDB, and then a view created based on the previously generalized qid. The goal is to find the least generalized set gnrlQID for a QID of the patient such that StRSDB already contains at least k entries with this set gnrlQID without disclosing the QID.

Discussion

In this section we analyze the limitations of our model and possible privacy threats. We also suggest the countermeasures against the threats.

Limitations

We assume that caregiver is trusted, meaning that he respects the medical ethic and will share the data about his patient (including the data produced by other caregivers for the treatment of this patient) only according to the access control policy specified by the patient. However, if (by any reason) the patient does not want the caregiver to be able to access patients' data that are stored in the cloud, a new key has to be created, the data have to be re-encrypted on the server side, e.g., with the means of a proxy re-encryption scheme [START_REF] Ateniese | Improved proxy re-encryption schemes with applications to secure distributed storage[END_REF]. We also require an existence of a certification authority that provides the certificates for public keys and is able to check the identity of a caregiver to ensure that the data aggregated in RSDB have been uploaded by a real doctor. However, CA does not have an access to the patients healthcare data.

A caregiver C can perform a MergePseud procedure only before he makes the first update of RSDB. Therefore, in order to merge pseudonyms the following strategy can be applied. According to the access control policy specified by the patient a caregiver that possesses the largest number of the keys may perform SearchOver and MergePseud procedures every time after de-generalization protocol is executed. This will decrease the number of pseudonyms, with which the information about the patient had been uploaded by di↵erent caregivers.

With the proposed algorithm we only preserve the utility of the RSDB. However, to improve utility of the data from RSDB, the possibility to de-generalize the data from RSDB without violation of patients' privacy (during bounded time interval) need to be considered. To define the requirements and selection criteria for gnrlqid to be de-generalized are the next steps in our future work.

Generalization step (procedure Gener of the algorithm) requires going through all the qid one by one. However, we assume that the number of qids stored in the RSDB is not high and qids are ordered based on their importance with respect to the requirements to the RSDB.

Possible Threats and Countermeasures

If a patient loses his smart card, all the keys can be recovered from the LDBs of the caregivers that treat the patient. If the smartcard was stolen it is still di cult access the data or to modify the access control policy for anybody except the patient, because the card is protected with PIN code that is known only to the owner of the card. The limit of attempts to insert a valid PIN code can be set up to prevent brute-force attack.

We assume that the cloud server, where RSDB and DR are hosted, is honest but curious (it executes protocols and the algorithm correctly but tries to learn about the patient as much as possible). For example, some additional location information can be inferred from the IP address of the device that transmits the data from LDB, and these data could be more precise then gnrlqid that stands for the patient address. Therefore, this can violate (k, k m ) anonymity. A straightforward countermeasure is to hide the IP address from the cloud server, e.g., using HTTP proxies or anonymous communication service like Tor [START_REF] Dingledine | Tor: The second-generation onion router[END_REF].

Caregivers could potentially link pseudonyms related to the same patient using the column PrevPS in case of pseudonyms merging. To prevent this during the procedure of merging the pseudonyms, the previous pseudonym has to be encrypted together with the information about the caregiver that had created this pseudonym. The cipher text and a parameter that will indicate how many times the pseudonym had been updated will be stored in the column PrevPS. Then, it will be possible to find the caregiver that initially uploaded the data (i.g., in case of legal issues), through the caregiver(s) that merged pseudonyms.

Conclusion and Future Work

In this paper, we proposed an architecture of a secure and scalable privacypreserving eHealth cloud system (that allows to store and e ciently search over patient data used for the treatment), and an algorithm that allows to build a database with patients' data for the research purposes.

In future work we will focus on the implementation of the architecture proposed in this paper and on its evaluation using a synthetic dataset (http://omop. org/OSIM2), and real patient data from our medical partners in the framework of ISyPeM2 project (www.nano-tera.ch/projects/368.php). We will also work towards de-generalization of RSDB to improve utility of the data. Finally, we will focus on improving e ciency of proposed solution by extending representation of the QID (from binary trees to n-ary trees) and employing agent based coordination model for the construction of RSDB.

Fig. 1 .

 1 Fig. 1. Use case scenario.

Fig. 2 .

 2 Fig. 2. An example of the access graph.

Fig. 3 .

 3 Fig. 3. Architecture overview.

Fig. 4 .

 4 Fig. 4. Example of data representation in LDB (a) RSDB (b) and StRSDB (c).

Fig. 5 .

 5 Fig. 5. Binary trees for qids: age and gender (a), and any set-valued qid (b).

Fig. 6 .

 6 Fig. 6. Pseudocode of the RSDB Update Algorithm (a) and Generalization (b).

Acknowledgements

This work was supported by the Nano-Tera initiative, in the framework of an RTD project ISyPeM2: developing therapeutic drug monitoring by designing a point-of-care system to measure drug concentration in blood samples and adjust dosage accordingly.


Jaspreet Kaur
email: jaspreet.kaur@fkie.fraunhofer.de

Jernej Tonejc
email: jernej.tonejc@fkie.fraunhofer.de

Steffen Wendzel
email: steffen.wendzel@fkie.fraunhofer.de

Michael Meier
email: michael.meier@fkie.fraunhofer.de

Securing BACnet's Pitfalls

Keywords: BACnet, network, security, attack, intrusion detection, traffic normalization, building automation, Snort

Building Automation Systems (BAS) are crucial for monitoring and controlling buildings, ranging from small homes to critical infrastructure, such as airports or military facilities. A major concern in this context is the security of BAS communication protocols and devices. The building automation and control networking protocol (BACnet) is integrated into products of more than 800 vendors worldwide. However, BACnet devices are vulnerable to attacks. We present a novel solution for the two most important BACnet layers, i.e. those independent of the data link layer technology, namely the network and the application layer. We provide the first implementation and evaluation of traffic normalization for BAS traffic. Our proof of concept code is based on the open source software Snort.

Introduction

BACnet (Building Automation and Control Networking Protocol) is an open data communication protocol developed by ASHRAE (American Society of Heating, Refrigerating and Air Conditioning Engineers), standardized by ISO 16484-5 [START_REF]2012 Building automation and control systems -Part 5: Data communication protocol[END_REF] and used for building automation systems (BAS). In general, BAS are integrated in and capable of controlling and monitoring buildings. Moreover, BAS form networks which can be interconnected with other buildings and the Internet (e.g., for remote monitoring purposes). In order to support interoperability, BACnet can use different lower level network protocols to perform its functions [START_REF] Merz | Building Automation: Communication systems with EIB/KNX, LON and BACnet. Signals and Communication Technology[END_REF]. In addition to BACnet, the European Installation Bus (EIB)/Konnex (KNX), and the Local Operating Network (LON) are the most common BAS protocols used in practice. The main goals of BAS are to improve the energy efficiency of buildings, to increase the comfort and safety of the people living or working in a building, and to decrease a building's operational costs.

Because of the immense growth of BAS, especially BACnet, the need for secure interconnection between BAS devices is increasing. Currently, there are neither intrusion detection nor intrusion prevention systems which are capable of detecting or preventing various network and application layer based attacks on BACnet devices. Although security features for BAS protocols are specified in their standards and have improved over time, they are, as highlighted in discussions with our industry partners, usually neither integrated in devices nor used in practice. Due to the Internet connectivity of BACnet systems and the fact that BACnet devices can be found using the SHODAN search engine (cf. www.shodanhq.com), remote attacks on BACnet devices can also be performed. Such attacks can, for instance, compromise smoke detectors or other critical BAS equipment. According to [START_REF]Proofpoint Uncovers Internet of Things (IoT) Cyberattack. Report[END_REF], there were more than 100,000 Internet-connected smart devices (including media players, smart televisions and at least one refrigerator) interconnected to a network of computers, which were able to send 750,000 spam emails between December 23, 2013 and January 6, 2014. In addition, the so-called smart building botnets could extend the capabilities of today's botnets by taking advantage of a building's physical capabilities (sensors and actuators) [START_REF] Wendzel | Envisioning Smart Building Botnets[END_REF].

In this paper, we show how to prevent the exploitation of vulnerabilities at the BACnet network and application layers. In particular, devices which interact with humans have to be both secure and safe; otherwise they can threaten and compromise human life. We improve network and application reliability and security with traffic normalizers (also known as protocol scrubbers [START_REF] Malan | Transport and application protocol scrubbing[END_REF] from TCP/IP networks). In TCP/IP networks, traffic normalization is capable of preventing various attacks on TCP/IP stack implementations [START_REF] Handley | Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics[END_REF]. So far, there is no BAS protocol for which traffic normalization has been applied. The building automation devices usually remain in buildings for decades, possess limited processing power and insecure firmware, and often cannot cope with malformed or malicious packets, hence there is an increased need for such normalizers.

We analyze the BACnet network and the application layer with its potential vulnerabilities and its potential non-compliant behavior, with the goal of ensuring that BACnet devices receive correctly formed messages. In addition, we study the well-known attacks from TCP/IP and adapt them to the corresponding BACnet network and application layer, in order to design effective countermeasures. Based on the discovered vulnerabilities, we present the first implementation of traffic normalization for building automation systems in the form of a Snort [START_REF]Snort -open source network intrusion prevention system and network intrusion detection system[END_REF] extension. Additionally, our normalization rules provide a means to counter fuzzing attacks and protect BACnet devices which are are not usually updated because patching is a challenging task for BAS. We design our system to normalize traffic between BAS subnets (e.g., between different floors of a building or between separate buildings). Our normalizer implementation ensures that the transferred packets reach the receiver well-formed according to the protocol standard, without protocol vulnerabilities. The Snort extension is implemented in a way that gives us an opportunity to either limit or prevent the initiated intrusions mentioned in this paper.

The rest of the paper is structured as follows. We summarize the related work in the area of BACnet security in Sect. 2. In order to make our method of protecting vulnerabilities in the BACnet network and application layer understandable, we provide a short overview on the relevant parts of the BACnet protocol in Sect. 3. Section 4 lists several vulnerabilities that were found by look-ing at the specifications of the standard, together with the adaptations of the TCP/IP attacks. Our normalization rules are presented in Sect. 5. The overview of the testing environment is presented in Sect. 6. In Sect. 7, we evaluate and summarize our results and discuss future work.

Related Work

Earlier installations of BAS were designed to work as isolated standalone systems with minimal security features. As the BAS functionality requirements increased, interconnectivity, interoperability, and especially Internet access for BAS became significant features. However, the interconnectivity of BAS enables remote attacks. Attacks on BAS can focus on gaining physical access to a building [START_REF] Holmberg | Enemies at the gates[END_REF] (e.g., by exploiting window or door actuators), on gaining access to an organizational intranet [START_REF] Soucek | Current developments and challenges in building automation[END_REF], on terrorist attacks [START_REF] Holmberg | Enemies at the gates[END_REF] (e.g., turning off fire alarms before a fire is placed), on monitoring inhabitants [START_REF] Wendzel | Covert Channels and their Prevention in Building Automation Protocols -A Prototype Exemplified Using BACnet[END_REF], or on disabling a building's functionality via denial-of-service (DoS) attacks [START_REF] Granzer | Security in networked building automation systems[END_REF]. Čeleda et al. [START_REF] Čeleda | Flow-Based Security Issue Detection in Building Automation and Control Networks[END_REF] and Szlósarczyk et al. [START_REF] Szlósarczyk | Towards Suppressing Attacks on and Improving Resilience of Building Automation Systems -an Approach Exemplified Using BACnet[END_REF] showed that different types of DoS attacks exist for BAS. As pointed out by Bowers [START_REF] Bowers | How to Own a Building: Exploiting the Physical World with BacNET and the BACnet Attack Framework[END_REF], BACnet devices are not robust enough to deal with abnormal traffic, since protocol implementations are vulnerable to malformed packets and various forms of attacks. The BACnet Attack Framework (BAF) [START_REF] Bowers | How to Own a Building: Exploiting the Physical World with BacNET and the BACnet Attack Framework[END_REF] introduces attack techniques, namely attacks on the BACnet routing, network mapping, DoS and spoofing. The existing work provides a good estimate of the current attack surface for BAS networks.

In terms of defense against (some of) the attacks mentioned above, the BACnet Firewall Router (BFR) [START_REF] Holmberg | Using the BACnet firewall router[END_REF] is the first approach integrating simple firewall functionality in BACnet. BFR is an open source project that implements filters for BACnet messages and is capable of performing NAT, software-side network switching, and routing. However, the BFR does not possess any normalization capabilities. In comparison to the previous work, we present the first traffic normalization for BAS capable of countering typical attacks known from TCP/IP networks, ensuring compliance, and increasing robustness against vulnerability tests and fuzzing attacks.

Structure of BACnet NPDU and APDU

BACnet's purpose is to handle a number of application areas such as lighting, fire alarms, and heating, ventilation, and air-conditioning (HVAC) in a cost effective, interoperable, and reliable manner [START_REF] Tom | BACnet for a City -Saving Energy one Small Building at a Time; BACnet Today and the Smart Grid[END_REF]. BACnet defines four layers (physical, data link, network, and application layer), similar to the particular functions of the OSI layers (shown in Fig. 1) and is designed to adapt to different data link and physical layer technologies to achieve data link layer-independent communication. BACnet network layer messages can be encapsulated in UDP (referred to as BACnet/IP), the BACnet-specific protocol MS/TP (RS485) or LonTalk ZigBee. The BACnet model differs from the OSI layer model in that the BACnet application layer is additionally responsible for performing and handling the message segmentation and reassembly, a feature usually accomplished by the transport layer. Our work focuses on the network and application layers. Therefore, we need to introduce the addressing scheme and the structure of the BACnet Network Protocol Data Unit (NPDU) and the Application Protocol Data Unit (APDU).

Each BACnet device has a medium access control (MAC) address which is combined with the BACnet (sub)net number to form the network level address. An essential feature in BACnet is broadcasting. Due to the nature of BACnet topology, three types of broadcasts are supported: local, global, and remote.

Network Layer

Even if the BACnet network layer is embedded into various data link layer protocols, the NPDU structure remains unchanged. We will focus on BACnet/IP, i.e. BACnet encapsulated in UDP sent over IPv4 [START_REF]2012 Building automation and control systems -Part 5: Data communication protocol[END_REF], for which we define our normalization rules. The structure of the BACnet NPDU is shown in Fig. 2.

Application Layer

An application program which uses the BACnet protocol interacts with a BACnet peer device. The purpose of the interaction itself is mainly to invoke devicespecific behavior, e.g. switching on/off a lighting device or ringing an alarm bell of an alarm device. To realize application-specific behavior, so-called objects are specified for functional behavior and services are specified for the interaction with the devices. The application layer then defines all required objects and services for a device's interaction with an application program. Notice that the application itself is independent of the application layer and is outside the scope of the BACnet ISO standard. In particular, the standard does not specify the Application Programming Interface (API).

For normalization, the relevant part of the APDU is the first region, called the Application Protocol Control Information (APCI), which is always present and whose length varies from 2 to 6 bytes depending on the PDU type. An example of a Confirmed Request PDU is shown in Fig. 3.

Exploiting the BACnet Network and Application Layer

We base our normalization rules and the need for traffic normalization by looking at the potential security deficits in BACnet. We group our attacks on BACnet/IP into two main categories: attacks adapted from TCP/IP, and attacks specific to BACnet. Each category represents the possible vulnerabilities allowing the exploitation of BACnet devices by taking advantage of primitive vulnerabilities in the network or application layer. We give a brief overview of the general attacker model. In this model, the attacker is outside the BACnet network with a goal to exploit a BACnet device. He is sending packets remotely to a BACnet device (e.g. fire alarm, HVAC or a simple door) through a BACnet Broadcast Management Device (BBMD), which forwards all the packets to the corresponding device. This scenario can be considered as the standard approach to attack BACnet environments remotely as BBMDs are always present to handle broadcasts between BACnet devices. The model is graphically depicted in Fig. 4 left.

BBMD

Attacks adapted from TCP/IP

Covert Channels. As shown in [START_REF] Wendzel | Covert Channels and their Prevention in Building Automation Protocols -A Prototype Exemplified Using BACnet[END_REF], BACnet allows for creating network covert channels, i.e. the policy-breaking communication channels capable of transferring data in a stealthy manner which can enable hidden command and control communication for botnets. Disguised as BACnet traffic, malware could use BACnet covert channels to hide illegitimate or confidential data within unobtrusive Internet-based traffic. Many hiding techniques for network covert channels are based on the idea of embedding hidden information in the unused NPDU and APDU fields. In the case of BACnet, all reserved bits can serve the purpose of embedding hidden information. Moreover, the use of particular BACnet message types and timing variations between BACnet messages can signal hidden information [START_REF] Wendzel | Covert Channels and their Prevention in Building Automation Protocols -A Prototype Exemplified Using BACnet[END_REF].

Abnormal behavior leading to botnets in BAS. Referring to the example of a refrigerator sending spam mails (cf. Sect. 1), we extended our research to examine the compromised BACnet devices, including BBMDs. Our concern is to provide security measures for the BACnet protocol against the abnormal behavior. Čeleda et al. [START_REF] Čeleda | Flow-Based Security Issue Detection in Building Automation and Control Networks[END_REF] introduced two examples of attacks that can serve as a backdoor for an attacker in a BACnet network. The WriteProperty attack can cause a BBMD or a BACnet device to switch on/off, resulting in an opportunity for an attacker gaining access to the restricted BACnet network. In general, the WriteProperty attack and disabling of network connection are possible by changing values in BACnet's object properties, respectively misusing BACnet services, i.e. in application layer [START_REF] Čeleda | Flow-Based Security Issue Detection in Building Automation and Control Networks[END_REF].

In addition, after successfully attacking a BACnet device, an attacker has an opportunity to use the device's communication channel within the subnet. One of the possible examples of such a scenario is shown in Fig. 4 right. We assume the attacker has determined the details of both BACnet devices in the subnet with the help of probing. If he takes over the lighting device, as shown in Fig. 4 right, then he gains the ability to transfer any kind of message he wants.

For instance, he can send a packet with an APDU containing a BACnet-Confirmed-Request to the elevator device in which the service-related data indicates the elevator should stop immediately. Because the lighting device is in the subnet, it is trusted whenever authenticity checks are performed, hence the attacker is able to bypass this security mechanism. The elevator accepts the request, sends a BACnet-Simple-ACK, and stops immediately.

Attacks specific to BACnet/IP

Standard Non-conformance. We start by simply listing the vulnerabilities which are tolerated by the standard. We distinguish the following terms, related to the packets: compliant traffic fulfill the requirements given by the standard and non-compliant traffic contain packets that do not conform to the standard, e.g. malformed packets. Malicious packets are defined as packets designed to exploit a threat. Malicious packets can either be compliant or not. We present the following two examples to illustrate:

1. Network Mapping: An attacker is able to map the network with standardcompliant messages like Who-is requests. Additionally, he is able to send NPDUs containing application-specific APDU messages to probe the network. The messages with reachable destination addresses are always forwarded by the BBMD to the corresponding BACnet devices [START_REF]ASHRAE: Proposed Addendum ai to Standard 135-2012, BACnet -A Data Communication Protocol for Building Automation and Control Networks[END_REF]. If a device understands the service-related data contained in the payload, it gives a valid response, otherwise the device returns an error. On getting a response, the attacker knows which kind of devices can be addressed, e.g. fire alarm, HVAC or a door. As all BACnet devices send responses, he is additionally able to infer where (i.e. in which subnet) a device is located since the requests and responses contain the destination and source addresses. 2. Flooding Attack : In this case, we consider the malformed packets, i.e. each packet must possess at least one incorrect bit, according to the standard, either in NPDU or APDU. Since BACnet devices do not drop the packets but instead try to accept and process any request, the incorrectly set bits in NPCI and APCI pose a threat to them. Thus, an attacker can break a device by sending a flood of identical or different packets, making the number of packets received by the device far higher than normal. As a consequence, this can cause a denial-of-service, or force unintentional behavior by the device.

Vulnerable protocol design. By analyzing the protocol structure of BACnet and behavior of devices during communication procedure of certain messages, we categorize the following attacks.

1. Smurf Attack : In BACnet, if an attacker is able to modify the source (SADR and SNET) at the network layer, he will be able to spoof the address of broadcast requests and can cause a denial-of-service for selected BACnet devices. A smurf attack on BACnet is feasible as many BACnet devices are either old (BAS hardware is seldom altered over decades) or possess substantially lower processing capabilities than today's desktop computers and smart phones. 2. Router Advertisement Flooding: A similar attack is possible if an attacker is able to spoof a target device's source address and source network (SADR and SNET) to send a Who-is-Router-to-Network message (requesting a router advertisement for a given network). The result is that the target will receive router advertisements from all the routers in the local network. If the attacker repeats this procedure and sends too many repeated messages, the target is likely to receive more responses in a time window than it can normally handle, causing a denial-of-service. 3. Traffic Redirection: An attacker can spoof I-Am-Router-to-Network [START_REF] Čeleda | Flow-Based Security Issue Detection in Building Automation and Control Networks[END_REF] or Router-Available-to-Network messages, i.e. messages indicating the availability of a router, with the goal to redirect selected traffic over itself to gain confidential monitoring data (e.g., presence sensor data of a given room to plan a physical break-in [START_REF] Wendzel | The Problem of Traffic Normalization in a Covert Channel's Network Environment Learning Phase[END_REF]). 4. Re-Routing DoS, Type 1 : To cause a message flood on a router R or a BBMD, an attacker can broadcast spoofed I-Am-Router-To-Network messages to the network using the source address of R. Therefore, all possible destination network addresses can be used as a parameter for the router advertisement. This attack forces R to handle all responses to the I-Am-Router-To-Network message and, moreover, forces R to handle all remote traffic. 5. Re-Routing DoS, Type 2 : If the target device of the Type 1 attack is not a router, an attacker can redirect all the traffic for remote networks to a device incapable of forwarding messages, thus, isolating the communication of a subnet. The scenario is similar to the one where the victim's address can be spoofed in a Router-Available-to-Network message. It is important to mention that broadcast floods in BACnet networks can also be caused by devices which are not configured properly. At least three examples from practice are known [START_REF] Szlósarczyk | Towards Suppressing Attacks on and Improving Resilience of Building Automation Systems -an Approach Exemplified Using BACnet[END_REF]: i) the wrong setup of layer two switches that can lead to loops;

ii) the use of multiple broadcasting BBMDs in a chain without a broadcastlimiting router device in the chain; iii) the combination of BACnet/Ethernet ISO 8802-3 and BACnet/IP routers within the same infrastructure configured to use the same UDP port (leads to permanent broadcast exchanges between the two layers).

A Snort-Based BACnet Normalizer

We implemented a Snort-based normalizer extension capable of normalizing BACnet/IP traffic based on a configuration file. Supporting BACnet/IP allows extending our work to non-IP-based data link-layer protocols used by BACnet. The Snort extension includes countermeasures for each discussed attack vectors. The rules serve to remove ambiguities within the traffic in order to achieve compliant traffic.

Standard conformity

Ensuring robustness for the protocol stacks of BACnet devices is essential as firmware is seldom updated. Therefore, malformed packets violating the rules of the BACnet standard must be modified or discarded to achieve specificity. We list countermeasures in the form of normalization rules for the variants of malformed packets which succeed in compromising a BACnet device or the whole network, as mentioned in Sect. 4. The rules are split into five categories: NPCI field, BACnet non-security message types, BACnet security message types, APCI field, and the handling of BACnet priority messages.

NPCI field. Being an ever present component of a BACnet NPDU, the NPCI field including the NPCI control octet (CO) can always be normalized. Reasons to DROP messages:

1. Protocol Version Number != 0x01 2. DNET = 0, or SNET = 0, or SNET = 0xFFFF 3. Multicasts and local broadcasts with DNET=0xFFFFFFFFFFFF using ISO 8802-3, DNET=0x00 using ARCNET or LonTalk, DNET=0xFF using MS/TP 4. Bit 3 of CO is 1 and SLEN = 0 5. Unicast message with DNET = 0xFFFF

Reasons to MODIFY messages:

1. Set DLEN = 0 and DADR=0 if the message is a remote broadcast 2. Set bits 6 and 4 of CO to 0 BACnet Non-Security Message Types. As explained in Sect. 3, bit 7 of the NPCI control octet indicates whether a BACnet message represents a network layer message or an APDU. Table 1 shows the possible network layer message types. We determined the following normalization rules for non-security network layer message types. We DROP the message, if the message type is any of the following: 1. 0x02, 0x03, 0x08 or 0x13, and 4 or more bytes follow the type field 2. 0x01, 0x04 or 0x05, and an odd number of bytes follows the type field 3. 0x06 or 0x07, and more than 4× NUMBER OF PORTS + Sum of all PORT INFO LENGTHs bytes follow the type field 4. 0x00 or 0x09, and more than 2 bytes follow after message type field 5. 0x00: Limit the number of messages to m per second 6. 0x01 and the message is not transmitted with a broadcast MAC 7. 0x12 and the message is not transmitted with a local address, or if Hop-Count > 0, or if SADR is the same during n minutes 8. 0x13 and SNET/SADR or DNET/DADR is set or the message is sent to a local unicast address

Parameters m and n are configurable and depend on the particular hardware used (for example, in collaboration with industry partners we determined m = 180 as a reasonable value).

BACnet Security Message Types. We define rules for security messages as stated in [START_REF]ASHRAE: Proposed Addendum ai to Standard 135-2012, BACnet -A Data Communication Protocol for Building Automation and Control Networks[END_REF]. Error messages in each case should always be sent signed-trusted. We DROP the message, if the message type is any of the following:

1. 0x0A, 0x0E, 0x0F or 0x11, and the message is broadcast 2. 0x0A and more than 9 bytes follow the type field 3. 0x0B and more payload is transferred than specified 4. 0x0C and (a) the RESPONSE CODE (RC) is 0x06 and the length of RESPONSE SPECIFIC PARAMETERS is > 4, or (b) RC=0x07 and > 2, or (c) RC=0x0E and is even and the first byte is not 0x00, or (d) RC=0x0F and > 2, or (e) RC=0x15 and > 1, or (f) RC=0x16 and > 3, or (g) RC=0x17 and > 2, or (h) RC=0x18 and > 1 5. 0x0D and more than 19 bytes follow the type field 6. 0x0E and more than 21 bytes + bytes of keys follow the type field 7. 0x0F and more than 1 byte + bytes of keys follow the type field

We MODIFY the messages as follows:

1. Set bit 2 of CO to 1 if the type is 0x0A, 0x0D, 0x0E, 0x0F or 0x11 2. Set bit 2 of CO to 0 if the type is 0x0C or 0x10 APCI field. Whenever bit 7 of the NPCI control octet is 0, the content of the NSDU is an APDU, in which case the APCI field is present and can thus be normalized. Therefore, we implemented additional normalization rules. We MODIFY the messages as follows (cf. Fig. 3):

1. Set the first bit in PDU Type to 0 2. Set bits 7 and 8 of APCI to 0 if PDU Type is 0 3. Set bits 4 -7 of APCI to 0 if PDU Type is 1, 2, 5 or 6 4. Set bits 6 and 7 of APCI to 0 if PDU Type is 3 5. Set bits 4 and 5 of APCI to 0 if PDU Type is 4 6. Set bits 4 -6 of APCI to 0 if PDU Type is 7

Handling of BACnet Priority Messages. BACnet allows assigning each message a priority [1, pp. 68]. The priority is indicated by bits 1 and 0 within the NPCI control octet (11=Life Safety, 10=Critical Equip, 01=Urgent, 00=Normal). The highest possible priority of a packet is the life safety message and can be handled in a prioritized way by the receiving devices. However, in practice this feature is rarely used. We aim to introduce normalization for packets of all priority levels if they are not well-formed according to the ISO standard [START_REF]2012 Building automation and control systems -Part 5: Data communication protocol[END_REF]. Nevertheless, we must take into account that not all malformed packets are caused by an attacker, and that dropping a life safety message can result in significant side-effects if the message is not delivered but contains life-essential information. Therefore, we require that life safety messages must be modified (in order to match compliant NPDUs according to the standard as closely as possible) and always forwarded, and should never be dropped. We are aware of the fact that an attacker could explicitly take advantage of such a rule. In order to mitigate such attacks, one could require that BACnet messages sent with life-safety priority MUST always have a trusted level, i.e. they must be either encrypted or physically secured according to [START_REF]ASHRAE: Proposed Addendum ai to Standard 135-2012, BACnet -A Data Communication Protocol for Building Automation and Control Networks[END_REF], so that the receiving device is aware of the sending device. Life safety messages not encoded this way would be dropped. This approach, however, requires the support in the devices, which is not always possible.

Prevention of Network Covert Channels

The covert storage channels that an attacker could embed in the reserved bits of the BACnet NPDU and APDU are disabled, as the normalizer clears these bits. It is important to mention that other covert channels (especially timing channels) cannot be eliminated with this approach and that many additional hiding techniques for network covert channels are available. To counter additional covert channels, extensions for caching packets before forwarding them would be required, in order to limit the capacity of covert timing channels.

Closing Protocol Security Flaws

Unconstrained broadcasting in BACnet networks is a problem and allows for a wide spectrum of attacks, as outlined in Sect. 4. In order to prevent flooding and spoofing attacks, the appropriate limits for broadcast messages per time interval must be defined. These limits depend on the particular BACnet devices and are thus vendor-specific. In one empirical study, performed in co-operation with a vendor of BACnet products, we measured that most tested BACnet devices cannot process more than 180 messages per second.

BACnet Testbed

Our test environment is implemented using the open source BACnet stack (available at http://bacnet.sourceforge.net) and the virtual machines, each representing multiple BACnet devices (see Fig. 5).

Linux VM 1 (Sender )

Fuzzer + BACnet Stack non-compliant -----------→ BACnet test traffic Linux VM 2 (Normalizer ) Snort-BACnet compliant ----------→ BACnet test traffic Linux VM 3 (Receiver )
Wireshark + BACnet Stack Fig. 5. BACnet testbed for evaluating the Snort extension [START_REF] Szlósarczyk | Towards Suppressing Attacks on and Improving Resilience of Building Automation Systems -an Approach Exemplified Using BACnet[END_REF].

We setup the testing environment using three virtual machines (VMs). VM 1 represents the attacker who sends non-compliant BACnet traffic using the fuzzer. The messages are first examined by the normalizer (VM 2) before they are forwarded to the virtual BACnet device (VM 3). The destination host VM 3 monitors the received packets using Wireshark.

The fuzzer is implemented using the Scapy packet manipulation tool [START_REF] Biondi | the Scapy community: Scapy Documentation[END_REF]. It sends invalid and malformed packets to our test system in order to measure the behavior and the performance of the test system. The fuzzer follows the rules related to the structure of the messages as described in the ISO standard. To simulate the denial-of-service scenarios we implemented the packet sending in C, thus achieving very high packet send rates (upwards of 800,000 packets per second).

The normalizer is created as an extension of the existing Snort [START_REF]Snort -open source network intrusion prevention system and network intrusion detection system[END_REF] code with our normalization rules for BACnet messages. Our extension is able to recognize BACnet messages which are sent through UDP over IPv4. Each byte of the NPDU and APDU can be analyzed in order to decide whether to forward, drop or modify each packet according to a predefined rule set.

Evaluation and Future Work

The purpose of implementing the testbed is to verify the correctness and the performance of the Snort-based normalizer by testing the prevention of attacks (described in Sect. 4). To achieve this, we divided the BACnet/IP packets into two sets, for each normalization rule (rules described in Sect. 5). The first set contained non-compliant and malformed packets and the second set contained compliant and legitimate packets. We created at least one malformed packet for each normalization rule individually. Each set was further subdivided into various subsets of different message types. We created different unit and generic test cases to examine the behavior of packets from both sets.

As per the test environment setup, the messages were sent from VM 1 to VM 3. For generic testing, we transmitted the messages using a fuzzer which has the capability to send thousands of messages of a particular message type at a time. This helps to evaluate the performance of the system in handling flooding of messages. We tested scenarios with between 10,000 and 100,000 messages. By using Wireshark on the destination VM (VM 3), we observed that the non-compliant messages were either dropped/blocked or modified correctly, and compliant messages were transmitted to the destination without any interruptions, so that all the received packets were handled as stated in Sect. 5. We carried out this scenario (as stress-testing) to measure performance of the destination, VM 3 -the virtual machine representing the attacked BACnetwith and without a preceding normalizer. We flooded the device with a various numbers of malformed packets. Without the normalizer, the target device was unable to cope with the traffic. When the normalizer was enabled, none of the malformed packets reached the device. During the test, the CPU load on the normalizer VM (VM 2) was below 65% at all times.

For unit testing, we created 48 non-compliant test messages for different message types. Each packet was created to test the normalization rules laid down in Sect. 5. We also created 45 compliant test messages. These test messages were sent individually to test the behavior of the normalizer VM 2. Our tests showed that the normalizer was clearly able to differentiate between compliant and non-compliant traffic and performed necessary actions whenever required before forwarding packets to the destination VM 3.

Our future work will focus on the problem of detecting abnormal behavior of infected or exploited BACnet devices. Čeleda et al. [START_REF] Čeleda | Flow-Based Security Issue Detection in Building Automation and Control Networks[END_REF] introduced a network flow-based detection tool and provided a theoretical comparison to determine anomalies in BACnet control flows using their network monitor tool. The authors were able to record key information in order to detect a flood. Prevention techniques, however, were not implemented in the tool. We plan to expand our Snort normalizer extension to include detection and prevention of abnormal traffic. By analyzing data collected from actual BACnet networks we will develop application-specific rules and create a state machine that can distinguish abnormal states from compliant ones. Furthermore, we plan to expand the normalizer to handle segmentation-based attacks by performing packet reassembly and caching within the normalizer.

Fig. 2 .

 2 Fig.2. BACnet NPDU format (left) and NPCI control octet (right). In NPCI control octet, Bit 7 indicates whether the NSDU contains a network layer message (bit is set) or an APDU (bit is unset). Based on[START_REF]2012 Building automation and control systems -Part 5: Data communication protocol[END_REF].

Fig. 3 .

 3 Fig. 3. BACnet APCI for Confirmed Request PDU (PDU Type = 0). From [1, p. 538].

Fig. 4 .

 4 Fig. 4. General Attacker model (left) and an attack through a controlled BACnet device (right).

  Is-Router-To-Network 0x0B * Security-Payload 0x01 I-Am-Router-To-Network 0x0C * Security-Response 0x02 I-Could-Be-Router-To-Network 0x0D * Request-Key-Update 0x03 Reject-Message-To-Network 0x0E * Update-Key-Set 0x04 Router-Busy-To-Network 0x0F * Update-Distribution-Key 0x05 Router-Available-To-Network 0x10 * Request-Master-Key 0x06 Initialize-Routing-

Table 1 .

 1 BACnet Network Layer Message Types. Security message types are marked with

* .

Table 0x11

 0x11

		*	Set-Master-Key
	0x07 Initialize-Routing-Table-Ack	0x12	What-Is-Network-Number
	0x08 Establish-Connection-To-Network	0x13	Network-Number-Is
	0x09 Disconnect-Connection-To-Network	0x14-0x7F Reserved for use by ASHRAE
	0x0A * Challenge-Request	0x80-0xFF Available for vendor proprietary messages