A Comprehensive Review of RFID and Bluetooth Security: Practical Analysis

: The Internet of Things (IoT) provides the ability to digitize physical objects into virtual data, thanks to the integration of hardware (e


Introduction
The rapid evolution in miniaturization, electronics, and wireless communication technologies have contributed to essential and unprecedented advances in our society [1]. As a result, the number of available electronic devices has increased while their production costs have been reduced. Thanks to these advances in chip design, sensors and actuators are currently cheap enough to be embedded in any device [2]. The Internet of Things (IoT) emerged with the objective of providing new intelligent services and commodities to facilitate our daily tasks [3]. IoT visualizes a completely connected world, where things are able to communicate and interact among each other [1]. In this context, two of the most widely used technologies in the IoT domain are RFID (Radio Frequency Identification) and Bluetooth. RFID is one of the best positioned technologies to perform identification, which, in the last years, has gained a lot of popularity in applications like access control, payment cards, or logistics [4]. Other fields where RFID has a known implication are health care [5], animal identification [6], and the supply chain [7]. It is also important to remember that RFID includes Near Field Communication (NFC) as part of the standard. Actually, public transportation in many cities use the NFC card, Mifare Classic [8], Mifare Ultralight [9], Mifare Plus X [10], Mifare DESfire [11], and Mifare DESfire EV1 [12] for access control. In addition, RFID cards such as the EM4100 features application environments such as logistics automation and the industrial transponder [13]. With regard to Bluetooth technology, it has new markets as automotive, smart building, smart city, and smart home, which is highlighted with the recent release of Bluetooth mesh [14]. In 2018, nearly 4 billion devices ship with Bluetooth technology [15]. Many applications like the smart home and industry automation will also benefit from Bluetooth Smart Mesh technology [16].
in an exchange previous to the pairing between CC2540DK central and CC2540DK peripheral. The importance of I/O capabilities is represented in Figure 1b, where it is shown how this device (CC2540DK central) supports keyboard and display. From Bluetooth 4.2 specifications, the LE Secure connection is introduced [41]. The previous pairing methods used in the 4.1 and 4.0 Bluetooth Specifications are still available, and are now defined as LE Legacy pairing. The main difference is that LE Secure connections uses Elliptic Curve Diffie-Hellman cryptography, while LE Legacy pairing does not [42]. The pairing features that can be enabled are: the OOB (Out-of-Band) Data Flag bit, the MITM [43] (Man-In-The-Middle) bit, the SC (LE Secure connection) indicator bit, and the IO Cap (IO Capabilities). After the pairing request and the paring response are exchanged, both devices can select which key generation method is used in subsequent phases. LE Legacy pairing offers Just Works, Passkey, and OOB. In addition to these three methods, the LE Secure Connection also includes a new one: Numeric Comparison [44]. connection is introduced [41]. The previous pairing methods used in the 4.1 and 4.0 Bluetooth Specifications are still available, and are now defined as LE Legacy pairing. The main difference is that LE Secure connections uses Elliptic Curve Diffie-Hellman cryptography, while LE Legacy pairing does not [42]. The pairing features that can be enabled are: the OOB (Out-of-Band) Data Flag bit, the MITM [43] (Man-In-The-Middle) bit, the SC (LE Secure connection) indicator bit, and the IO Cap (IO Capabilities). After the pairing request and the paring response are exchanged, both devices can select which key generation method is used in subsequent phases. LE Legacy pairing offers Just Works, Passkey, and OOB. In addition to these three methods, the LE Secure Connection also includes a new one: Numeric Comparison [44].

Vulnerabilities and Threats for RFID and NFC
Security attacks on RFID may target the physical tag, the communication channel between the tag and the reader, or the applications system. Table 1 allows us to classify the existing security risks and threats according to their target into physical threats, channel threats, and system threats. The three types of categories are briefly defined below.
• Physical threats are represented by the threats that use physical means to attack the RFID system to disable tags, modify their content, or to imitate them [45]. • Channel threats refer to the attacks targeting the insecure channel between a reader and a tag.
RFID systems may face eavesdropping, snooping, counterfeiting, tracking threats, playback, and other communication security issues that lead to privacy leaks [46]. • System threats refer to the attacks on the flaws existing in the authentication protocol and encryption algorithm [46].
Note that the "PA" column indicates whether the security risk and threats will be demonstrated as part of the practical analysis in Section 6.1.

Vulnerabilities and Threats for RFID and NFC
Security attacks on RFID may target the physical tag, the communication channel between the tag and the reader, or the applications system. Table 1 allows us to classify the existing security risks and threats according to their target into physical threats, channel threats, and system threats. The three types of categories are briefly defined below.
• Physical threats are represented by the threats that use physical means to attack the RFID system to disable tags, modify their content, or to imitate them [45]. • Channel threats refer to the attacks targeting the insecure channel between a reader and a tag. RFID systems may face eavesdropping, snooping, counterfeiting, tracking threats, playback, and other communication security issues that lead to privacy leaks [46]. • System threats refer to the attacks on the flaws existing in the authentication protocol and encryption algorithm [46]. Disabling Tags An attacker takes advantage of the wireless nature of RFID systems in order to disable tags temporarily or permanently [45].

Cloning Tags
Each RFID tag used for identification has a unique ID number. If the ID information is exposed by the attacker, the tag can easily be copied [45].

Reverse Engineering
An attacker takes apart the chip to find out how it works in order to receive the data from the Integrated Circuit (IC) because most RFID tags are not equipped with a tamper resistant mechanism for an estimated long period of time [47]. 4 Power Analysis Power analysis attacks can be mounted on RFID systems by monitoring the power consumption levels of RFID tags.

Tag Modification
The most RFID tags use writable memory. Therefore, an adversary can take advantage of this feature to modify or delete valuable data from the memory of the tag [46]. 6

RFID Channel threats
Eavesdropping An unauthorized RFID reader listens to conversations between a tag and reader and then obtains important data [48]. x 7 Snooping Snooping is similar to eavesdropping. However, snooping occurs when the data stored on the RFID tag is read without the owner's knowledge or agreement by an unauthorized reader interacting the tag [46]. 8 Skimming The adversary observes the information exchanged between a legitimate tag and a legitimate reader. Via the extracted data, the attacker attempts to make a cloned tag, which imitates the original RFID tag [49]. 9 Replay Attack The replay attack is when a malicious node or device replays those key information, which is eavesdropped through the communication between reader and tag [46]. 10 Relay Attack In a relay attack, an adversary acts as a man-in-the-middle. An adversarial device is placed surreptitiously between a legitimate RFID tag and reader [50]. 11 Passive Interference RFID networks are rendered susceptible to possible interference and collisions from any source of radio interference such as noisy electronic generators and power switching supplies [45]. 12 Active Jamming Although passive interference is usually unintentional, an attacker can take advantage of the fact that an RFID tag listens indiscriminately to all radio signals in its range [45].

13
System Threats

Counterfeiting and Spoofing Attacks
When the attackers get some information about the identity of RFID tags either by detecting the communication between readers and legitimate tags or by physical exploration of the tags, the attacker can clone the tags.

Tracing and Tracking
By sending queries and obtaining the same response from a tag at various locations, it can be determined where the specific tag is currently and which locations it has visited [46].

Decoding or Crypto Attacks
Since most RFID systems use encryption technology to ensure the confidentiality and integrity of information delivery, attacking against the encryption algorithm is a common form of attack.
x 16 Denial of Service (Dos) Attacks DoS attacks are usually physical attacks like jamming the system with noise interference, blocking radio signals, or even removing or disabling RFID tags. Therefore, it causes the system to work improperly [51].

Viruses
RFID tags currently do not have enough memory capacity to store a virus. However, in the future, viruses could be a serious threat to an RFID system. A virus programmed on an RFID tag by an unknown source could cripple an RFID system when the tagged item is read at a facility [48].
Note that the "PA" column indicates whether the security risk and threats will be demonstrated as part of the practical analysis in Section 6.1.

Vulnerabilities and Threats for Bluetooth
Both the practical analysis and the developed review of vulnerabilities and threats are focused from Bluetooth 4.0. Table 2 provides an overview of a number of known security vulnerabilities associated with Bluetooth. Information has been gathered from different dataset analysis tools like CVE-MITRE [52], NIST [53], and CVE-Details [54]. Attempts for authentication are repeatable [53].
A mechanism needs to be included in Bluetooth devices to prevent unlimited authentication requests. The Bluetooth specification requires an exponentially increasing waiting interval between successive authentication attempts. However, it does not require such a waiting interval for authentication challenge requests. Therefore, an attacker could collect large numbers of challenge responses (which are encrypted with the secret link key) that could leak information about the secret link key. Link keys can be stored improperly. Link keys can be read or modified by an attacker if they are not securely stored and protected via access controls. All 10 Strengths of the pseudo-random number generators (PRNG) are not known [53].
The Random Number Generator (RNG) may produce static or periodic numbers that may reduce the effectiveness of the security mechanisms.
Only device authentication is provided by the specification. Application-level security, including user authentication, can be added via overlay by the application developer.

All 12
End-to-end security is not performed [61].
Only individual links are encrypted and authenticated. Data is decrypted at intermediate points. End-to-end security on top of the Bluetooth stack can be provided by use of additional security controls.

All 13
Security services are limited [62].
Audit, non-repudiation, and other services are not part of the standard. If needed, these services can be incorporated in an overlay fashion by the application developer.

All x 14
Discoverable and/or connectable devices are prone to attack [53].
Any BR/EDR/HS device that must go into discoverable or connectable mode to pair or connect should only do so for a minimal amount of time. A device should not be in discoverable or connectable mode all the time.

All
Technologies 2019, 7, 15 7 of 29 Note that the "PA" column indicates whether the security risk and threats will be demonstrated as part of the practical analysis in Section 6.2.
Bluetooth offers several benefits and advantages, but the benefits are not provided without risk. Bluetooth and associated devices are susceptible to general wireless networking threats, such as DoS attacks, eavesdropping, MITM attacks, message modification, and resource misappropriation, and are also threatened by more specific Bluetooth related attacks, such as the following.

•
Pairing Eavesdropping: Low Energy Legacy Pairing are susceptible to eavesdropping attacks [62]. The successful eavesdropper who collects all pairing frames can determine the secret key(s) given sufficient time, which allows trusted device impersonation and active/passive data decryption. Moreover, Reference [62] mentions how using Ubertooth One tool in conjunction with Kismet, Wireshark, and Crackle [64] is able to perform spectrum analysis, packet sniffing, and packet decoding. A security vulnerability due to (Temporary Key) TK is predictable because its length is too short [65]. Lastly, Reference [66] presents a comprehensive survey on the security flaws of BLE.

Tools Description: PM3 for RFID/NFC, Ubertooth, BtleJuice, and Bleah for Bluetooth
In order to carry out the PA, four open source and open hardware tools are used as the baseline to develop the security tests: PM3 for RFID/NFC and Ubertooth, BtleJuice, and Bleah for Bluetooth. These tools are presented below.

Proxmark3
PM3 supports both LF and HF signal processing, which are enabled by two independent parallel antenna circuits. Both antennas are connected to a 4-pin Hirose connector, and, in turn, it is connected to an external loop antenna [67]. PM3 can be used in the reading mode, the eavesdropping mode, or in the card emulation mode. The signal from the antenna is routed through the FPGA (Field Programmable Gate Array) after it has been digitized by an 8-bit ADC (Analog-to-Digital Converter). The FPGA relays the information needed to perform the signal decoding to the microcontroller. The core of this microcontroller is an ARM processor that is in charge of the protocol. It receives the digital signal from the FPGA and decodes it. The decoded signal can just be copied to a buffer in the EEPROM (Electrically Erasable Programmable Read-Only Memory). The PM3 has a USB interface to the computer. The current implementation uses the default Human Interface Device (HID) USB protocol. The microcontroller and the FPGA can be flashed via USB.
PM3 presents an associated tool, called mfkey [68], which allows us to obtain the keystream that has been used to generate {ar} and {at} and, therefore, the keys of card's sectors. All these terms are detailed in Section 6.

Ubertooth
Ubertooth is a USB dongle with an RF frontend, CC2400 radio chip, and LPC micro-controller [69]. The CC2400 has a reconfigurable narrowband radio transceiver that can monitor a single Bluetooth channel at any given moment. The CC2400 (roughly) converts RF into a bitstream, which is then processed entirely on the LPC. The Ubertooth project also implements a partial sniffer for BR/EDR Bluetooth. Because BLE is a simpler protocol than BR/EDR Bluetooth, it can process packets entirely on the LPC (on-dongle). In contrast, the BR/EDR Bluetooth sniffer only uses the LPC to shovel bits from the CC2400 to the PC. Ubertooth allows an operation with greater agility and enables the precise timing necessary for recovering hop interval and hop increment. The last firmware release can be obtained in Reference [70].
Ubertooth and Wireshark are used to capture traffic in order to use the crackle tool [64]. Crackle exploits a flaw in the BLE pairing process that allows an attacker to guess or very quickly brute force the TK (Temporary Key). With the TK and other data collected from the pairing process, the STK (Short Term Key) and later the LTK (Long Term Key) can be collected [64].

BtleJuice
BtleJuice is a complete framework to perform Man-in-the-Middle (MITM) attacks on BLE devices. It is composed of an interception core, an interception proxy, a dedicated web user interface (UI), and Python and Node.js bindings [70]. Figure 2 shows the software architecture of BtleJuice. The interception proxy interacts with Bluetooth peripherals and the interception core generates the fake devices with a fake Bluetooth address. In order to install BtleJuice, Reference [71] should be followed. BtleJuice is composed of two main components: an interception proxy and a core. These two components are required to run on independent machines in order to operate simultaneously two Bluetooth 4.0+ adapters.

Ubertooth
Ubertooth is a USB dongle with an RF frontend, CC2400 radio chip, and LPC micro-controller [69]. The CC2400 has a reconfigurable narrowband radio transceiver that can monitor a single Bluetooth channel at any given moment. The CC2400 (roughly) converts RF into a bitstream, which is then processed entirely on the LPC. The Ubertooth project also implements a partial sniffer for BR/EDR Bluetooth. Because BLE is a simpler protocol than BR/EDR Bluetooth, it can process packets entirely on the LPC (on-dongle). In contrast, the BR/EDR Bluetooth sniffer only uses the LPC to shovel bits from the CC2400 to the PC. Ubertooth allows an operation with greater agility and enables the precise timing necessary for recovering hop interval and hop increment. The last firmware release can be obtained in Reference [70].
Ubertooth and Wireshark are used to capture traffic in order to use the crackle tool [64]. Crackle exploits a flaw in the BLE pairing process that allows an attacker to guess or very quickly brute force the TK (Temporary Key). With the TK and other data collected from the pairing process, the STK (Short Term Key) and later the LTK (Long Term Key) can be collected [64].

BtleJuice
BtleJuice is a complete framework to perform Man-in-the-Middle (MITM) attacks on BLE devices. It is composed of an interception core, an interception proxy, a dedicated web user interface (UI), and Python and Node.js bindings [70]. Figure 2 shows the software architecture of BtleJuice. The interception proxy interacts with Bluetooth peripherals and the interception core generates the fake devices with a fake Bluetooth address. In order to install BtleJuice, Reference [72] should be followed. BtleJuice is composed of two main components: an interception proxy and a core. These two components are required to run on independent machines in order to operate simultaneously two Bluetooth 4.0+ adapters.

Bleah
Bleah is a BLE scanner based on the bluepy library [63]. Functions like continuous scanning for BLE devices, connecting to a specific device, enumerating all services, and injecting information to a specific characteristic of the device are part of the tool. Figure 3 shows the architectures built to perform security tests on devices that support both technologies. On these architectures, each and every one of the practical analyses are deployed. Due to the portability provided by RBPi, all architectures are based on this hardware. Figure 3a

Bleah
Bleah is a BLE scanner based on the bluepy library [63]. Functions like continuous scanning for BLE devices, connecting to a specific device, enumerating all services, and injecting information to a specific characteristic of the device are part of the tool. Figure 3 shows the architectures built to perform security tests on devices that support both technologies. On these architectures, each and every one of the practical analyses are deployed. Due to the portability provided by RBPi, all architectures are based on this hardware. Figure 3a testing the PassKey Entry mode. On the other hand, the architecture shown in Figure 3e represents the use of the BtleJuice framework for the execution of an MITM attack. The architecture represented in Figure 3f is used to build a fuzzing attack from the Bleah tool. The main details of each architecture are specified below.

PM3 Architecture
In order to perform a security test on RFID/NFC, two architectures have been deployed: Figure  3a,b. First of all, the PM3 is launched on the RBPi. Details of the installation of PM3 over RBPi can be obtained using Reference [73]. The architecture shown in Figure 3a needs to launch the ACR122U [74]. Figure 3a shows the interaction between the reader and the card. The ACR122U reader has been selected like additional hardware because it is compliant with the most used operating systems [74] and the library nfc-tools [75]. PM3 supports Eavesdropping Mode, which allows us to focus on security aspects because the PM3 antenna receives the interaction tag-reader (in this case: MFCT-ACR122U). Figure 3b shows the other used architecture. In this case, PM3 is used in the reader mode so it has a direct interaction with the tags. As it was mentioned in Section 2, four different tags are used, one HF and three LF. From the point of view of PM3, to change architecture, the antenna must be changed. In both cases, the security tests include the commands, which are shown in Section 6.1.

Ubertooth Architecture
The architectures of Figure 3c,d are deployed to perform security tests using Ubertooth as a passive eavesdropping tool. Two peripheral devices known as CC2650STK and CC2540DK are used. The reason is that they support different security modes: CC2650STK supports LE Secure connections [42], while CC2540DK supports LE Legacy pairing [76]. In addition, both use different pairing methods because they have different input/output capabilities. In the case of the CC2650STK, it only supports the method Just Works (Figure 3c), while the CC2540DK supports Passkey Entry ( Figure  3d). In order to interact with both end devices, a Bluetooth gateway is used.
An RBPi with a network connection and Bluetooth connectivity is used as the central device. It hosts an application written in JavaScript that runs on a Node.js server. The application is split into two major components, which are detailed below.

PM3 Architecture
In order to perform a security test on RFID/NFC, two architectures have been deployed: Figure 3a,b. First of all, the PM3 is launched on the RBPi. Details of the installation of PM3 over RBPi can be obtained using Reference [73]. The architecture shown in Figure 3a needs to launch the ACR122U [74]. Figure 3a shows the interaction between the reader and the card. The ACR122U reader has been selected like additional hardware because it is compliant with the most used operating systems [74] and the library nfc-tools [75]. PM3 supports Eavesdropping Mode, which allows us to focus on security aspects because the PM3 antenna receives the interaction tag-reader (in this case: MFCT-ACR122U). Figure 3b shows the other used architecture. In this case, PM3 is used in the reader mode so it has a direct interaction with the tags. As it was mentioned in Section 2, four different tags are used, one HF and three LF. From the point of view of PM3, to change architecture, the antenna must be changed. In both cases, the security tests include the commands, which are shown in Section 6.1.

Ubertooth Architecture
The architectures of Figure 3c,d are deployed to perform security tests using Ubertooth as a passive eavesdropping tool. Two peripheral devices known as CC2650STK and CC2540DK are used. The reason is that they support different security modes: CC2650STK supports LE Secure connections [42], while CC2540DK supports LE Legacy pairing [76]. In addition, both use different pairing methods because they have different input/output capabilities. In the case of the CC2650STK, it only supports the method Just Works (Figure 3c), while the CC2540DK supports Passkey Entry (Figure 3d). In order to interact with both end devices, a Bluetooth gateway is used.
An RBPi with a network connection and Bluetooth connectivity is used as the central device. It hosts an application written in JavaScript that runs on a Node.js server. The application is split into two major components, which are detailed below.

•
The Gateway Server (GS) provides the engine of the solution, which searches for nearby peripherals and interrogates them to expose the information in the form of a Rest API.

•
The Gateway Explorer (GE) provides a web interface, which communicates with the API noted above to expose the information to the user and allow them to interact with the devices.
Both gateways must be launched from the console to manage Bluetooth devices. Figure 4a,b show GS and GE, respectively. When the GE server is started, a browser provides the web interface to manage the connection including the pairing and the bonding of both CC2650STK and CC2540DK. Figure 5a shows the first interface with devices detected. Figure 5b shows how the GE's web interface allows us to establish connections and to manage pairing. Once the connections are established, the interactions between the peripheral and gateway can be sniffed using Ubertooth.
Technologies 2018, 6, x 11 of 29 • The Gateway Server (GS) provides the engine of the solution, which searches for nearby peripherals and interrogates them to expose the information in the form of a Rest API.

•
The Gateway Explorer (GE) provides a web interface, which communicates with the API noted above to expose the information to the user and allow them to interact with the devices.
Both gateways must be launched from the console to manage Bluetooth devices. Figure 4a,b show GS and GE, respectively. When the GE server is started, a browser provides the web interface to manage the connection including the pairing and the bonding of both CC2650STK and CC2540DK. Figure 5a shows the first interface with devices detected. Figure 5b shows how the GE's web interface allows us to establish connections and to manage pairing. Once the connections are established, the interactions between the peripheral and gateway can be sniffed using Ubertooth.  One additional tool, BTool [77], is used to interact with CC2540DK as peripheral with the gateway. BTool includes the ability to make use of security features in BLE, including encryption, • The Gateway Server (GS) provides the engine of the solution, which searches for nearby peripherals and interrogates them to expose the information in the form of a Rest API.

•
The Gateway Explorer (GE) provides a web interface, which communicates with the API noted above to expose the information to the user and allow them to interact with the devices.
Both gateways must be launched from the console to manage Bluetooth devices. Figure 4a,b show GS and GE, respectively. When the GE server is started, a browser provides the web interface to manage the connection including the pairing and the bonding of both CC2650STK and CC2540DK. Figure 5a shows the first interface with devices detected. Figure 5b shows how the GE's web interface allows us to establish connections and to manage pairing. Once the connections are established, the interactions between the peripheral and gateway can be sniffed using Ubertooth.  One additional tool, BTool [77], is used to interact with CC2540DK as peripheral with the gateway. BTool includes the ability to make use of security features in BLE, including encryption, One additional tool, BTool [77], is used to interact with CC2540DK as peripheral with the gateway. BTool includes the ability to make use of security features in BLE, including encryption, authentication, and bonding. Figure 6a shows how the gateway generates a Pass Key, and Figure 6b) shows how this Pass Key is introduced using the BTool.  Figure 3e shows the architecture deployed in order to build a MITM attack. It uses both the CC2650STK as peripheral and the IoT Gateway used in the previous section as the central device. Another RBPi runs BtleJuice tool, which uses the Ethernet interface (eth0), the wireless interface (wlan1) and the Bluetooth controllers (hci0 and hci1) for the deployment.

BtleJuice Architecture
Once BtleJuice proxy and BtleJuice core are launched, Figure 7a Figure 3f shows the architecture deployed in order to build a fuzzing attack. This architecture is very simple because it is constituted only by the RBPi with the internal Bluetooth controller hci0 and the Bleah tool installed, as well as by the CC2650STK. The installation of Bleah is simple and Reference [63] should be followed. Once Bleah is installed, in order to discover devices, command (1) should be launched. Figure 9a shows the output to the command (1). Next, the Bluetooth address of  Figure 3e shows the architecture deployed in order to build a MITM attack. It uses both the CC2650STK as peripheral and the IoT Gateway used in the previous section as the central device. Another RBPi runs BtleJuice tool, which uses the Ethernet interface (eth0), the wireless interface (wlan1) and the Bluetooth controllers (hci0 and hci1) for the deployment.

BtleJuice Architecture
Once BtleJuice proxy and BtleJuice core are launched, Figure 7a,b, BtleJuice UI allows the selection ( Figure 8a) and the connection (Figure 7a) to real CC2650STK. On the other hand, the Gateway Explorer (GE) receives a notification to connect to a dummy device (Figure 8b)), which is accepted and the connection is established (Figure 7b).  Figure 3e shows the architecture deployed in order to build a MITM attack. It uses both the CC2650STK as peripheral and the IoT Gateway used in the previous section as the central device. Another RBPi runs BtleJuice tool, which uses the Ethernet interface (eth0), the wireless interface (wlan1) and the Bluetooth controllers (hci0 and hci1) for the deployment.

