 Hello, everyone, and thanks for joining us today. My name is Keith Walters, and I'm a Regional Technical Marketing Manager for Memory and RFID at FT Microelectronics. Today we'd like to talk about secure Bluetooth pairing made easy using NFC. The use of NFC for Bluetooth pairing has been around since 2007 with the introduction of secure, simple pairing by the Bluetooth Committee. Over the course of the intervening years, the Bluetooth specification and the associated security protocols have evolved significantly. Today, the main issue with correctly implementing secure Bluetooth communications is simply the raw size and complexity of the Bluetooth specification itself, just to give you an idea. Version 5.1 of the core specification itself is 2,985 pages long. So today, what we'd like to do is to wade through all that documentation for you and focus on just the key components required for secure Bluetooth pairing. Now, the reason why we're discussing this topic today is twofold. One, a significant majority of smartphones being shipped are now capable of near-field communications. NFC is experiencing a compound annual growth rate of over 20% will reach a market value of around $23 billion by the year 2023. Two, Apple has just opened up NFC Read-Write capabilities in iOS 13. This means that the two major mobile platforms in existence, iOS and Android, now fully support near-field communications. You can leverage this development to provide a completely new features to your designs while maintaining consistent user experience regardless of the mobile platforms your customers are using. So what is NFC? NFC is a subset of radio frequency identification. RFID covers a large number of different frequencies, such as 125 kilohertz for low-frequency RFID, 868 to 960 megahertz for ultra-high-frequency RFID, and 13.56 megahertz high-frequency RFID, which is the band that NFC uses. NFC is also governed by a number of different ISO standards, which determines how the field is modulated and how the data is encoded. There's ISO 14443A, ISO 14443B, and ISO 15693. There's also Sony Felica, but it's normally not found outside of Japan. All of the different requirements that govern NFC are maintained by the NFC Forum. The NFC Forum develops test specifications and test mechanisms to ensure consistency and reliability of NFC transactions and interoperability of NFC devices produced by different manufacturers. They also standardize the data formats for various use cases, such as URLs, telephone numbers, and handover messages. NFC is quickly growing. In 2018, two out of every three smartphones shipped with NFC is a standard feature. Also, NFC is the basis for Apple Pay. Since its introduction, Apple has been slowly opening up NFC to applications developers. Now Apple has completely opened up NFC in iOS 13, thus enabling new use cases such as Bluetooth pairing using NFC. Going more in-depth with NFC, we want to compare and contrast it to Classic RFID. In Classic RFID, you only had one use case, and that was an active reader communicating with a passive tag. A common application would be library book checkout. The book would have an embedded tag, and the checkout desk would have a reader that would be used to log the book checkout and deactivate the alarm. NFC brings to the table two additional operating modes. One of them is known as card emulation mode, which is the foundation of Apple Pay, Android Pay, and Samsung Pay. This is where you have an active reader emulating a passive tag, and how you can have your smartphone emulate a Visa card or Mastercard, allowing you to pay for merchandise by simply tapping a point of sale terminal. The additional mode that NFC offers is called peer-to-peer mode. This is where you have an active reader communicating with another active reader using NFC. An example would be a smartphone communicating to another smartphone, allowing you to transfer a V card, telephone number, or playlist simply by tapping the two phones together. The maximum data transfer rate in NFC is for peer-to-peer transfer, which is 424 kilobits per second. There are proprietary modes that support higher data rates, such as 848 kilobits per second, and ST offers readers that support rates as high as 6.8 megabits per second, but this is outside the NFC forum specification. When you have an active reader communicating to a passive tag, the data rates will depend upon the tag type and the modulation method used. For ISO 15693, you can expect to obtain a data rate of 27 kilobits per second and up to approximately 53 kilobits per second if the tag supports fast read mode. For ISO 14443, you can achieve a maximum data rate of 106 kilobits per second. Now, most tags do not store an appreciable amount of information, so you will not notice much of the difference in reaction time between ISO 15693 and ISO 14443. What you will notice is that ISO 15693 will give you about a 30% improvement in read range when using a standard smartphone compared to ISO 14443A. This will help in non-optimal environments, such as when there's a significant amount of nearby metal or non-ideal alignment between the smartphone and tag. Because of the longer range and higher sensitivity of 15693, you'll have a better chance of reading the tag in these cases. Also, the NSC forum defines a number of tag types. There's type 1 to type 5. The main difference between the various types of tags are different combinations of features, storage, and security. For instance, some tags will support anti-collision, allowing communication with an individual tag during multiple tags in the reader field. Some tags will support advance levels of security or incorporate security processors for banking and identification applications. ST supports the most popular tag types that are out there, types 4 and type 5. These types provide the highest level of data storage and features while also providing excellent read performance. NFC is not designed to compete with other wireless technologies like Bluetooth or Wi-Fi. It is designed to complement them. With NFC's inherently short range, you can use it to securely transfer network credentials to participating nodes, such as PAN IDs, passwords, and encryption keys. Also, due to the fact that NFC is a zero-power technology, these nodes do not even have to be powered on in order to configure them. This makes networks set up fast, simple, and far less prone to error. Now, the big news here is the fact that iOS 13 has added both tag reads as well as tag writes. For the longest time, Apple only supported what was known as card emulation mode for Apple Pay. In iOS 11, they added the capability of doing tag reads using what's known as NFC Core. In iOS 12, they rolled that support directly into the operating system. And in iOS 13, they've now completely opened it up for the fact that you can do both tag reads as well as tag writes. You can also support custom commands as well, too. This means that Apple now supports NFC to the same degree that Android has supported since around 2011. And it means that both major mobile platforms now support all the capabilities that NFC brings to the table. This means you can actually leverage this mobile infrastructure that you didn't have to pay for in order to add some new features to your product at a very, very low price point. NFC for Bluetooth pairing shows the evolution of the Bluetooth specification since its inception in 1999. Prior to version 4.0, Bluetooth had only a single radio, the basic rate enhanced data rate radio, with a single security scheme. Version 4.0 of Bluetooth introduced low energy radio. LE only is known as Bluetooth smart. And with Bluetooth smart, you had a completely different method for pairing this new radio. For radios that supported both BR, EDR and LE, known as Bluetooth smart ready, pairing process was quite complicated since your application had to support two very different pairing schemes. This continued up until the introduction of Bluetooth 4.2. And both the BR, EDR and LE radios harmonized their pairing security schemes while their authentication encryption methods became functionally identical. This combination of BR, EDR and LE security is known as secure connections. We're all familiar with pairing by entering a pin or doing a number comparison between two Bluetooth devices to ensure that they are correctly connected. But this requires a user interface of some sort, such as a keypad or a display. And this has cost, complexity, size and power consumption. For instance, if you're making a pair of Bluetooth wireless earbuds, there's simply no space for a keypad or display. With NFC out of band pairing, you can drop the user interface while actually improving the level of security. So how does Bluetooth pairing work? Basically, when a phone is tapped to the tag, the field generated by the phone powers up the tag. Some of our tags offer a general purpose output pin that is asserted when the NFC field is detected. This pin can then be routed to the Bluetooth radio and used as a wake-up interrupt from a deep sleep or deep power down mode. Next, the tag provides the radio address and authentication credentials to the phone by load-modulating the NFC field generated by the phone. This information is then used to pair the phone with, in this case, a Bluetooth speaker. One benefit to the end customer is that NFC-enabled Bluetooth pairing is faster and simpler. There's no need to scan for radios or set yourself in discovery mode or enter a pin and confirm it. It's just a simple tap and pair. Another is that there are no conflicts. You know exactly what you're pairing to because you're physically tapping it. NFC is low-cost since you can eliminate the user interface required by other pairing methods. This allows you the ability to realize a smaller, more inexpensive solution. Also, with the elimination of a display and input keys, it's much easier to hermetically seal your device to meet waterproofing or chemical wash-down requirements as with medical applications. NFC is superior to QR codes since you do not need line of sight. Also, QR codes can be rendered unreadable if the pattern is damaged or covered by dirt or contaminants. NFC does not suffer from the same limitations. Finally, NFC does allow you to save power. By leveraging in zero-power capabilities, NFC allows you to leave a battery-powered device in a deep sleep mode longer and wake the unit with just a tap. Pairing information is stored in an NFF record. NFF is short for NFC data exchange format and is the standard format defined by the NFC forum to store data on an NFC tag. One or more of these NFF records can be contained in a single NFF message. Each NFF record can store information representing a URL, text, SMS, a phone number, et cetera. In the header of each NFF record is a field called the record type definition, which defines what the data payload means. If the type is what's known as a well-known type, then the appropriate application can be invoked in the data loaded into it. For example, if data on a tag represents a telephone number, your phone will read the data, open up the phone dialer, and automatically copy the number into the dialer app. For the case of Bluetooth pairing, that well-known type is called a MIME type. MIME stands for Multi-Purpose Internet Mail Extensions. MIME was originally created to extend the capabilities of internet email clients to handle formats beyond just basic text, such as audio, images, et cetera. They're an enormous number of MIME types. Bluetooth pairing is a specific MIME application type known as a multi-part message digest. Multiple parts of the message cover different pieces of information that can be used for pairing, such as authentication results, encryption keys, MAC addresses, et cetera. Bluetooth BR-EDR and Bluetooth LE had different MIME formats. Many radios support both BR-EDR as well as LE, and you can configure them both in the same NDef message by defining each radio and its own individual NDef record, and then combining the two records into one NDef message. So what does an NDef pairing record look like once it's recorded to a tag? Well, an NDef record starts out with the NDef record header. Within the header, there's a field known as a type name format, and in this example, the value of that field denotes a MIME format will follow. Further on down, once you get to the record type name, you'll determine that the MIME type is going to be for a Bluetooth low energy radio. Following this field are two required fields known as LE Bluetooth address as well as the LE role. After these two fields are some optional fields known as the appearance of the device as well as device local name. So what kind of NFC tags are available to implement Bluetooth pairing? Starting with our most flexible solution, we have the I2C dynamic tag. The dynamic tag is a dual port EPROM, one port is I2C, and the other port is NFC. Since the contents of a dynamic tag can be updated on the fly by the host, it offers a lot of the same capabilities of an active NFC transceiver, such as random private addressing, dynamic advertising of carriers, or updating security keys and authentication data. The dynamic tag also has a field detect pin that can be used to wake the host from a deep sleep or deep power down mode. An additional benefit of our ST25 DV tag is that they offer an SRAM buffer in addition to EPROM memory that can be used to stream data, such as a firmware update. Finally, our dynamic tags also offer energy harvesting from the NFC field, where you can expect around two and a half to three volts at four milliamps with a dedicated reader. This will of course depend upon such factors as the antenna size, reader power, and distance between the reader and tags. Lower cost option for implementing a NFC pairing tag is a static tag with a field detect output. Now this does still allow the ability to wake up a host from a deep sleep mode once the NFC field is detected, but because there isn't that I2C interface between the host and the tag, the tag contents are static. This means you cannot implement dynamic addressing, you cannot really update any of the secure pairing information because this information is usually refreshed on every pairing cycle. Also, because of this lack of interface between the host and the tag, you have to advertise all the carriers that are available. Then, whether you want to use a carrier or not, that has to get negotiated over Bluetooth. Many low cost Bluetooth speakers do use this kind of tag option since they typically only have one carrier and many of them don't really need to be all that terribly secure. And finally, the lowest cost option can be accomplished with a static off the shelf sticker tag. The tag would contain the Bluetooth MAC address as well as the device roll. It can be used to simplify the pairing process, but the radio would have to already be powered on in order to enable this pairing. And once again, due to the static nature of the tag, dynamic addressing or carrier advertisement where any of the secure pairing exchanges cannot be accomplished with this tag. The table shown here details the evolution of Bluetooth security for both the Bluetooth basic radio as well as the Bluetooth low energy radio. Prior to version 2.1 of the specification, the pairing method incorporated the safer algorithm, which stands for secure and fast encryption routine. With the introduction of version 2.1 of the specification, the pairing method was upgraded to elliptic curved Diffie-Hellman P192. And in version 4.1 of the specification, Bluetooth basic rate enhanced data rate radios utilized the elliptic curved Diffie-Hellman P256. Now, in version 4.0 of the specification, this is where Bluetooth low energy was introduced and the security scheme incorporated utilized a temporary key in combination with a short-term key. In version 4.2 of the specification, the low energy radio was also upgraded to the same elliptic curved Diffie-Hellman P256 algorithm. At this point, Bluetooth low energy and Bluetooth basic rate enhanced data radios utilized the exact same pairing methods. This combination is known as Bluetooth secure connections. Secure pairing is intended to support a number of potential Bluetooth security threats. One of these potential threats is passive eavesdropping. This is where you have two nodes communicating with each other over a Bluetooth link in the third party attempting to listen in. In earlier versions of Bluetooth, the initial keys were either set to zero for something simple, such as 0000 or 1234, making it relatively easy for a third party to decrypt the link. NFC, due to its inherently short range, is extremely difficult to eavesdrop on since the power of the signal drops at one over R to the power of six. To listen into an NFC key transfer from just a few feet away would take a very large loop antenna with a high power amplifier in order to do so. Also, with the introduction of public private key encryption, passive eavesdropping has become less of a security concern. Another potential security threat is known as the man in the middle or active eavesdropping. This is where a third party inserts itself in between two Bluetooth nodes. To the master node, it impersonates the slave. And to the slave node, it impersonates the master. Once in this position, the man in the middle can intercept all the traffic going between the two nodes as well as adding or removing data from the data stream. If you use near field communication to transfer the pairing credentials between the master and slave, it makes it very resistant to man in the middle attacks. Once again, due to the inherently short range of near field communications and to the 128 big key sizes that are possible for LE legacy. And finally, another potential security threat is known as identity tracking. This is where someone attempts to attach your identity to a static Bluetooth MAC address. Then, every time you power on your Bluetooth LE radio, which typically advertises your address continuously, you will potentially be able to find your physical location. The way Bluetooth overcomes this, starting with version 4.0 of the specification, is with resolvable private addressing. A resolvable private address is an address that is generated using a hash of a random number in the secret identity resolving key, which is shared between two trusted devices at the time of pairing. Pairing is a three phase process. Now, the details of what occurs in each phase depends upon what kind of security you're implementing and what version of Bluetooth you're using. Now, in phase one, this is known as feature discovery. The two devices exchange what kind of input output capabilities they have. Do you have a keyboard? Do you have a screen? Do you have a simple button? And also they determine what kind of pairing method that you're gonna use in phase two. Now, in phase two, if you're doing LE legacy pairing, you initially have a temporary key and the temporary key depends upon how you paired. And then from the temporary key, you then combine that with the addresses and random numbers to derive a short-term key. And that short-term key is never transmitted over Bluetooth at all. The secure connections, which is version 4.2 of Bluetooth and beyond, this is where you use your public private key, elliptic curved Diffie Hellman. In this case, you just automatically generate your long-term key. In phase three, if you're using LE legacy, you would then take your short-term key and use some randomizers to generate a long-term key. Or if you're already in the long-term key phase, then you would disseminate some additional keys, such as the connection signature resolving key, which signs data. And also you have that identity resolving key for that random private addressing. Now, once two devices have been paired, it can be quote-unquote bonded. This is where they take the long-term key they've decided upon and store that in memory. So the next time they encounter each other, they can skip this entire process and immediately just jump to using the long-term key in order to communicate with each other. Simple and secure pairing introduce four different kinds of pairing methods. These are known as JustWorks, Passkey, AmericanPerson, and Out-of-Band. JustWorks means there's no key entered. The devices identify each other and automatically begin communicating to each other. Therefore, there's no secure encryption and there's no authentication. In this case, you get virtually no protection against man-in-the-middle kind of attacks. With Passkey entry, this is where you enter a six-digit PIN code. And then in AmericanPerson, where you have LE secure, both devices would have a display and if that exact same number shows up on both displays, then the user confirms the match. Note that in AmericanPerson, the number that shows up on the display is not used to generate the security keys. And for Out-of-Band, this is where you use NFC or QR codes to enable the pairing. You use this alternative communications channel to exchange authentication data, MAC IDs, potentially even temporary keys. Now, for LE legacy pairing, there don't have a numerical comparison equivalent. And also JustWorks and Passkey entry provide no activities drop protection. This is due to the fact that they're not using that elliptic curve Diffie-Hellman for the initial key exchange. When discussing NFC Bluetooth handover, there are a number of terms you will commonly encounter. One of them is the handover requester or initiator. This device initiates the handover operation. It's also referred to as the master. A handover selector responds to the initiator. It's also known as the slave. And it tells the initiator what its capabilities are. A handover mediator is a device that facilitates a connection between two different nodes, but in the end does not actually participate in the communications between them. This device would, for example, be a smartphone that you could use to configure a wireless network. The smartphone would have all the network credentials and you would tap and transfer those credentials to all the participating nodes. So how do two Bluetooth devices know how to pair? How do they know whether to use PIN over autoband pairing? This is all defined by the generic access profile. The gap layer of the Bluetooth LE stack handles connection functionality. This layer is responsible for access modes and procedures of the device. This includes device discovery, link establishment, determination, configuration of security features, et cetera. Now within the gap layer, you will find the security manager. The security manager handles the pairing and bonding as well as the parameter negotiation and encryption key generation as well as key distribution. So when does all this happen? Well, with pairing, it's a three-phase process and the method for pairing is decided upon in the first phase. Master or initiator advertises all of its IO capabilities, the size of key it can handle and the pairing method over Bluetooth. The slave responds in kind with its IO capabilities, key size and pairing methods over Bluetooth. Now if both devices have their autoband data flag set, then both devices default to NFC handover. There are a number of different NFC handover types. We'll start with the static handover. In this case, we have an active NFC transceiver, such as a cell phone, talking to a passive NFC pairing tag. Now the passive tag will incorporate in it the Bluetooth MAC ID along with the role of the device. Is it a printer? Is it a mouse? Is it a keyboard, et cetera? Because of the static nature of the tag, all of the available capabilities of that responder have to be advertised whether they're actually available or not at that given moment. Later on, there'll have to be a negotiation over Bluetooth as far as requesting whatever carriers are available and which ones aren't. Since the tag itself is static and the values for the randomizers and keys cannot be updated, simple secure pairing cannot be supported with the static tag. Another type of handover is the negotiated handover. In this case, either both devices have an active NFC transceiver or the master has an active NFC transceiver and the slave has a dynamic tag. Because of the dynamic nature of both of these endpoints, they'll be able to selectively advertise available carriers. So in this example, we have a phone talking to a smartwatch and the phone is asking for both Bluetooth and Wi-Fi. But because the battery is low on the smartwatch, it only offers a BLE in this case. Because of the dynamic nature of both endpoints, you can also support optional secure pairing. The final type of Vennessey handover is the mediated handover. In this case, with the static tag, in the system you would have a device, let's say it's a control panel, and it would contain an active NFC transceiver. It wants to communicate to a sensor which has a passive tag embedded in it. You would use a handover mediator, such as a smartphone or tablet, in order to facilitate the pairing process. In the first step, the cell phone or smart tablet would tap the device, initiating the pairing process. Secondly, you would take that same cell phone and tablet and tap it's the tag in the sensor, collecting all that sensor's output capabilities. Finally, you would transfer all of those output capabilities back to the device with a final tap. Now in this example, the end sensor has a static tag, so it is not capable of supporting secure pairing. But there's another type of mediated handover where both devices have active NFC transceivers in them. In this case, secure pairing is a possibility. NFC offers a number of different communication modes. Some of you may be wondering which modes are used in a handover request. Well, that depends. If both devices have an active NFC transceiver, then the peer-to-peer mode is used. The first device to send a handover request will assume the initiator role, while the other device will then default to the responder role. If both devices make a handover request, then a collision has occurred. In this case, the initiator role is then resolved using the collision resolution record, which is embedded into the end-def record. It is a random number whose value will determine which device becomes the initiator and which one defaults to the responder. As the secure simple pairing specification has evolved over the years, the format of the handover request record has changed as well. Each iteration of the handover record is assigned a major version number and a minor version number. If the two devices support different handover record versions, then there is a process on how to handle the differences. If the difference is in the minor version number, the request select exchange happens normally. If the difference is in the major version number, then the responder can either send an empty select record containing just its supported version number, or it can respond with standard select record, which also contains its version number. The requester will then have to decide on how to process the response it receives. If you're trying to pair one device that has an active reader to another device that has a pairing tag, then this is done in the NFC reader mode. In this case, the reader will scan for all the different types of tags it supports. Once the reader gets a response, you'll read the pairing information stored on the tag and then use it to complete the pairing process. The NFC polling loop shown here depicts how an active NFC transceiver might transition between listening for another transmitter and scanning for passive NFC listeners, such as tags or cards. In this example, we have a polling loop where, a majority of the time, we're listening for NFC transmissions. So this device will preferentially be a responder, switching to the initiator role when it encounters another device that can only respond. When the device is actively scanning, it will have to partition that time to query for all the different tag types that it supports. So in this example, the NFC transceiver spends a portion of time looking for type five tags using ISO 15693 protocol. Then it switches to type A, ISO 14443A tags, looks for another active peer to attempt peer-to-peer communications, and then finally switches to type Afsoni Felica. Now, if you have a device that would prefer to be an initiator rather than a responder, then the amount of time spent listening versus active scanning would probably be inverted when compared to this example. Secure pairing. In LE legacy pairing, the security of the link depends heavily on the security of the initial temporary key. The temporary key is defined by the pairing method used. For JustWorks, the temporary key is set to zero. This means that JustWork provides no security and no protection from either passive or active eavesdropping. For Passkey, where the same six-digit pin is entered on both devices, the pin becomes the temporary key and has a one in one million chance of a brute force attack being successful. But this also requires at a minimum a keypad on one of the devices and a display on the other. With NFC out of band pairing, the temporary key can be as large as 128 bits, thus providing the strongest level of security and making it much more difficult for a brute force attack to succeed while eliminating the need for any user interface at all. The temporary key determined in phase one is then used in phase two to mutually authenticate both nodes using something known as a confirmation number. This is a combination of place MAC addresses, random numbers, and the temporary key. The confirmation numbers and random numbers are exchanged over Bluetooth. Both nodes verify the other's confirmation number and, if successful, both derive the same short-term key using the temporary key and random numbers generated by the master and slaves. The LE legacy pairing sequence is shown in the diagram here. In phase one, both devices determine if they can use NFC pairing. If they can, then in phase two, they exchange their MAC addresses and temporary key using NFC while transmitting the rest of their required pairing information over Bluetooth. They authenticate by computing and exchanging confirmation numbers. The inputs to the confirmation function are the temporary key, random number, master and slave MAC addresses, address types, pairing requests, command, and responses. Since the temporary key and MAC address inputs to the confirmation function are transmitted via NFC, the Bluetooth eavesdropper won't be able to successfully compute the confirmation and, therefore, will be able to authenticate. Also, an eavesdropper won't be able to compute the short-term key either, since the short-term key generation function uses exchange random numbers along with the temporary key as well. Once the link is encrypted with the short-term key in phase three, the long-term key is computed and distributed along with other such keys as identity resolving key and the connection signature resolving key. For LE secure pairing, phase one is where both devices determine if they can use NFC pairing, just as in LE legacy. Unlike LE legacy, there is no temporary key. The two devices exchange their public keys and create a Diffie-Hellman encryption key, which is a node's private key, combined with another node's public key. So in this case, a master Diffie-Hellman key is a master private key combined with a slave public key. The slave Diffie-Hellman key is a slave private key combined with a master public key. If they can pair using NFC, then in phase two, they mutually authenticate using a commitment function, which is a hash of their public key combined with a random number. The public keys are exchanged over Bluetooth and the commitment and randomizer, as well as MAC addresses, are exchanged via NFC. Each device recomputes the other's commitment to see if they get the same result. And if they do, they then generate a long-term key based on the Diffie-Hellman key, some random numbers and the device addresses. The LE secure pairing sequence is shown in the diagram here. After both devices have determined they can pair using NFC, they start the mutual authentication process in phase two. Mutual authentication involves verifying whether the holder of a public key is also the holder of a master private key and is usually encompassed by a random number challenge response. In this case, authentication is accomplished using a commitment function using a hash of their authentication code, SHA-256 of the public key and randomizer. Bluetooth e-strapper would not be able to authenticate since it would not be able to intercept the commitment and randomizer, which are sent over NFC. And, even if it did, it would only be able to intercept the public keys and not have access to the private keys, which are used to drive the long-term key. Once this link is encrypted with a long-term key in phase three, the identity resolving keys and connector signature keys are also distributed. In this diagram, you can see a typical handover request record for a Bluetooth basic rate enhanced data rate radio. The mandatory fields are the collision resolution record, the alternative carrier record, the out-of-band data length, and the Bluetooth MAC ID. All the other fields are optional. The optional fields are a class of device, which is typically used to present an appropriate icon for systems that have a graphical display, the hash and randomizer values, which are used for secure pairing. The service class unique ID, which is used for uniquely identifying a device and its capabilities. And finally, the Bluetooth local name, which is a user-friendly name to identify the Bluetooth device. The Bluetooth low-energy handover request record has a number of similarities to the Bluetooth basic rate enhanced data rate request record, but there are some differences in the Bluetooth carrier configuration portion. So once again, the collision resolution record and alternative carrier are required, as well as the LE device address, and this includes both the public as well as the random private MAC address, length, type, and values, and also the LE role, whether it's a broadcaster observer, peripheral or central role. After that, all the additional fields are optional. You can have a security manager TK value to provide backwards compatibility for LE legacy applications. Also, you can have the hash C and randomizer to support secure pairing. The appearance field will cover whether it's a mouse, keyboard, et cetera, and kind of determines what icon will be produced for systems that have a graphical user interface. The local name is a user-friendly name for the device, and then there's a field for flags, which determine what features are actually supported by this Bluetooth low-energy device. If the responder has an active NFC transhever or a dynamic tag, then it can participate in a negotiated handover, and the select record is virtually identical to the request record. Since the responder's dynamic, it can support secure pairing as well as selectively advertising available carriers. In a negotiated handover scenario, conflicting roles can be resolved by retransmitting the handover request message with the new LE role preference. If the two NFC-formed devices have the same role preferences, both have peripheral and central role capabilities, the handover requester will need to change its role. If the handover responder is equipped with a static NFC tag, then the format of the handover select message will be a simplified version of the negotiated handover response. This is due to the fact that the temporary key values, hash, and randomizers used for secure pairing cannot be updated, so they are all set to zero. Additionally, all available carriers will have to be advertised regardless of their actual current power state. Next, I would like to discuss our NFC product portfolio as well as available demonstration platforms and evaluation tools. The ST25R Reader family spans the range from entry level all the way to the ultimate NFC front end. The ST25R 95 is a low price leader, typically found in high volume industrial and consumer applications. In volume, this reader can come in under $1. The ST25R 3911B was the first reader on the market to introduce the concept of automatic content tuning. When the antenna is either capacitively loaded, such as with the NFC smartphone, or inductively loaded, as with an NFC tag, the reader can automatically sense this and retune the antenna circuit. This allows it to maintain optimal output power under all circumstances. The 3916 builds upon the success of the 3911 by adding two-dimensional automatic content tuning, which can adjust both parallel as well as series capacitance, integrated noise suppression receiver, which can compensate for such things as power supply or LCD backlight EMI, and active waveform shaping. This makes the 3916 ideal for access control and contactless payment applications. The ST25R family differentiates itself from the competition, with its outstanding analog performance. Many of our readers have a high output power, which allows them to achieve a long read-write range. Additionally, some of our readers incorporate automatic content tuning. This allows them to compensate for changes in the environment and suboptimal conditions. Many of our readers also feature a low power wake-up using either an analog inductive ping or capacitive touch. We also provide a fast time to market. We have EMVCO, that's European Mastercard and Visa Company, reference designs for payment applications, as well as evaluation boards where we provide all the schematics, PCB Gerber files and physical materials, as well as intended design tools. Our software library is a MISRC compliant single library written to support all of our NSC readers and to allow for easy migration from one device to another. Finally, we do have full software integration into the STM-8 and STM-32 Cortex-Q ecosystems. ST also offers a broad range of NSC tag ICs. We support ISO 14443A, 14443B and ISO 15693. We have memory densities ranging from 512 bits all the way up to 64 kilobits and a wide variety of features such as password protection and digital signature which is used in anti-cloning applications. Now ST does not produce the complete tag. We work with third-party companies such as Identive and Tagstand in order to realize a complete tag solution. So please contact your local sales office to discuss your tag requirements. For our NSC dynamic tag offering, we have two main family members, the M24SR family and the ST-25DV. The M24SR supports ISO 14443A and appears as a type four NSC tag. The ST-25DV supports ISO 15693 and appears as a type five NSC tag. Other differences are the RF range. The ST-25DV has a theoretical maximum read-write range up to one meter due to its use of ISO 15693. In reality, this is only achievable with a dedicated high-power reader but even with a cell phone, you should see around a 30% improvement range over the M24SR. The ST-25DV also has energy harvesting as well as a fast transfer mode using an integrated 256-byte SRAM buffer. Similarities between the devices are that they both feature a digital output pin to indicate NSC field detection, which can be used to interrupt the host and they both come in PCB-friendly packages so you can solder them directly to a board and realize the tag antenna with a simple copper trace. For our dynamic tag, we do offer a wide variety of evaluation boards. A standalone system for evaluating the performance of our dynamic tags is the ST-25DV Discovery Board. If you want to actually do some development work with your own system, I would recommend the XNUCLEO NFC04A1 shield board attached to a NUCLEO board using either an STM8 or an STM32 base board for doing your code development. For the Discovery Board, a lot of people would like to know what impact it has by going to either a larger antenna or a smaller antenna. So we do also offer different antenna sizes to plug into the Discovery Board so you can evaluate for yourself what impact a smaller antenna has on the read and write range. Additionally, on the backside of the ST-25DV Discovery Board, we do have a site for soldering down blue energy Bluetooth modules. We have a variety of these modules available. We have Bluetooth 4.2 as well as Bluetooth 5.0. By soldering these modules onto the board, you will actually be able to experiment with dynamic tag pairing on your own using this kit. For our low-cost reader evaluation, we do also offer a reader in our M24LR Discovery Kit for the CR95, and also we do offer a shield board for the ST-25R95. Once again, this plugs into a NUCLEO board either the STM8 or the STM32 and allows you to do your own code development with this reader. For the ST-25R3911B, we have a wide range of Discovery Boards and NUCLEO Boards. The Discovery Board is a single board evaluation platform that uses USB cable plugged into a PC and allows you to evaluate such things as the automatic antenna tuning and tag reads and writes. If you want to do your own code development, I would recommend using the NUCLEO shield combined with a NUCLEO baseboard. We provide you with all the available firmware for you to write your own reader application. Now, if you're trying to do a point-of-sale terminal application, we do have a reference design for this. Getting through EMV Co-certification is an arduous process and we've already done a lot of work for you. So our ST-25R3911B EMV Co-board has been EMV Co-compliance tested and you provide the schematics as well as all the Gerbers and source code available to get you through L1 testing. All of our NSC application software is written in Java. This allows you to run our application code on any platform that has a Java virtual machine via Windows, iOS, or Android. We do have a software development kit incorporating our Java libraries that allow you to access all of our readers and their functionality. If you sign an NDA with us, we can provide you with these libraries as well as documentation on how to use the API calls so you can craft your own PC or mobile-based application for our NSC readers. One example of this Java application is our Android tap app. As you can see, by tapping your NSC-enabled phone to either a tag or another reader, we'll bring up a number of different screens that allow you access to all of the information that's available on the tag or other device. This picture shows a previous generation of the iOS tap app written for iOS 11. Going forward with iOS 13, you'll expand the menu options available in this application to allow not only tag reads, but also tag writes.