 introduction to BLE security. BLE communications often occur in public environments and that is why it's very critical to apply some security measures to maintain the confidentiality and integrity of data. Luckily cryptography can help with that quite a lot. The second major concerns with BLE is the authenticity of both devices that are creating the link. In other words the device we are trying to connect to is it really the one that it claims to be? And there are several protocol methods that can make sure that this is the case. Next concern is authorization. So even when we create the link we may try to restrict the access to certain data. And authorization is deeply embedded inside the BLE stack and it lets the user application to decide which data and when are exposed to the party we are connected to. Another concern in BLE security is privacy which is the ability to track devices and their users but this is outside of scope of this video. Let's now look at the possible threats that can occur in Bluetooth Low Energy. The simplest type of attack is passive e-dropping where the attacker simply listens on the communication channels and can capture all the communications all the data that are exchanged between the two parties. If the BLE link is non-encrypted the attacker has an easy job. If the two parties want to encrypt the link they first need to go through the so-called pairing procedure which is derivation of a shared secret which is later used to encrypt the link. In some older version of Bluetooth prior to Bluetooth 4.2 there is a possible issue. If the attacker if the passive eavesdropper is present during this negotiation of a shared secret the attacker can also derive the key which means it can make sense of the data even though the link is encrypted. Luckily this was later improved by the secure simple pairing in Bluetooth 4.2 and later versions. Another very common type of attack is man in the middle. There is a third party, malicious third party that is acting in the middle of the link and impersonates both the initiator and responder. Such an attacker is able to insert data or remove it from the BLE link. Some of the pairing methods provide protection against such attack and others not. So it's important to understand the security requirements and the configuration that must be done on the application side. Before we move forward let's quickly review the architecture on STM32WB. The device is a dual core and it integrates Cortex M0 plus and Cortex M4. Cortex M0 plus is a black box from the application point of view. It runs the RF stack whether it's Bluetooth, Zigbee, Thread or even some low level access to the radios. For purpose of this video we will focus only on the Bluetooth stack. In the pictures you can see various levels of Bluetooth device and Bluetooth host that both form the Bluetooth stack. If we start from the bottom you see the link layer which among other things is responsible for encryption of the link. In the upper layer you see the security manager which manages pairing and bonding procedures. We'll see shortly what it means in more details. The data that are exposed to the outside world over BLE are stored in a gut server in so-called gut database. It's up to the BLE service to define requirements for this data. So let's imagine our device is a heart rate which is adopted service by Bluetooth specification and it exposes the value of a heartbeat. It's up to the specification of the service whether the data require encryption, encrypted link or whether it requires protections against man-in-the-middle attack and so on. The user application runs on the Cortex M4 which interfaces with the RF stack over high level command interface called ACI application command interface. So the user application sends these commands towards the BLE stack and in the other direction the BLE stack may send ACI events towards the application to process. When the link is encrypted the payload of every single data packet is encrypted plus there is a four byte message integrity check that is calculated over the plain text payload plus part of the header. The cryptography scheme is AES in counter mode with CBC Mac so symmetric cryptography. Let's now have a look how to establish secure link over BLE. There are two devices STM32WB which acts as a BLE peripheral and at the same time as a gut server so it exposes two characteristics to the outside world. One that can be read and another one that can be written. Mobile phone acts as a BLE central and at the same time as a gut client. Procedure starts by the peripheral device advertising its presence. Central performs scanning, it detects these packets and sends a connection request. Then central device performs service and characteristic discovery to understand what type of data and service is hosted on the gut server. At this point central may initiate pairing which means establishment of a shared secret between the two devices. This shared secret is then later used to derive a session key for the link encryption and this is what happens in the last stage. The link is encrypted. The level of security of this link depends on the pairing method that was used. The method can provide protection against eavesdropping against eavesdropping plus man in the middle attack which is also called authenticated link or it can provide neither which means the pairing must be done in secure environments only. But even for the last case if the pairing information is stored persistently in the device which is bonding the subsequent connections may occur securely even in the non-secure environments. So which keys are generated during the pairing procedure? Well firstly it's a long term key or short term key which is used to derive the session key which in turn is used to encrypt the payload and calculate the message integrity check. The security level of these keys depend on the pairing method that was used to derive them as we discussed just early before. Another key is identity resolving key which is used for privacy so the ability to track identity of the devices and its users and we will not discuss that in more details. The last key is connection signature resolving key which is used to authenticate the payload on an unencrypted link. This is a special feature that we will touch briefly at the end of this video. The following timeline shows the evolution of Bluetooth specification since the beginning in 1999. Bluetooth low energy was introduced in version 4.0 in 2010. Four years later in BLE 4.2 a major improvements have been done especially to the security. The introduction of the Diffie Hall-Monkey Agreement Protocol means that all pairing methods provide protection against passive eavesdropping even if the pairing is done in a non-secure environment. This is not the case with so-called legacy pairing in BLE 4.0 and 4.1. The versions are backward compatible unless the legacy pairing is explicitly disallowed by the user application. Pairing methods are also known as association models. For legacy pairing there are three. Just works which requires no interactions by the user nor any input-output capabilities on each device such as keyboard or display. The second one is pass key entry and the third is out of band which is typically based on NFC or some optical based method like QR code or barcode. Secure simple pairing introduces one more and that's numeric comparison. None of the legacy pairing methods provide protection against eavesdropping so the pairing must be done in secure environment only. The exception to this is out of band which is secure provided that the out of band channel is secure. On the other hand secure simple pairing provides protection against eavesdropping and that's thanks to the elliptic curve Diffie Hall-Monkey Agreement Protocol. Just works provide no protection against man and middle attack. Since there is no interactions by the user required there is no device authentication. So let's now have a look at each pairing method in more details and from now on let's focus on secure simple pairing only. Assume we have a mobile phone which acts as a BLE central and the device we are trying to connect to is BLE peripheral. On the phone we start scanning for all the devices that are advertising around us. We select the device we want to connect to either by the BLE address or by the device name that's advertised. The phone performs service and characteristic discovery and optionally it will start pairing so generating a shared secret and later encrypting the link. With just works there is no way to verify the authenticity of the pure device so this method may be subjected to man in the middle attack. Apart from allowing the pairing on the telephone side there is no user interactions required. The pairing procedure via passkey is very similar. The only difference is that during the pairing one device shows a six digit number that we must enter via keyboard into the second device. Now the key point is that even if there was a man in the middle he would have to know this six digit number. If the numbers don't match the pairing procedure is immediately terminated and the chances of man in the middle guessing the right value is only one in a million since the number is six digit long. Now with numerous comparison this procedure is even simplified. During pairing both devices show the same six digit number and user is required to confirm that these values are the same. The only requirement is that the both devices must have a display. Out of band pairing is arguably the most secure provided that the out of band communication channel is secure which is typically the case for NFC due to the close proximity nature. With the phone it can work for example like this which we take the phone and tap the NFC tag we can read the identity information and also the security related information from the device. The operating systems on the phone or the application running on the phone can then use this information to connect securely over Bluetooth. Pairing over NFC can bring many benefits to the user. First of all it's faster and simpler. The only interaction that you need to do is to take your phone and tap the device. Based on this the phone can launch application and in the case of Android it can also start a pairing procedure. There are no conflicts which means that if you start scanning in typically office environment you may find that there are tens of devices so you might have to go through the list and select the correct one. With the NFC you pair directly to the device that you want. As we said it's very secure due to close proximity nature and the size of the exchanged credentials. It's also low cost especially if you require man in the middle protection. The other possible options is that the device integrates either a keyboard or a display so you may find it the low cost solution to integrate an NFC tag instead. It's very easy to use especially if you compare it to other out of band methods like QR codes or bar codes. The device can be completely sealed which is very useful for example if you require waterproofness. It can save power. The device can be in very deep low power mode and it can wake up and start to advertise only upon a detection of the field on the NFC. ST offers wide selection of NFC devices. The best solution for true out of band pairing is the dynamic tag ST25D. This device features two interfaces wireless and wired which is typically I2C that is connected to the host microcontroller. The reason why this is necessary is that the security credentials for Bluetooth pairing shall be random and unique for each pairing so they shall be generated and written to the tag by the host microcontroller before they are read out by the NFC reader. The simplest solution is the passive tag ST25T. These devices they are typically standalone they come in a form of a sticker or a label. These devices cannot provide the OOB security feature since the microcontroller cannot write the credentials into them. However it can still simplify the connection and pairing procedure. The identity information for the Bluetooth node can be statically stored inside the tag and the reader which reads the information out can connect to one particular device without searching through the list of all the advertising nodes around. The most complex application might take advantage of NFC reader ST25R. This reader can work as a tag in card emulation mode or it can even read other tags and initiate the connection over BLE or even pairing over OOB.