BtleJuice Architecture
Once BtleJuice proxy and BtleJuice core are launched, Figure 7a Figure 3f shows the architecture deployed in order to build a fuzzing attack. This architecture is very simple because it is constituted only by the RBPi with the internal Bluetooth controller hci0 and the Bleah tool installed, as well as by the CC2650STK. The installation of Bleah is simple and Reference [63] should be followed. Once Bleah is installed, in order to discover devices, command (1) should be launched. Figure 9a shows the output to the command (1). Next, the Bluetooth address of  Figure 3e shows the architecture deployed in order to build a MITM attack. It uses both the CC2650STK as peripheral and the IoT Gateway used in the previous section as the central device. Another RBPi runs BtleJuice tool, which uses the Ethernet interface (eth0), the wireless interface (wlan1) and the Bluetooth controllers (hci0 and hci1) for the deployment.

BtleJuice Architecture
Once BtleJuice proxy and BtleJuice core are launched, Figure 7a Figure 3f shows the architecture deployed in order to build a fuzzing attack. This architecture is very simple because it is constituted only by the RBPi with the internal Bluetooth controller hci0 and the Bleah tool installed, as well as by the CC2650STK. The installation of Bleah is simple and Reference [63] should be followed. Once Bleah is installed, in order to discover devices, command (1) should be launched. Figure 9a shows the output to the command (1). Next, the Bluetooth address of  Figure 3f shows the architecture deployed in order to build a fuzzing attack. This architecture is very simple because it is constituted only by the RBPi with the internal Bluetooth controller hci0 and the Bleah tool installed, as well as by the CC2650STK. The installation of Bleah is simple and Reference [63] should be followed. Once Bleah is installed, in order to discover devices, command (1) should be launched. Figure 9a shows the output to the command (1). Next, the Bluetooth address of the target device is filtered and the command (2) is launched in order to recover sensible information to deploy the fuzzing attack in Section 6.2.5. Figure 9b shows the output of the command (2).

