dataesr/scientific-paragraphs-categorization huggingface dataset:
The coldwire is calibrated from voltage to degrees Celsius in post-flight analysis using a co-located commercial sensor (ADS1118) that has much slower frequency response than the coldwire (time constant about 2 s at 14 ms -1 airspeed) but has a specified accuracy better than ±1 °C over -40 to +125 °C range (Table  2 ). The DataHawk sensor module also contains a commercial humidity sensor (Honeywell HIH4031) that is relatively slow (time constant about 5 s at nominal flow rates). The factory calibration using temperature compensation is used to produce relative humidity (RH) that is specified to ±8% over the 0-100% RH range and the -40 to +85 °C temperature range (Table  2 ). The RH signal is sampled at 10 Hz. Velocity of the flow relative to the DataHawk is measured by a Pitot-static tube and differential pressure sensor (MS4525DO DS5AI001DP), mounted at a height of 3 cm above the vehicle to project into the free stream above the aerodynamic boundary layer.
In this overview, we will describe some preliminary results mostly obtained from UAV 5 and UAVs 12 and 17, whose flight paths are shown in Fig. 3. These results demonstrate the good performance of the MU radar in range imaging mode and the potential of UAV measurements. Future work will focus on specific aspects of these and other flights, which can be studied from the datasets. Analyses of some of the data and syntheses of the results are presented in  Luce et al. (2017)  and (Luce H, Hashiguchi H, Kantha L, Lawrence D, Tsuda T, Mixa T: On the performance of the range imaging technique using UAVs during the ShUREX 2015 campaign, submitted). UAV 12, on June 9, 2015: detection of UAVs by the MU radar Because the UAVs were flying close to the radar antenna array, they could be detected and monitored, mostly by side lobes of the radar beam pattern.
Radar echo contaminations by UAVs are obviously a drawback when comparing atmospheric data but can also be an advantage. They provide the opportunity to calibrate the radar altitude to the altitude provided by the onboard sensors and to synchronize the two datasets. Figure  4c  shows an example of high-resolution, time-height image of echo power at vertical incidence on June 9, between 16:30 and 18:00 LT during the UAV 12 flight. Echoes due to the reflection from the UAV appear as a single, thin, and continuous line in the image below the altitude of 3. 0 km ASL from ~17:00 LT until ~17:45 LT. This is despite the presence of strong atmospheric echoes (the observed atmospheric structures for this flight will not be discussed here). Therefore, it is clearly evident, as expected from theoretical considerations and from earlier applications, that the range imaging processing with the Capon method does not produce any "ghost" echo, i.
8 °C in the DH and CW temperature data, compared to iMET temperature data and -15% in the DH humidity data, compared to the iMET humidity data. However, apart from these biases, the overall trend appears to be reproduced well by all sets of sensors. Figure  7  shows temperature and relative humidity profiles during UAV 17. The blue curve corresponds to the descent D1, the red curve to ascent A2, and the black curve to descent D2. The initial ascent of the UAV borne by the balloon has been omitted for clarity. Also, in the top two panels, the profiles have also been offset to the right by 5 °C for temperature and 50% for humidity. In the top left panel, the leftmost profile refers to the iMET data, with the DH profile offset to its right. This is followed by the profile to its right. In the top right panel, only the iMET and DH humidity profiles are shown (there is no corresponding third high-resolution humidity profile).
Once again, the agreement between the various sets of sensors is quite good, in general, except for the offsets mentioned above. When properly calibrated, the three sensor sets capture trends in the data quite well, with slight variations between different datasets highlighting the importance of synergistic use of the instruments to determine the most accurate measurement when disagreements arise. The CW temperature has a much smaller time constant than the iMET temperature (see Table  2 ) so the radiosonde temperature minima from 2400 to 2700 s and 3000 to 3300 s (see Fig. 6 ) are likely artifacts, since they do not occur in the higher-fidelity CW data. The iMET humidity sensor has a smaller time constant than the DH sensor, so the iMET humidity minima from 3700 to 4000 s are likely real, since the DH humidity sensor cannot respond as quickly to changes in the ambient air as iMET humidity sensor can.
In cases where the iMET temperature and humidity sensors experience simultaneous excursions that do not occur in the DH data, it is likely to be an error in both radiosonde sensors, since they are coupled on the same sensor array and occupy the same circuitry. The GPS altitude has higher "local" uncertainty than the pressure altitude, making pressure altitude the more accurate measurement when the two disagree over the short term. However, pressure altitude has longterm errors over large altitude ranges that GPS does not exhibit. Relative benefits of different sensor datasets have therefore been used to produce a more accurate composite set of measurements. The iMET temperature exhibits spikes (e. g. , at 2. 5 and 3. 2 km, Fig. 7 ), perhaps due to the impact of water particles because of its exposed location on the UAV.
The blue curve corresponds to descent D1, the red curve to ascent A2, and the black curve to descent D2. The initial ascent (A1) borne by the balloon has been omitted for clarity. Also for clarity, the profiles have been offset to the right by 5 °C for temperature and 50% for humidity. In the top left panel, the first profile refers to the iMET sensor data, with the DH profile offset to its right, which is followed by the CW profile to its right. In the top right panel, the relative humidity profile is from the iMET sensor followed to its right by that from the DH sensor. The bottom three panels show composite profiles of temperature (bottom left) and relative humidity (bottom right) from the three sets of sensors and the potential temperature derived from them (bottom middle). Once again, the blue curve corresponds to descent D1, the red curve to ascent A2, and the black curve to descent D2 cross sections of a given parameter are made from radar data (such as echo power in Fig.
Acknowledgements LK, DL, and TM thank the  Japanese Society for Promotion of Science (JSPS)  and  RISH  for providing the funding to participate in the campaign as well as to modify the DataHawk to carry the iMET sonde. The stays of HL and RW were funded by  CNRS PICS. The hospitality of RISH personnel and director  Prof. Tsuda  to their visitors is exemplary. Thanks to  Abhiram Doddi  for the help with the analysis of UAV data.
Software-based approaches for search over encrypted data are still either challenged by lack of proper, low-leakage encryption or slow performance. Existing hardware-based approaches do not scale well due to hardware limitations and software designs that are not specifically tailored to the hardware architecture, and are rarely well analyzed for their security (e. g. , the impact of side channels). Additionally, existing hardware-based solutions often have a large code footprint in the trusted environment susceptible to software compromises. In this paper we present HardIDX: a hardware-based approach, leveraging Intel's SGX, for search over encrypted data. It implements only the security critical core, i. e. , the search functionality, in the trusted environment and resorts to untrusted software for the remainder.
HardIDX is deployable as a highly performant encrypted database index: it is logarithmic in the size of the index and searches are performed within a few milliseconds rather than seconds. We formally model and prove the security of our scheme showing that its leakage is equivalent to the best known searchable encryption schemes. Our implementation has a very small code and memory footprint yet still scales to virtually unlimited search index sizes, i. e. , size is limited only by the general -non-securehardware resources.
INTRODUCTION Outsourcing the storage and processing of sensitive data to untrusted cloud environment is still considered as too risky due to possible data leakage, government intrusion, and legal liability. Cryptographic solutions such as Secure Multiparty Computation (MPC)  [10, 35]  and in particular Fully Homomorphic Encryption (FHE)  [31]  offer high degree of protection by allowing arbitrary computation on encrypted data. However, MPC and FHE schemes are still impractical for adoption in large distributed systems  [21, 32]. Moreover, there are a number of useful applications that only require a small set of operations rather than the universal solutions offered by MPC/FHE. A prime example of such operations is the search and retrieval in databases without the need to download all data from the cloud.
For searching over encrypted data, different cryptographic schemes have been proposed such as propertypreserving encryption  [9, 12] , or functional encryption  [14]  and its special case searchable encryption  [24, 42, 49, 65]. In this context, performing efficient and secure range queries are commonly considered to be very challenging. CryptDB  [59]  resorts to orderpreserving encryption for this purpose which is susceptible to simple ciphertext-only attacks as shown by Naveed et al. [54]. As we will elaborate in our related work section, many schemes for search over encrypted data supporting range queries require search time linear in the number of database records. Recently, schemes with polylogarithmic search time, based on an index structure, have been proposed  [25, 28, 49]. Nonetheless, the first scheme in  [49]  is not yet practical, because it applies pairing-based cryptography and also leaks sensitive information about the plaintext, namely the order of the plaintexts.
In particular, TEEs often have limited resources and need to utilize untrusted resources of their host system. For instance, in case of limited memory it swaps out data to untrusted memory or storage. Hence, in order to achieve comprehensive security, information leakage through those channels has to be considered and taken care of. Previous solutions for isolating databases with SGX load and execute the entire unmodified database management system (DBMS) into an enclave  [6, 7] , but they do not consider possible side channels occurring from the use of untrusted resources as well as resource sharing between TEE and untrusted host. In particular, previous works do not formally consider information leakage. Additionally, they do not scale well due to the limited memory size of SGX's enclaves and the large footprint of the code they require in the TEE.
Our goal and contribution. In this paper, we present an efficient scheme for search over encrypted data using SGX that can directly be deployed as a database index. We utilize SGX's protection characteristics to achieve an outstanding tradeoff between security, performance and functionality. The currently fastest softwarebased schemes that support range queries are  [25]  and  [28]. Our solution significantly improves over these approaches in terms of performance and storage. Compared to the latest hardware-based schemes  [6, 7] , we improve in terms of security and scalability. Our scheme organizes data in a B + -tree  [8]  structure that is frequently used for databases indexes in most database management systems (DMBSs)  [1, 60] , for data access  [2]  as well as for file systems  [33, 64]  to vastly improve the performance of search operations.
Our solution support searches for single values and value ranges. Additionally, our solution can be adapted easily to many other database (search) operations. We provide two constructions of our search scheme differing in the management of the B + -tree. The tree is either loaded and handled as a whole inside the enclave, or is loaded in an on-demand fashion (see  Section 5). Although the tree does not directly leak information about the content of the (encrypted) index, it can leak access patterns information observed during query processing. For both constructions we show the access pattern leakage with respect to side channels observable by an attacker. Furthermore, we show that the leakage of both construction is almost the same differing only by their granularity. We implemented and extensively evaluated both constructions on SGX-enabled hardware (see Section 6 and Section 7).
The first construction loads the whole B + -tree structure in an SGX enclave and performs search queries thereafter. However, it is not possible to load arbitrarily large structures into an enclave, as enclave size is limited. We will detail this in Section 6. Our second construction only loads those data in SGX that is currently needed to process a search query. It has a very small code and memory footprint in the TEE compared to other hardware-based approaches  [6, 7]. Additionally, it scales to arbitrary index sizes, as memory usage in the enclave is constant and untrusted resources are used to store the database itself. Our main contributions are as follows: • Our scheme has logarithmic complexity in the size of index and searches are performed within a few milliseconds. • We formally model and prove our scheme secure showing that its security (leakage) is comparable to the best known searchable encryption schemes.
Intel Software Guard Extensions (SGX) SGX is an extension of the x86 instruction set architecture (ISA) introduced with the 6th Generation Intel Core processors (code name Skylake). We now present a high level overview of SGX's features utilized by HardIDX (see  [4, 22, 37, 39, 41, 51]  for more details). Memory Isolation. On SGX enabled platforms, programs can be divided into two parts, an untrusted part and an isolated, trusted part. The trusted part, called enclave in SGX terminology, is located in a dedicated portion of the physical RAM. The SGX hardware enforces additional protection on this part of the memory. In particular, all other software on the system, including privileged software like OS, hypervisor, firmware and code in system management mode (SMM) cannot access the enclave memory.
The latter is called Enclave Page cache (EPC) and is about 96 MB according to our evaluations. The SGX memory is reserved in the early boot phase and is static throughout the runtime of the system. As the number of enclaves which may be loaded and executed in parallel is virtually unlimited, the OS has to manage the enclave memory dynamically. The OS can allocate (parts of) the memory to individual enclaves and change these allocation during the runtime of the enclaves. In particular, the OS can swap out enclave pages. SGX ensures integrity, confidentiality and freshness of swapped-out pages. Attestation. SGX has a remote attestation feature which allows to verify the correct creation of an enclave on a remote system. During enclave creation the initial code and data loaded into the enclave are measured.
HardIDX Overview The high level design of our solution is shown in Figure  1a. The design involves three entities: the client (who is the data owner and therefore trusted), the untrusted SGX enabled server and the trusted SGX enclave within the server. Initially, a client prepares its data values (abbreviate with values in the following) by augmenting it with (index) search keys. The values are stored at pseudo-random position. The keys are then inserted into a B + -tree and the storage order of all nodes is also pseudo-random. The tree and values are linked by adding pointers to the leaves of the tree identifying the random position of the corresponding values. A value can be any data such as records in a relational database or files/documents in other database types. The client then encrypts all nodes of the tree with a secret key SK k and all data values with SKv.
This list of pointers, representing the search result, is passed to the untrusted part (see step 6 ). The untrusted part learns nothing, except for the cardinality of the result set, from this interaction, because the values are stored in a randomized order. The result of the index search can be processed further, e. g. in combination with additional SQL operators, in the SGX enclave at the server. In order to complete the end-to-end secure search we assume that the server uses the pointers, in step 7 , to fetch the encrypted values from untrusted storage and sends them to the client. The client uses SKv to decrypt the received files. Notably, the plaintext data values are never available on the server. They are encrypted with strong standard cryptography methods  2  and never decrypted on the server, not even inside the SGX enclave.
Assumptions and Attacker Model We assume a system which provides SGX (or any TEE with capabilities similar to SGX). In particular, code and data inside the TEE are protected with respect to their integrity and confidentiality. We further assume that the TEE provides means to establish a secure channel to the client which allows secure communication and secure provisioning. Our attacker model is illustrated in Figure  1b. Due to SGX's protection, the attacker cannot directly access the enclave. However, side channels exist through, which the attacker could potentially extract sensitive information. In particular, the attacker aims to learn the structure of the B + -tree which represents the order relation between the indexed data. We assume the attacker has full control over all software on the system running HardIDX.
B + -tree A B + -tree is a balanced, n-ary search tree. So called search keys are utilized to index values. For instance, unique staff ids are used to find the corresponding database record (see Figure  2 ). An index could also be built for other information, e. g. , the salary, and a B +tree is able to retrieve all records below or above a limit or between limits. We abbreviate the search keys as keys throughout this paper and clearly differentiate all other key types (e. g. , cryptographic keys) if ambiguous. Three node types are differentiated in a B + -tree: the root node, internal nodes and leaf nodes. Every node x contains x. #k keys that are stored in a nondecreasing order: x. k1 ≤. ≤ x. k x. #k. At every inner node x (including the root if not the only node), the keys separate the key domain into (x.
Construction 1 We describe our first correct (according to Definition 2) and secure (according to Definition 3) construction in this section. The guiding idea of the construction is that the entire data should be stored and processed inside the enclave. The client constructs the B + -tree locally, encrypts the B + -tree structure and the values with SK k and SKv, respectively, and sends both to the cloud provider. The SGX application gets deployed to an SGX capable server at a cloud provider (see Section 2. 1 for details). Software measurement is used for remote attestation, i. e. , to prove to the client that the correct software is deployed on an SGX enabled CPU. During the deployment, the application reserves an SGX protected memory region. A secure transfer protocol between client and server is used to deploy SK k inside the enclave.
Thus SK k is only known by the enclave's process and the client. The cloud provider and all other processes cannot access this key at any point in time. The next step is to load the B + -tree structure from an untrusted to the isolated memory region and use SK k to decrypt the tree nodes. It is important to note that the tree is still protected, because all data inside the enclave is secured by SGX. The enclave is then ready to receive search queries from the client. Since the values can be very large, the data transfer to the enclave can cause a severe performance overhead. We, therefore, store the values outside of the enclave. A second reason is the limited size of protected memory inside an enclave. Storing the values outside of the enclave has no security implications as the values are encrypted with an authenticated IND-CCA secure encryption scheme and they are stored in a randomized order.
Therefore, the results are consistent for different requests of the same range and also for queries of distinct or overlapping ranges. Furthermore, the number of result pointers matches and the pointers are consistent, because ∆(s, T, R, t) is unambiguous. The values pointed on are indistinguishable, because they are protected by IND-CCA secure encryption. Cloud computing enables the fast and cost-effective processing of large amounts of data. Unfortunately, Construction 1 suffers from the substantial problem mentioned before: the memory reserved for SGX is limited to 128 MB, and only about 96 MB can be used for data and code. SGX supports a larger enclave size, but enclave pages have to be swapped in and out in this case. Our evaluation (see  Section 7)  shows that even 50,000,000 values are possible.
Active attacker Construction 1 and 2 are secure and correct for a passive attacker, but our overall goal is to enable the outsourcing of data to untrusted cloud providers. Therefore, it is important to consider active attackers. This attacker type tries to thwart the correctness and tries to gain additional sensitive information by not following the defined protocol. We omit concrete definitions of correctness and CKA2-HW-security under a active attacker, because they are easily deducible from Definition 2 and Definition 3. In the following, we consider only Construction 2, but the arguments and techniques can be applied to Construction 1 with minor modifications. Attack vectors. We identified two basic attack vectors that cover a wide range of possible attacks. Firstly, the attacker can try to attack the protection mechanisms of SGX to gain insights about data and algorithm execution not under his control.
We rely on SGX's protection mechanism that guarantees security and correctness under an active attacker. However, as defined in our attacker model (see Section 3. 2), we consider various side channels. Protection mechanisms against these are implementation details and thus described in our implementation section (Section 6). Secondly, the active attacker can try to influence the data and protocol execution that is under his control. Namely, all encrypted nodes, encrypted values, encrypted tokens and the HSBT2_SearchRange algorithm. He can do this to gain additional sensitive information or to prevent the client from getting the correct result. In this section, we present arguments and protection mechanisms that address this second attack vector. For now, we assume that there is a mechanism that guarantees the following to the client: if it gets a result, all results in the response match the query and the response contains all matching results.
Again, the security of tokens and the prevention of modifications and additions is provided by the authenticated IND-CPA secure encryption scheme. A replay attack does also not give any additional information to the attacker as the tree is static and the leakage stays the same for a replayed token. The correctness could only be influenced by a denial of service (DoS) attack by dropping tokens, but DoS is out of scope according to our attacker model. Unprotected algorithms. HSBT2_SearchRange is the only remaining untrusted part under control of the active attacker. There is only a fixed set of deviations from the protocol that do not lead to a DoS. As explained before, all additional or modified static or dynamic data is directly noticeable by the enclave, which can simply reject further processing.