dataesr/scientific-paragraphs-categorization huggingface dataset:
Relay-Resistance in EMV Relay attacks are particularly relevant in contactless-payment systems. Indeed, no PIN code or other payee-originating input is requested with such payments. Moreover, most contactless payment cards rely on ISO 14443, which is a standard available in most of today's smartphones. Consequently, performing a relay attack between a payment terminal and a payment card is as simple as uploading an app on a smartphone  [567]. Indeed, using off-the-shelf smartphones and some in-house Android software, this relay threat was exhibited in practice by Chothia et al. [141]  against the EMV (Europay, Mastercard and Visa) contactless-payment protocol; this is the most wide-spread type for contactless payments. In their work, Chothia et al. also introduced a countermeasure to mitigate their own relay attack.
Data Preprocessing In the data preprocessing phase, the aim is to prepare the data in a way to increase the performance of side-channel analysis. There are several papers considering various data augmentation techniques in order to artificially generate measurements so as to increase the size of the profiling dataset. Cagli   augmentation techniques they call Shifting and Add-Remove  [122]. They use convolutional neural networks (CNN) and find data augmentation to significantly improve the performance of CNN. Pu et al. use a data augmentation technique where they randomly shift each measurement in order to increase the number of measurements available in the profiling phase  [489]. They report that even such simple augmentation can effectively improve the performance of profiling SCA. Picek et al.
experiment with several data augmentation and class balancing techniques in order to decrease the influence of highly unbalanced datasets that occur when considering HW/HD models  [478]. They show that by using a wellknown machine learning technique called SMOTE, it is possible to reduce the number of measurements needed for a successful attack by up to 10 times. Kim et al. investigate how the addition of artificial noise to the input signal can be beneficial to the performance of the neural network  [329].
Datasets When preparing the data for machine learning analysis, it is necessary to discuss the number of measurements, the number of features, and the number of classes (if known). Additionally, if the data come from different distributions, one needs to discuss those. If not all data from datasets are used, it is necessary to state how the samples are chosen and how many are used in the experiments. One needs to define the level of noise appearing in the data in a clearly reproducible way, e. g. , using the signal-to-noise ratio (SNR). Finally, if some feature engineering procedure is used, it needs to be clearly stated in order to know what features are used in the end.
Experiments Regarding the experiments, it is first necessary to discuss how the data are divided into training and testing sets. Then, for the training phase, one needs to define the test options (e. g. , whether to use the whole dataset or cross-validation, etc. ) After that, for each algorithm, one needs to define a set of parameter values to conduct the tuning phase. There are different options for tuning, but we consider starting with the default parameters as a reasonable approach and continue varying them until there is no more improvement. Naturally, this should be done in a reasonable way, since the tuning phase is the most expensive from the computational perspective and it is usually not practical to test all combinations of parameters.
Finally, we describe the use of our solution using an open source hardware/software trace acquisition platform that we have developed in our lab (FlexLeco project  [427] ) that consolidates the latest trends in trace collection tools and platforms. The rest of the chapter is organized as follows. In Sect. 9. 2, the major SCA categories and leakage assessment methodologies are described and evaluated according to the number of traces needed. In Sect. 9. 3 we overview existing open source and commercial trace collection platforms and toolsets, and the proposed trace collection approach is described. In Sect. 9. 4, we describe the use of the proposed approach on the FlexLeco project architecture, and discuss the benefits of the solution. In Sect. 9. 4 conclusions are provided.
Gradually the quality of the boards improved to such a degree that several of them found their way to the market for commercial use, with significant success. There is limited variety of commercial SCA boards, each with its pros and cons. The Cryptographic Engineering Research Group (CERG) presented the FOBOS board  [565, 566] , which consists of two FPGA's, one for handling control tasks and one for the implementation of the cryptographic algorithm. The FOBOS board contains a Digital Clock Manager that produces frequencies in the range of 31. 25 kHz up to 50 MHz for the Victim Board. The communication with the Control FPGA is performed through a software control loop that is responsible for transmitting the appropriate commands and the necessary data to the victim FPGA. The software loop is also responsible for the communication with the oscilloscope (currently supporting only Agilent oscilloscopes).
Also, the provided software loop in charge of data and command transmission to the Cryptographic FPGA is slow, oriented towards a specific algorithm with fixed key-length, and offers through a PC program very basic functionality only for a single trace capture per loop round. An attempt to remedy this issue was made in the IAMeter project, which is focused exclusively on developing an efficient control loop for commercial and custom FPGA board platforms (including the Sasebo-G and GII boards)  [307]. However, even this attempt can provide only a single trace collection per loop round, it is not capable of adjusting/controlling the DUT clock, and it relies heavily on PC-based configurations (including Python scripts along with MySQL databases queries) which slow the trace collection as a whole.
In some solutions, the control loop operations are implemented in hardware and are downloaded on a dedicated control FPGA that is physically connected to the DUT. This is done in the Sasebo/Sakura project and in some ChipWhisperer (NewAE) technologies, just to name some examples. Hardware, however, is not flexible and thus cannot be easily adapted to different algorithms or assessment techniques. Similarly, control loop functionality is partially migrated on dedicated control loop ASIC microcontrollers or microprocessors that operate alongside a PC in order to implement the DUT control in software. Such solutions lack speed when transmitting DUT test vectors to the DUT itself since PC usage is still needed. Therefore, it has become apparent that a different, updated approach to realize DUT control loops for SCA evaluation and leakage assessment is needed.
A Use Case of a Flexible and Fast Platform for DUT SCA Evaluation To showcase the applicability and effectiveness of the above-proposed three-step trace collection architecture and mechanism in action, we focus on the Flexible Leakage Collection (FlexLeco) project, which was recently published in  [427]. the FlexLeco project was designed to match the latest trace collection challenges and to introduce a unified mechanism for applying various trace collection scenarios. It provides an architecture that tries to blend the reconfigurability of Software Control loops with the speed of Hardware Control loops. Taking advantage of the latest trace collection boards that utilize schemes with two FPGAs (one acting as the Control Unit and the other as the Device Under Test), the project created two generic hardware interfaces that enable fast communication between the two FPGAs, and managed to include an embedded softcore processor inside the Control FPGA, which is in charge of the Control Loop during the execution of trace collection scenarios.
1 By doing so, the attacker/evaluator can use the API functions to create any SCA or leakage assessment scenario to be executed inside the softcore microprocessor, omitting the slow, PC-based software control loops. In that sense, the FlexLeco solution fully supports and favors the design phase of the proposed trace collection approach of this chapter and provides to an SCA evaluator all the tools required to design diverse and complex SCA evaluation experiments. The cryptographic interface on the cryptography FPGA side is primarily designed for testing specific security/cryptography hardware implementations. It is an open source HDL (Hardware Design Language) design that can be adapted to the DUT's cryptographic algorithm specifications during design time. By simply assigning appropriate values for five HDL generic parameters, the number of inputs, outputs and their bit length is adjusted to that of the DUT's algorithm.
Appropriate Selection of Tests The correlation between tests in a battery, and as a whole if the evaluation methodology involves multiple test batteries, must be considered. Statistical tests have a limited range of issues that they are able to identify in the target RNG. Test   [272]  batteries are intended to mitigate this issue by providing many statistical tests that evaluate different aspects of the target RNG, providing a broader analysis. Hernandez-Castro et al. identify a degree of correlation between tests in the Ent battery. The Ent battery is a simple set of tests included in most Linux distributions as a simple statistical testing tool  [568]. Ent includes tests for estimated entropy, compression, χ 2 , arithmetic mean, Monte Carlo π, and serial correlation. Bit and byte level tests can be run over target sequences.
Type-I: General purpose OS-based devices (e. g. , Linux-based). The Linux OS kernel is widely used in the embedded world. However, in comparison to the traditional GNU/Linux found on desktops and servers, embedded systems typically follow more minimalist approaches. For example, a very common configuration that can be found in consumer-oriented products as well as in Industrial Control Systems (ICS) is based on the Linux kernel coupled with BusyBox and uClibc.
Type-II: Embedded OS-based devices. These dedicated operating systems targeted at embedded devices systems are particularly suitable for devices with low computation power, which is typically enforced on embedded systems for cost reasons. Operating systems such as uClinux or FreeRTOS are suitable for systems without a Memory Management Unit (MMU) and are usually adopted on single-purpose user electronics, such as IP cameras, DVD players and Set-Top Boxes (STB). Type-III: Devices without OS-Abstraction. These devices adopt a so called "monolithic firmware", whose operation is typically based on a single control loop and interrupts triggered by the peripherals in order to handle external events. Monolithic firmware can be found in a large variety of controllers of hardware components, such as CD-readers, WiFi-cards or GPS-dongles.
Collecting Firmware Packages The environments in which embedded systems are deployed are heterogeneous, spanning a variety of devices, vendors, CPU/hardware architectures, instruction 187 sets, operating systems, and custom components. This makes the task of compiling a representative and balanced dataset of firmware packages a difficult problem to solve. The lack of centralized points of collection, such as the ones provided by software/app marketplaces, antivirus vendors, or public sandboxes in the malware analysis field, makes it difficult for researchers to gather large and well triaged datasets. Firmware often needs to be downloaded from vendor Web pages and FTP sites, and it is not always simple, even for a human, to tell whether or not two firmware packages are for the same physical device.
Firmware Unpacking Frameworks The main tools to unpack arbitrary firmware packages are: binwalk  [263] , FRAK  [161] , Binary Analysis Toolkit (BAT)  [558]  and Firmware. RE  [155]  (Table  11. 1 compares the performance of each framework): • Binwalk is perhaps the best known and most used firmware unpacking tool developed by Craig Heffner  [263]. It uses pattern matching to locate and carve files from a binary blob. Additionally, it also extracts some meta-data such as license strings. • FRAK is an unpacking toolkit first presented by Cui et al. [162]. It reportedly  1 supports a limited number of device vendors and models, such as HP printers and Multi-Function Peripherals (MFP). • The Binary Analysis Toolkit (BAT), formerly known as GPLtool, was originally designed by Armijn Hemel and Tjaldur software in order to detect GPL license violations  [269, 558].
To do so, it recursively extracts files from a binary blob and matches strings with a database of known strings from GPL projects and licenses. BAT also supports file carving similar to binwalk, as well as a very flexible plugin-oriented extension interface. Camera STL Linux ✗ ✓ ✗ ✓ Router Bintec - ✗ ✗ ✗ ✗ ADSL gateway Zyxel ZynOS ✓ ✓ ✗ ✓ PLC Siemens - ✓ ✓ ✗ ✓ DSLAM - - ✓ ✓ ✗ ✓ PC Intel BIOS ✓ ✓ ✗ ✓ ISDN server Planet - ✓ ✓ ✗ ✓ Voip Asotel Vxworks ✓ ✓ ✗ ✓ Modem - - ✗ ✗ ✗ ✓ Home automation Belkin Linux ✗ ✗ ✗ ✓ 55% 64% 0% 82% • Firmware. RE  [155]  extends BAT with additional unpacking methods and specific analyses to perform automated large-scale analyses. When released, it achieved a lower false positive rate when unpacking firmware compared to binwalk.
Configuration Analysis For a large majority of complex embedded devices (i. e. , those of Type-I as described in Sect. 11. 1. 5), while service configuration is stored within the file-system of the device, user-configurable information is often stored elsewhere-within a region of memory called Non-Volatile Random Access Memory (NVRAM) which retains its state between power cycles (similar to Flash memory in some ways). Many devices treat NVRAM as a key-value store and include utilities such as nvram-get and nvram-set, as well as dedicated libraries to get and set values stored there. On a router, for example, the current Wi-Fi passphrase and web-based configuration interface credentials, will often be stored within the NVRAM, which will be queried by software in order to facilitate the authentication of the device and its services.
Thus, a further step in the analysis of firmware is to identify the versions of software (both programs and libraries) it contains, and correlate those versions with known vulnerabilities (e. g. , CVE database). There are several possible approaches to perform this. For example,  [155]  use fuzzy hashing  [340, 507]  as a method to correlate files in firmware images. The effectiveness of the approach was demonstrated in several examples, in particular uncovering many IoT and embedded devices being so-called "white label" products. 2 Finally, machine learning can be used to identify firmware images  [157]  or to search for known vulnerabilities  [585].
HumIDIFy attempts to validate that binaries do not perform any functionality outside of what is expected of the type of software they are identified as. For example, HumIDIFy is able to detect a backdoor within a web-server taken from Tenda router firmware  4  that contains an additional UDP listening thread which executes shell commands provided to it (without authentication) as the root user. Stringer 5   [550]  attempts to locate backdoor-like behavior in Linux-based firmware. It automatically discovers comparisons with static data that leads to execution of unique program functionality, which models the situation of a backdoor providing access to undocumented functionality via a hard-coded credential pair or undocumented command. Stringer provides an ordering of the functions within a binary based on how much their control-flow is influenced by static data comparisons that guard access to functionality not otherwise reachable.
The authors demonstrate Stringer is able to detect both undocumented functionality and hardcoded credential backdoors in devices from a number of manufacturers. Firmalice  [528]  is a tool for detecting authentication bypass vulnerabilities and backdoors within firmware by symbolic execution. It takes a so-called security policy as input, which specifies a condition a program (or firmware) will exhibit when it has reached an authenticated state. Using this security policy, it attempts to prove that it is possible to reach an authenticated state by discovering an input that when given to the program satisfies the conditions to reach that state. To discover such an input, Firmalice employs symbolic execution on a program slice taken from a program point acting as an input source to the point reached that signals the program is in an authenticated state.
If it is able to satisfy all of the constraints such that a path exists between these two points, and an input variable can be concretised that satisfies those constraints, then it has discovered an authentication bypass backdoor (and a triggering input)-such an input will not be discoverable in a nonbackdoored authentication routine. Unfortunately, Firmalice requires a degree of manual intervention to perform its analysis, such as identifying the security policy, input points and privileged program locations. It is therefore not easily adaptable for large-scale analysis.
To this end, Cojocar et al. [150] , propose PIE, a tool to automatically detect parsing routines in firmware binaries. PIE utilizes a supervised learning classifier trained on a number of simple features of the LLVM IL representation of firmware components known to contain parsing logic. Such features include: basic block count, number of incoming edges to blocks, and number of callers (for functions). PIE provides a means to identify specific functions responsible for performing parsing within an input firmware package, or software component. Stringer  [550] , described in Sect. 11. 3. 2. 2, similarly provides a means of automatically identifying parser routines (for text-based input); in addition to identifying routines, it is also able to identify the individual (text-based) commands, processed by the parser.
Similarly, FIRMA-DYNE  [137]  presents an automated and scalable system for performing emulation and dynamic analysis of Linux-based embedded firmware. The general idea of both works is to crawl and then unpack firmware packages into minimal root filesystems (i. e. , rootfs) that can subsequently be virtualized and executed as a whole via "system emulation" (as opposed to "user emulation") using for example QEMU  [69]. The emulator is first used to start an architecturespecific emulation host OS, such as Debian for ARM or MIPS depending on the 197 architecture of the device whose firmware is being dynamically analyzed. Then the firmware root filesystem is uploaded to the emulation host OS, where its Linux boot sequence scripts are initiated, most likely in a chroot environment under the emulation host OS.
5-D Classification and Analysis of Privacy Risks From Sect. 12. 2 it can be derived that most of the efforts have been oriented towards the suggestion of measures to protect privacy (fighting against specific privacy issues). Also, some efforts have been devoted to the analysis and proposal of privacy principles and properties to be fulfilled. However, there is a lack of conceptual models that allow researchers and practitioners to analyze UCS privacy holistically. With the aim to fill this gap we build upon the ideas of Martínez et al. in  [395]  to suggest a 5-dimensional privacy model for UCS. The 5-dimensional privacy model results from the combination of two simpler privacy models (i. e. , the 3-D Conceptual Framework for Database Privacy  [187]  and the W 3 -privacy model for location-based services  [461] ), and it was already used within the context of smart cities  [395].
e. , putting in place the principle of data minimization). By doing so, users make more difficult for service providers to learn information. Most users are not trained to tune their queries, hence, in general, query privacy concerns can be mitigated by using Private Information Retrieval (PIR) techniques. By definition, PIR-based schemes are cryptographic protocols that retrieve records from databases while masking the identity of the retrieved records from the database owners  [589]. From the UCS-based services perspective, PIR tools could be used by consumers to query service providers. By doing so, the correlation between queries and individuals could be broken and profiling becomes much more difficult. Queries and their results can be easily analyzed by UCS-based service providers unless the proper countermeasures are put in place.
Intelligence Privacy In the current globalization context, there are numerous service providers offering similar products and services, which results in an increase in the number of competitors. Data collected by each provider is, in many cases, very valuable, and it is used to extract knowledge and provide customer-oriented, personalized or addedvalue services. Hence, sharing and releasing this data is not a common practice, especially if competitors have a chance to take advantage from such data. However, in some cases, organizations (not necessarily competitors) could take mutual benefit by collaborating, but they do not want to share their data. This situation is covered by what we have called intelligence privacy. In this dimension, the goal is to allow the collaboration among several organizations so that all could make joint queries to databases to obtain joint information in such a way that only the results are revealed (i.
e. , the actual information in the databases of each company is not shared or revealed). To clarify the concept of intelligence privacy let us have a look at the following example of manufacturers of autonomous and intelligent vehicles. Each vehicle manufacturer integrates many built-in sensors on vehicles to gather, store and analyze the status of the car, the nearby environment and further driving-related parameters. Since these data are highly sensitive, manufacturers might decide not to share them. However, collaboration among manufacturers by sharing data could be extremely useful to improve safety on roads and to avoid collisions. In this sense, each manufacturer (even if they compete) would benefit from the collaboration, that is, to obtain joint results, but they want to avoid sharing their intelligence data.
In this situation of mutual distrust, Privacy-Preserving Data Mining (PPDM) techniques emerge as the natural solution to protect intelligence privacy  [12]. PPDM methods are applicable once independent entities want to collaborate to obtain common results that benefit both of them, but without sharing their data since they do not trust each other. In such scenario, by applying PPDM to the queries submitted across several organization databases, the amount of information transferred to every party is controlled, and this does not pose risks that original data will be revealed, only the results. It is worth emphasizing that Intelligence Privacy considers data belonging to companies (e. g. , the heat dissipated by the front-left wheel brake). Thus, data collected by companies but belonging to individuals should not be considered under this dimension because they belong to the users and not to the companies, and hence they should be managed as such.
Future Trends and Challenges Privacy has often been considered from a data-oriented perspective. The goal was to protect the data regardless of their origin. Data, in this sense, were seen as something of value that belong to whoever has the ability to collect, store and exploit them and, following this line, privacy protection has been mixed with related problems such as access control, network and database security, and the like. However, to understand privacy we have to put the focus on people and, from there, we should rethink the whole architecture that aims at protecting it. Although some people support the idea of companies' privacy (i. e. , our concept of intelligence privacy), privacy issues mainly affect people. There is no doubt about the importance of protecting people's privacy and to do so we state that the focus should be put on people and become personalized.