Bleah Architecture
sudo bleah -b "54:6c:0e:80:9a:03" -e, Technologies 2018, 6, x 13 of 29 the target device is filtered and the command (2) is launched in order to recover sensible information to deploy the fuzzing attack in Section 6.2.5. Figure 9b shows the output of the command (2).

Practical Analysis and Discussion Results
The practical analysis (PA) demonstrates some of the vulnerabilities, security risks, and threats discussed during the reviews developed in Section 3. Table 3 lists some security risks and threats described in Table 1, with a mark on the "PA" column. The security test are then carried out.  (Figure 3b), the command (3) is launched to get the LF tags near the PM3 antenna.

Practical Analysis and Discussion Results
The practical analysis (PA) demonstrates some of the vulnerabilities, security risks, and threats discussed during the reviews developed in Section 3. Table 3 lists some security risks and threats described in Table 1, with a mark on the "PA" column. The security test are then carried out.  (Figure 3b), the command (3) is launched to get the LF tags near the PM3 antenna. This Tag ID is directly encoded from the Facility Code (19) and Card ID (8011). In order to check this relation, Reference [78] can be used like online 26 bit Wiegand calculator (Figure 10b). As the Tag ID (2004263E97) is known, the command (4) can be run to continuously read the ProxCard (the button on the PM3 should be pushed to stop scanning). The output of the command (4) is shown in Figure 10c.

RFID and NFC Practical Analysis
lf hid fskdemod, lf hid clone 2004263E97, Technologies 2018, 6, x 14 of 29 Figure 10a shows the output of the command (3) where the Tag ID (2004263E97) is detected. This Tag ID is directly encoded from the Facility Code (19) and Card ID (8011). In order to check this relation, Reference [78] can be used like online 26 bit Wiegand calculator (Figure 10b). As the Tag ID (2004263E97) is known, the command (4) can be run to continuously read the ProxCard (the button on the PM3 should be pushed to stop scanning). The output of the command (4) is shown in Figure  10c.
lf hid fskdemod, lf hid clone 2004263E97, It is only necessary to know those numbers (which are also printed on the card itself) to clone the card. Therefore, a spoofing attack is carried out because of physical exploration of the tag.
Most low frequency tags do not have any kind of complex authentication scheme or any protection against replay attacks. It is a simple matter to scan an existing working card and create a clone. With a high powered reader, one can steal RFID tags from multiple feet away. With the Tag ID recovered, it is now necessary for a blank RFID card to clone the Tag ID. The T5577 card emulates a variety of low frequency cards. Therefore, it is selected. The command (5) allows the cloning of the original ProxCard. Figure 10d represents the command (5) output and shows how the cloning of the card was successful.

Cloning RFID Tag EM4100
From PM3 again in reader mode, (Figure 3b)), the command (3) is launched in order to get the LF tags near the PM3 antenna. lf em4x em410xdemod 1, lf em4x em410xwrite 8800393f75 1, The output of command (3) allows us to discover the EM4100 tag ( Figure 11a). Therefore, more specific EM4100 RFID commands can be performed and read the Tag ID (command (6)). Figure 11b shows the output of command (6). Once again, with the Tag ID recovered, the EM4100 can be cloned to a T5577 using command (7). Figure 11c shows the output of command (7). It is only necessary to know those numbers (which are also printed on the card itself) to clone the card. Therefore, a spoofing attack is carried out because of physical exploration of the tag.
Most low frequency tags do not have any kind of complex authentication scheme or any protection against replay attacks. It is a simple matter to scan an existing working card and create a clone. With a high powered reader, one can steal RFID tags from multiple feet away. With the Tag ID recovered, it is now necessary for a blank RFID card to clone the Tag ID. The T5577 card emulates a variety of low frequency cards. Therefore, it is selected. The command (5) allows the cloning of the original ProxCard. Figure 10d represents the command (5) output and shows how the cloning of the card was successful.

Cloning RFID Tag EM4100
From PM3 again in reader mode, (Figure 3b)), the command (3) is launched in order to get the LF tags near the PM3 antenna. lf em4x em410xdemod 1, lf em4x em410xwrite 8800393f75 1, The output of command (3) allows us to discover the EM4100 tag ( Figure 11a). Therefore, more specific EM4100 RFID commands can be performed and read the Tag ID (command (6)). Figure 11b shows the output of command (6). Once again, with the Tag ID recovered, the EM4100 can be cloned to a T5577 using command (7). Figure 11c shows the output of command (7).  The Eavesdropping Mode in PM3 (Figure 3a) allows us to analyze other security aspects because the PM3 antenna receives the MFCT -ACR122U interaction. PM3 must use the specific HF antenna. The type of card is identified using command (8). Figure 12 shows the output of command (8).
proxmark3 > hf seach, (8)    The Eavesdropping Mode in PM3 (Figure 3a) allows us to analyze other security aspects because the PM3 antenna receives the MFCT -ACR122U interaction. PM3 must use the specific HF antenna. The type of card is identified using command (8). Figure 12 shows the output of command (8).

Eavesdropping Attack on the Mifare Classic Tag
The Eavesdropping Mode in PM3 (Figure 3a) allows us to analyze other security aspects because the PM3 antenna receives the MFCT -ACR122U interaction. PM3 must use the specific HF antenna. The type of card is identified using command (8). Figure 12 shows the output of command (8).
proxmark3 > hf seach, (8)   Once MFCT is identified, the command (9) is launched, which allows the eavesdropping of ISO 14,443 Type A card. proxmark3 > hf 14a snoop, The interaction that happens in an ISO/IEC 14,443 type A communication is described in Reference [79]. It is necessary to hold the PM3 antenna next to the reader and to locate the MFCT. Blinking lights indicate that the transmission has been captured. If the button on the PM3 is pressed, the flow of frames stops. Another way is to wait until the buffer is full. The trace highly likely contains more than just only the authentication information. Before the reader can exchange messages with a MFCT, it needs to perform the initial communication and the anti-collision protocol [80]. To retrieve the eavesdropped trace from the PM3, command (10) can be used.
proxmark3 > hf list 14a, Figure 13a contains a capture after command (10) is executed. Figure 13b is a schema of the capture of Figure 13a. Once MFCT is identified, the command (9) is launched, which allows the eavesdropping of ISO 14,443 Type A card.
proxmark3 > hf 14a snoop, The interaction that happens in an ISO/IEC 14,443 type A communication is described in Reference [79]. It is necessary to hold the PM3 antenna next to the reader and to locate the MFCT. Blinking lights indicate that the transmission has been captured. If the button on the PM3 is pressed, the flow of frames stops. Another way is to wait until the buffer is full. The trace highly likely contains more than just only the authentication information. Before the reader can exchange messages with a MFCT, it needs to perform the initial communication and the anti-collision protocol [80]. To retrieve the eavesdropped trace from the PM3, command (10) can be used. Figure 13a contains a capture after command (10) is executed. Figure 13b is a schema of the capture of Figure 13a.   Figure 13b shows a process known as "three pass authentication," which is described by Reference [80] and summarized below.

•
The tag picks a challenge nonce 'nt' and sends it to the reader in the clear.

•
The reader sends its own challenge nonce 'nr' together with the answer 'ar' to the tag's challenge.

•
The tag finishes authentication by replying 'at' to the challenge of the reader.
A detailed cryptographic analysis is shown in Reference [82]. PM3 includes an important tool that calculates the nonce and the keystream. This tool is launched with command (11). The recovered information, which is shown in Figure 13a, is used as an argument of command (11).

•
The tag picks a challenge nonce 'nt' and sends it to the reader in the clear.

•
The reader sends its own challenge nonce 'nr' together with the answer 'ar' to the tag's challenge.

•
The tag finishes authentication by replying 'at' to the challenge of the reader.
A detailed cryptographic analysis is shown in Reference [82]. PM3 includes an important tool that calculates the nonce and the keystream. This tool is launched with command (11). The recovered information, which is shown in Figure 13a, is used as an argument of command (11). /mfkey > sudo ./mfkey64 3eb4e249 245cdbee 584767bf 686f4fb9 6021b93d, After running command (11), the console's output (Figure 14a) shows the recovery of important keys. However, 'ks2' and 'ks3' are used to obtain the values of '{ar}' and '{at}', respectively. The following process is shown in Figure 14b. The process demonstrates that the values of 'ks2' and 'ks3' recovered by the PM3 are the correct ones. After running command (11), the console's output (Figure 14a) shows the recovery of important keys. However, 'ks2' and 'ks3' are used to obtain the values of '{ar}' and '{at}', respectively. The following process is shown in Figure 14b. The process demonstrates that the values of 'ks2' and 'ks3' recovered by the PM3 are the correct ones.  Figure 15 shows how ks2 and ks3 have been calculated, respectively, through the XOR operation, which means that the key generated by the Pseudo Random Number Generator (PRNG) is deciphered from a simple capture realized in a PM3 eavesdropping mode. When applying command (11), a key is retrieved (see Figure 16a). From this key and using command (12), the rest of the keys are recovered as well as the data for each block and sector (Figure 16b). proxmark3> hf mf rdbl block_num A key_found,  Figure 15 shows how ks2 and ks3 have been calculated, respectively, through the XOR operation, which means that the key generated by the Pseudo Random Number Generator (PRNG) is deciphered from a simple capture realized in a PM3 eavesdropping mode. When applying command (11), a key is retrieved (see Figure 16a). From this key and using command (12), the rest of the keys are recovered as well as the data for each block and sector (Figure 16b). proxmark3> hf mf rdbl block_num A key_found, Technologies 2018, 6, x 17 of 29 After running command (11), the console's output (Figure 14a) shows the recovery of important keys. However, 'ks2' and 'ks3' are used to obtain the values of '{ar}' and '{at}', respectively. The following process is shown in Figure 14b. The process demonstrates that the values of 'ks2' and 'ks3' recovered by the PM3 are the correct ones.  Figure 15 shows how ks2 and ks3 have been calculated, respectively, through the XOR operation, which means that the key generated by the Pseudo Random Number Generator (PRNG) is deciphered from a simple capture realized in a PM3 eavesdropping mode. When applying command (11), a key is retrieved (see Figure 16a). From this key and using command (12), the rest of the keys are recovered as well as the data for each block and sector (Figure 16b). After running command (11), the console's output (Figure 14a) shows the recovery of important keys. However, 'ks2' and 'ks3' are used to obtain the values of '{ar}' and '{at}', respectively. The following process is shown in Figure 14b. The process demonstrates that the values of 'ks2' and 'ks3' recovered by the PM3 are the correct ones.  Figure 15 shows how ks2 and ks3 have been calculated, respectively, through the XOR operation, which means that the key generated by the Pseudo Random Number Generator (PRNG) is deciphered from a simple capture realized in a PM3 eavesdropping mode. When applying command (11), a key is retrieved (see Figure 16a). From this key and using command (12), the rest of the keys are recovered as well as the data for each block and sector (Figure 16b).

Password Decoding or Crypto Attacks on Mifare Classic Tag
"Nested Attack" is another security test carried out against the MFCT. PM3 must be used in an Eavesdropping Mode (Figure 3a). The HF antenna must be connected. Once command (8) is launched, an output that is similar to Figure 12 is obtained. If some sectors of the card use default keys, they can be easily read through command (13), which is shown in Figure 17a. However, the default passwords may have been changed in other sectors, as it is shown in Figure 17b, once command (14) is applied. The PM3 performs the "Test Block Keys" command, which tests the default keys through command (15). Figure 17c shows the output of command (15).
hf mf rdbl 7 A FFFFFFFFFFFF, (14) hf mf chk * ?, (15) hf mf nested 1 0 A ffffffffffff d, Technologies 2018, 6, x 18 of 29 "Nested Attack" is another security test carried out against the MFCT. PM3 must be used in an Eavesdropping Mode (Figure 3a). The HF antenna must be connected. Once command (8) is launched, an output that is similar to Figure 12 is obtained. If some sectors of the card use default keys, they can be easily read through command (13), which is shown in Figure 17a. However, the default passwords may have been changed in other sectors, as it is shown in Figure 17b, once command (14) is applied. The PM3 performs the "Test Block Keys" command, which tests the default keys through command (15). Figure 17c shows the output of command (15).
hf mf rdbl 7 A FFFFFFFFFFFF, (14) hf mf chk * ?, (15) hf mf nested 1 0 A ffffffffffff d, (c) The "Nested Attack" is launched through command (16) because there is one useable key to identify keys for the other blocks. Figure 18 shows the output of command (16), where keys of many sectors are obtained.    The "Nested Attack" is launched through command (16) because there is one useable key to identify keys for the other blocks. Figure 18 shows the output of command (16), where keys of many sectors are obtained. "Nested Attack" is another security test carried out against the MFCT. PM3 must be used in an Eavesdropping Mode (Figure 3a). The HF antenna must be connected. Once command (8) is launched, an output that is similar to Figure 12 is obtained. If some sectors of the card use default keys, they can be easily read through command (13), which is shown in Figure 17a. However, the default passwords may have been changed in other sectors, as it is shown in Figure 17b, once command (14) is applied. The PM3 performs the "Test Block Keys" command, which tests the default keys through command (15). Figure 17c shows the output of command (15).
hf mf rdbl 7 A FFFFFFFFFFFF, hf mf chk * ?, hf mf nested 1 0 A ffffffffffff d,  (c) The "Nested Attack" is launched through command (16) because there is one useable key to identify keys for the other blocks. Figure 18 shows the output of command (16), where keys of many sectors are obtained.    The new recovered key (080808088888) allows us to read the secret blocks, which is shown in Figure 19. Once it is used, command (13) with the values of the sector and key are updated. Therefore, the information of all blocks can be read. The new recovered key (080808088888) allows us to read the secret blocks, which is shown in Figure 19. Once it is used, command (13) with the values of the sector and key are updated. Therefore, the information of all blocks can be read. proxmark3> hf mf rdbl 9 A 080808088888 --block no:9, key type:A, key:08 08 08 08 08 08 #db# READ BLOCK FINISHED isOk:01 data:00 0c 00 0e ff f5 ff ff 00 0c 01 00 09 ea 07 ff Figure 19. Output of hf mf rdbl command. Table 4 lists the Bluetooth's vulnerabilities described in Table 2, with a mark on the "PA" column. The security test is then carried out over the associated devices.  [55]. If the Bluetooth device is connected in this mode, using the architecture in figure  3c, the exchanged information is retrieved, as shown in Figure 19b, because Ubertooth sniffs the communication between the peripheral (CC2650STK) and the central (GS) (see Figure 19a).   Table 4 lists the Bluetooth's vulnerabilities described in Table 2, with a mark on the "PA" column. The security test is then carried out over the associated devices.  [55]. If the Bluetooth device is connected in this mode, using the architecture in Figure 3c, the exchanged information is retrieved, as shown in Figure 20b, because Ubertooth sniffs the communication between the peripheral (CC2650STK) and the central (GS) (see Figure 20a). The new recovered key (080808088888) allows us to read the secret blocks, which is shown in Figure 19. Once it is used, command (13) with the values of the sector and key are updated. Therefore, the information of all blocks can be read. proxmark3> hf mf rdbl 9 A 080808088888 --block no:9, key type:A, key:08 08 08 08 08 08 #db# READ BLOCK FINISHED isOk:01 data:00 0c 00 0e ff f5 ff ff 00 0c 01 00 09 ea 07 ff Figure 19. Output of hf mf rdbl command. Table 4 lists the Bluetooth's vulnerabilities described in Table 2, with a mark on the "PA" column. The security test is then carried out over the associated devices.  [55]. If the Bluetooth device is connected in this mode, using the architecture in figure  3c, the exchanged information is retrieved, as shown in Figure 20b, because Ubertooth sniffs the communication between the peripheral (CC2650STK) and the central (GS) (see Figure 20a). Once the architecture of Figure 3e is deployed and the dummy device is connected to the GS gateway, the MITM is carried out, where all the intercepted GATT operations are then displayed with the corresponding services characteristics, UUID, and the data associated in BtleJuice UI. Figure 21a shows the information received for both battery and humidity services in the BtleJuice UI. From the same UI, the replay attack is carried out by modifying the value of the GATT service (Figure 21b).

Vulnerability 2: Just Works, MITM Attack
Once the architecture of Figure 3e is deployed and the dummy device is connected to the GS gateway, the MITM is carried out, where all the intercepted GATT operations are then displayed with the corresponding services characteristics, UUID, and the data associated in BtleJuice UI. Figure 21a shows the information received for both battery and humidity services in the BtleJuice UI. From the same UI, the replay attack is carried out by modifying the value of the GATT service (Figure 21b).  Figure 22 shows the information received from the dummy device connected to the central device (GS), which shows the same value as in the CC2650STK for the battery service because it did not apply the replay attack and, for the humidity service, the value changed from "46" to "64".

Vulnerability 3: Just Works, Eavesdropping Attack
In order to provide a secure channel, the pairing process must be executed. CC2650STK only supports the pairing method "Just Works," where the TK is always zero because it does not have enough physical characteristics (Input/Output) to support another type of pairing, such as OOB or Passkey Entry (Figure 23a). Figure 23a shows the pairing response package, where flags: OOB, Keypress, MITM, and LE Secure are unset to CC2650STK. These results are related with supported input/output capabilities because the CC2650STK has neither input nor output, such as a keyboard and/or a display.
The connection between CC2650STK peripheral and the GS gateway is sniffed with Ubertooth and Wireshark following the configuration shown in Figure 3c. As result, a file with the ".pcap" or ".pcapng" extension is generated, which is used by Crackle tool with command (17) in both cases.  Figure 22 shows the information received from the dummy device connected to the central device (GS), which shows the same value as in the CC2650STK for the battery service because it did not apply the replay attack and, for the humidity service, the value changed from "46" to "64".

Vulnerability 2: Just Works, MITM Attack
Once the architecture of Figure 3e is deployed and the dummy device is connected to the GS gateway, the MITM is carried out, where all the intercepted GATT operations are then displayed with the corresponding services characteristics, UUID, and the data associated in BtleJuice UI. Figure 21a shows the information received for both battery and humidity services in the BtleJuice UI. From the same UI, the replay attack is carried out by modifying the value of the GATT service (Figure 21b).  Figure 22 shows the information received from the dummy device connected to the central device (GS), which shows the same value as in the CC2650STK for the battery service because it did not apply the replay attack and, for the humidity service, the value changed from "46" to "64".

Vulnerability 3: Just Works, Eavesdropping Attack
In order to provide a secure channel, the pairing process must be executed. CC2650STK only supports the pairing method "Just Works," where the TK is always zero because it does not have enough physical characteristics (Input/Output) to support another type of pairing, such as OOB or Passkey Entry (Figure 23a). Figure 23a shows the pairing response package, where flags: OOB, Keypress, MITM, and LE Secure are unset to CC2650STK. These results are related with supported input/output capabilities because the CC2650STK has neither input nor output, such as a keyboard and/or a display.
The connection between CC2650STK peripheral and the GS gateway is sniffed with Ubertooth and Wireshark following the configuration shown in Figure 3c. As result, a file with the ".pcap" or ".pcapng" extension is generated, which is used by Crackle tool with command (17) in both cases.

Vulnerability 3: Just Works, Eavesdropping Attack
In order to provide a secure channel, the pairing process must be executed. CC2650STK only supports the pairing method "Just Works," where the TK is always zero because it does not have enough physical characteristics (Input/Output) to support another type of pairing, such as OOB or Passkey Entry (Figure 23a). Figure 23a shows the pairing response package, where flags: OOB, Keypress, MITM, and LE Secure are unset to CC2650STK. These results are related with supported input/output capabilities because the CC2650STK has neither input nor output, such as a keyboard and/or a display.
The connection between CC2650STK peripheral and the GS gateway is sniffed with Ubertooth and Wireshark following the configuration shown in Figure 3c. As result, a file with the ".pcap" or ".pcapng" extension is generated, which is used by Crackle tool with command (17) in both cases. Figure 24a shows the output of command (17). From decrypted files, Figure 25a shows how important information about the cypher channel is captured. The Long Term Key (LTK) of CC2650STK (Figure 25a) is found. It should be noted that the LTK listed in Figure 25a, which was once used as crackle, is encrypted so they do not match those in Figure 24a, where the package is already decrypted.
Bluetooth uses the function (18) to generate the key to encrypt the channel. The values of rand, p1 and p2, are obtained in the pairing process [83]. In the case of CC2650STK, the value of TK is 0. Figure 26a shows how the transmitted value 03 is recovered despite the encryption from CC2650STK.  Figure 24a shows the output of command (17). From decrypted files, Figure 25a shows how important information about the cypher channel is captured. The Long Term Key (LTK) of CC2650STK (Figure 25a) is found. It should be noted that the LTK listed in Figure 25a, which was once used as crackle, is encrypted so they do not match those in Figure 24a, where the package is already decrypted.
Bluetooth uses the function (18) to generate the key to encrypt the channel. The values of rand, p1 and p2, are obtained in the pairing process [83]. In the case of CC2650STK, the value of TK is 0. Figure 26a shows how the transmitted value 03 is recovered despite the encryption from CC2650STK.  Figure 24a shows the output of command (17). From decrypted files, Figure 25a shows how important information about the cypher channel is captured. The Long Term Key (LTK) of CC2650STK (Figure 25a) is found. It should be noted that the LTK listed in Figure 25a, which was once used as crackle, is encrypted so they do not match those in Figure 24a, where the package is already decrypted.
Bluetooth uses the function (18) to generate the key to encrypt the channel. The values of rand, p1 and p2, are obtained in the pairing process [83]. In the case of CC2650STK, the value of TK is 0. Figure 26a shows how the transmitted value 03 is recovered despite the encryption from CC2650STK.

CC2650STK CC2540DK
Analyzing connection 0:   Figure 24a shows the output of command (17). From decrypted files, Figure 25a shows how important information about the cypher channel is captured. The Long Term Key (LTK) of CC2650STK (Figure 25a) is found. It should be noted that the LTK listed in Figure 25a, which was once used as crackle, is encrypted so they do not match those in Figure 24a, where the package is already decrypted.
Bluetooth uses the function (18) to generate the key to encrypt the channel. The values of rand, p1 and p2, are obtained in the pairing process [83]. In the case of CC2650STK, the value of TK is 0. Figure 26a shows how the transmitted value 03 is recovered despite the encryption from CC2650STK.

CC2650STK CC2540DK
Analyzing connection 0:  6.2.4. Vulnerability 8: Passkey, Eavesdropping Attack CC2540DK supports the "PassKey" method because it connected with the BTool (via serial), which serves as interface to provide IO capabilities. Figure 23b shows a pairing response package, where flags: Keypress, MITM, and Bonding are set to CC2540DK. These results are related with input/output capabilities supported because the CC2540DK supports the keyboard as the input and the display as the output.
The same procedure of the previous section is used. The connection between CC2540DK peripheral and the GS gateway is sniffed with Ubertooth and Wireshark following the configuration shown in Figure 3d. As a result, a file with ".pcap" or ".pcapng" extension is generated, which is used by the Crackle tool with command (17). Figure 24b shows the output of command (17) for CC2540DK. As for Section 6.2.1, Figure 25b shows the encrypted LTK, while Figure 24b shows the decrypted LTK through the capture of Wireshark.
Function (18) is used to generate the key to encrypt the channel. The values of rand, p1 and p2, are obtained in the pairing process [82]. In the case of CC2540DK, the TK is recovered because crackle applies brute force since it is a six-digit pin. Figure 26b shows how sensible information about the service is recovered from CC2540DK. 6.2.4. Vulnerability 8: Passkey, Eavesdropping Attack CC2540DK supports the "PassKey" method because it connected with the BTool (via serial), which serves as interface to provide IO capabilities. Figure 23b shows a pairing response package, where flags: Keypress, MITM, and Bonding are set to CC2540DK. These results are related with input/output capabilities supported because the CC2540DK supports the keyboard as the input and the display as the output.
The same procedure of the previous section is used. The connection between CC2540DK peripheral and the GS gateway is sniffed with Ubertooth and Wireshark following the configuration shown in Figure 3d. As a result, a file with ".pcap" or ".pcapng" extension is generated, which is used by the Crackle tool with command (17). Figure 24b shows the output of command (17) for CC2540DK. As for Section 6.2.1, Figure 25b shows the encrypted LTK, while Figure 24b shows the decrypted LTK through the capture of Wireshark.
Function (18) is used to generate the key to encrypt the channel. The values of rand, p1 and p2, are obtained in the pairing process [82]. In the case of CC2540DK, the TK is recovered because crackle applies brute force since it is a six-digit pin. Figure 26b shows how sensible information about the service is recovered from CC2540DK. 6.2.4. Vulnerability 8: Passkey, Eavesdropping Attack CC2540DK supports the "PassKey" method because it connected with the BTool (via serial), which serves as interface to provide IO capabilities. Figure 23b shows a pairing response package, where flags: Keypress, MITM, and Bonding are set to CC2540DK. These results are related with input/output capabilities supported because the CC2540DK supports the keyboard as the input and the display as the output.
The same procedure of the previous section is used. The connection between CC2540DK peripheral and the GS gateway is sniffed with Ubertooth and Wireshark following the configuration shown in Figure 3d. As a result, a file with ".pcap" or ".pcapng" extension is generated, which is used by the Crackle tool with command (17). Figure 24b shows the output of command (17) for CC2540DK. As for Section 6.2.1, Figure 25b shows the encrypted LTK, while Figure 24b shows the decrypted LTK through the capture of Wireshark.
Function (18) is used to generate the key to encrypt the channel. The values of rand, p1 and p2, are obtained in the pairing process [82]. In the case of CC2540DK, the TK is recovered because crackle applies brute force since it is a six-digit pin. Figure 26b shows how sensible information about the service is recovered from CC2540DK. AES(TK, AES(TK, rand XOR p1) XOR p2), The CC2650STK has several built-in services, which delegate security to the lower layers of the Bluetooth protocol. This vulnerability is exploited using the Bleah tool, which sends malformed frames and causes the output value to be altered. From command (2), the selected service to be attacked is humidity. Then command (19) is launched in order to inject the character "j". Figure 27a shows how the output of Bleah indicates that byte "j" was sent. In order to probe the fuzzing attack, the humidity period value is read from the GS server and the GE server. As shown in Figure 27b, the value of the humidity period is "j" and, therefore, the value was injected.
sudo bleah -b "54:6c:0e:80:9a:03" -u "f000aa23-0451-4000-b000-000000000000" -d "j", The CC2650STK has several built-in services, which delegate security to the lower layers of the Bluetooth protocol. This vulnerability is exploited using the Bleah tool, which sends malformed frames and causes the output value to be altered. From command (2), the selected service to be attacked is humidity. Then command (19) is launched in order to inject the character "j". Figure 27a shows how the output of Bleah indicates that byte "j" was sent. In order to probe the fuzzing attack, the humidity period value is read from the GS server and the GE server. As shown in Figure 27b, the value of the humidity period is "j" and, therefore, the value was injected. sudo bleah -b "54:6c:0e:80:9a:03" -u "f000aa23-0451-4000-b000-000000000000" -d "j",

Risk Mitigation and Counter Measures for RFID/NFC
Physical and cryptographic solutions can be used for protecting the privacy of RFID tags against possible attacks and threats. Some solutions are discussed below.
• The Faraday cage is an easy way of protecting an RFID tag that is inspired by the characteristics of electromagnetic fields [84]. • The protocol used in communication between tags and the reader is randomized at each communication, which does not allow obtaining the data contained in the tag or even knowing the id tag. Thus, the tracking of the tag will be impossible [85]. • To defend against the RFID attacks' replay, some simple counter measures exist such as the use of timestamps, one-time passwords, and the challenge response cryptography. • A blocker tag is similar to an RFID tag with the difference being that it can block readers from reading the identification of those tags that exist in the blocker tag's range [86]. Many possibilities will be generated by the blocker tag based on the serial number of the consumer tag. Therefore, the reader will not obtain the correct identification tag. • A new coding scheme can be integrated in RFID parts used in both frontal and backward communication. In Reference [87], the RFRJ coding scheme is used to get content of tag using the secret key since an adversary will fail to obtain the data from the tag. • Crypto attacks can be eliminated by using strong cryptographic algorithms, following open cryptographic standards and using a key with enough length.

Risk Mitigation and Counter Measures for RFID/NFC
Physical and cryptographic solutions can be used for protecting the privacy of RFID tags against possible attacks and threats. Some solutions are discussed below.

•
The Faraday cage is an easy way of protecting an RFID tag that is inspired by the characteristics of electromagnetic fields [84].

•
The protocol used in communication between tags and the reader is randomized at each communication, which does not allow obtaining the data contained in the tag or even knowing the id tag. Thus, the tracking of the tag will be impossible [85].

•
To defend against the RFID attacks' replay, some simple counter measures exist such as the use of timestamps, one-time passwords, and the challenge response cryptography. • A blocker tag is similar to an RFID tag with the difference being that it can block readers from reading the identification of those tags that exist in the blocker tag's range [86]. Many possibilities will be generated by the blocker tag based on the serial number of the consumer tag. Therefore, the reader will not obtain the correct identification tag.

•
A new coding scheme can be integrated in RFID parts used in both frontal and backward communication. In Reference [87], the RFRJ coding scheme is used to get content of tag using the secret key since an adversary will fail to obtain the data from the tag. • Crypto attacks can be eliminated by using strong cryptographic algorithms, following open cryptographic standards and using a key with enough length.

•
The "sleeping" mechanism is another type of physical solutions. In this approach, the reader sends a "sleep" command including a password to the tag to make it temporarily inactive [88]. • A successful countermeasure against the skimming attack is the use of a multiple loops antenna [49].

Risk Mitigation and Countermeasures for Bluetooth
Organizations should mitigate risks to their Bluetooth implementations by applying countermeasures to address specific threats and vulnerabilities. Some of these countermeasures cannot be achieved through security features built into the Bluetooth specifications.
The main measure is that organizations must invest in awareness-based education to support staff understanding and know Bluetooth technology. Therefore, the first line of defense is to provide an adequate level of knowledge for those who will deal with Bluetooth-enabled devices.
Organizations should establish and document security policies that address the use of Bluetooth-enabled devices and users' responsibilities. Policy documents should include a list of approved usages for Bluetooth and the type of information that may be transferred over Bluetooth networks. When feasible, a centralized security policy management approach should be used in coordination with an endpoint security product installed on the Bluetooth devices to ensure that the policy is locally and universally enforced. Another line of defense is to secure the services implemented in the application layer, e.g., using end-to-end encryption mechanisms, so that they are not delegated to the lower layers. Lastly, the security policy should also specify a proper password usage scheme.
The general nature and mobility of Bluetooth enabled devices increases the difficulty of employing traditional security measures. Other mitigation techniques are listed below.

•
Default settings should be updated to achieve optimal standards [62]. • Ensuring devices are in and remain in a secure range. This is done by setting devices to the lowest power level [60]. • Use link encryption for all data transmissions to prevent any eavesdropping, including passive eavesdropping [62].

•
Users should ensure that all links are encryption-enabled when using multi-hop communication [60].

•
Lower the risk of broadcast interceptions by encrypting the broadcasts [62].

Conclusions
Predictions regarding the number of connected IoT devices are clear. Therefore, the need to pay attention to security is high. In this article, two of the most used IoT technologies known as RFID and Bluetooth have been analyzed in terms of topology, architecture, messages/data, and security. A comprehensive review of vulnerabilities, security risks, and threats has been carried out for both technologies including information from several dataset analysis tools like CVE-MITRE, NIST, and CVE-Details. Subsequently, six architectures have been built to perform the practical analysis. All architectures have been deployed on a Raspberry Pi device due to its portability and easy management. By using open source and open hardware tools such as Proxmark3 for RFID/NFC and Ubertooth, BtleJuice, and Bleah for Bluetooth, practical analyses have been carried out, which demonstrates some mentioned vulnerabilities and provides a working methodology. Particularly, the Proxmark3 has been shown to be a powerful tool for reading, writing, cloning, and emulating the most low frequency RFID tags. In particular, it has been shown how two tags (EM4100 and HID ProxCard) can be cloned, by using the T7755 tag as a card to emulate both. Proxmark3 has been used to build two attacks in order to test the Mifare Classic security. Specifically, the mfkey attack and the nested attack have been launched. On the other hand, some vulnerabilities have been exploited for Bluetooth by using attack patterns like eavesdropping, MITM, and Fuzzing. Moreover, for both Just Works and Passkey Entry, the Long Term Key and sensible information have been recovered.
In addition, BtleJuice has been used to carry out a MITM attack, while Bleah has been used to build a fuzzing attack. The baseline, methodology, and steps of security tests have been described in detail.
Future lines are being developed for both technologies. Security analyses for second generation EPC UHF RFID tags, such as ALN-9640 Squiggle and Monza R6-P, as well as NFC cards, such as DESfire EV1 and DESfire EV2, are being developed. For Bluetooth, demonstration environments are being built for both the LE Secure mode and the Bluetooth mesh topology.