Hello and welcome to the destination Lorawan webcast serious thank you all for joining us today from around the globe. I'm up at Eagan. I'm the vice chair of the board and chair of the Technical Committee, Indoor Alliance and I'm the Vice President of Advanced Technology Development in activity. I will be your host and one of the speakers on today's webcast. Today's topic is focused on their own security, discussing security as a whole, from the network to the end device. Before we begin few housekeeping notes, this webcast is being streamed through your computer. There is no dial in number. If you are having any audio problem, it might be due to the Internet connection you have. And if the audio or the video freezes, please. Push a F5 on your keyboard. Refresh the page. And for the answers to common technical issues, click the help box at the bottom. On your screen there's an application. You will find the help button. And at the end of the presentation we are going to have a Q&A and there's a Q&A box on your screen. Feel free to submit your questions during the presentation and we will get to them at the end. An on demand version of the webcast will be available approximately 24 hours after this live webinar and you will be able to. View the webinar again and share with your friends and colleagues. Well, if you're interested in becoming a lawyer Alliance member, you can view a copy of the membership benefits available in the webcast resources box again, which you will find on the tool you are using right now. To view this webinar. And for any questions, you can always contact admin@laura-alliance.org regarding the membership benefits or the membership process or anything else about the Lore alliance. And today's webinar is brought to you. Special thanks to our sponsors are gold sponsors. Machine Q At Comcast Company and the silver sponsors are birds and Charter Communications. Would like to thank them making this broadcast possible. So coming to our webinar, as you know, the security of any wireless network or wireless architecture involves multiple parties. The end device and the network infrastructure and the communication channel in between the two. In today's webinar we have two parts. In the first part I will focus on the channel security. And the second part is about the end device security and Christopher Farr, who is the chair of Secret working group in the Lore Alliance and their principle architect includes Coyote will be focusing on the device security part. So let's start with the communication channel security. As you know Lorawan is a wireless communication technology and just like any other wireless communication technology like Wi-Fi, 3G-4G or 5G. Given that we are not able to resort to physical security in terms of like walls, guards, gates or dogs, we have to rely on cryptographic security. In the absence of physical access control, a number of threats become a possibility, such as unauthorized access to the network resources, spoofing packets, modification of legitimate or victims packets, and eavesdropping on 3rd party traffic. And the remedy for such threats are done with the thanks to various tools we have, such as mutual endpoint authentication data, original temptation replay protection, integrity protection, an encryption, and all using cryptographic algorithms and cryptographic keys. And that's where we use cryptography in securing wireless communication. And this is just a general template that applies to all sorts of wireless communication technologies. And obviously we have done the same. By addressing all these threads on Lorawan technology, the link layer communication technology between the end device on the network. Using the well established methods and algorithms as proven in the industry and in the rest of sliced couple slides, I will be talking about how we achieve every one of these facilities within our link layer specification within the Lorawan link layer specification so that the security for the communication channel comes out of box for all your deployments. So let's first look at the security credentials in order to perform mutual authentication between the end device and the network. We rely on a set of credentials being present both on the end device and a server called join server on the network side, join server is more of a authentication server. That stores a copy of the device credentials, so between the end device and the joint server they need to identify each other. So for device we use the so called Debbie UI as a globally unique identifier and for the network side, in order to identify the joint server we use the so called join you I as a globally unique identifier and the two share symmetric cryptographic key called App Key. This is 128 bit key. It's AES 128 bit key. And every device has a device specific key, so the same key is never used with any other keys using the same network or in other network. It is typically generated randomly. As such, even if it were to be compromised, it would. That compromise would not affect any other devices sessions. So starting with the with the set of security credentials being both on the end device and the joint server. We execute a mutual authentication procedure and in the low end world in our specifications it's called the joint procedure or any other name for that is the activation procedure which involves a roundtrip handshake procedure. That uses the device and network credentials and the shared secret key app key in order to achieve mutual authentication. Not only it achieves initial authentication, but it also generates the so called session keys which are used subsequently for securing the link and also securing the application payload delivery and to end between the device and the application server. These keys are called network session key and application session key and there as well AES 128 symmetric keys. And now that we have these session keys, we proceed to use this session keys for securing the data transmission. How do we do that? Well, we take the cleartext payload and encrypt that using the application session key as you would remember from the previous slide, the application session key is shared between the end device and the application server. As such, it provides end to end encryption. And the encrypted payload is taking taken in to the lower one frame. And what we add to that frame are a couple other attributes. On one side we have the device address in order to uniquely identify who the sender or receiver of this of this frame is, and secondly, A-frame counter. And this is a non repeating value that provides freshness for this frame. In order to prevent any replay attacks. And then by taking the devil their frame counter and few other attributes along with the encrypted payload. We we use network session key together with the AES CMAC algorithm to generate the message Integrity code which provides integrity protection and data origin authentication. As this frame is received by the ultimate destination. And again, with the thanks to the frame counter, which never wraps back to the same value in which never reused, we're able to have freshness so that frames cannot be replayed. So starting from the long term credentials and apki, we generate the session keys and we use this session keys in every frame. Both in the uplink direction and down direction to achieve all the bells and whistles you need in order to achieve a secure communication channel. And regarding the activation procedure. Which is how devices gets used on various networks. We have two variants in our standard. One of them is called over the air activation, which involves starting from the long term credentials like the join you iwi an app Ki. We run the joint procedure. More specifically, the device sends a join request. Receive the join, accept and then it sends an uplink frame to conclude the handshake. And through that it generates the session keys. Now we also have another abbreviated mode for activation, called activation by personalization, where we skip over the. Activation procedure the joint procedure of this handshake. And jump stuck device with the application session key and network session key. Now we do not recommend using ABP mode unless you really cannot run the joint procedure. There are some very special case or corner cases where the device cannot receive downlink or where the device may have to be provisioned on multiple networks simultaneously, and these are like super corner cases. Under such circumstances, you may have to resort to using the ABP. The activation by personalization mode but otherwise in any typical case, we highly recommend using the OTA. Over the activation procedure or the mode, and the reason is. OTA, you're able to regenerate the session keys, which provides more strength. Your security instead of using these same session keys over and over again or before you run out of the frame counters, you can always run the joint procedure again and generate new fresh session keys. That's possible with the OTA. And also with the OTA you don't need to personalize your device against a single network where the ABP devices are personalized against a single network as the session keys gets shared with that network server. An if you were to. If you want to really personalize device you would have to share the same session keys with another network and they will open the door for the so called Domino Effect. If one network is compromised, the other network that got the same session keys will be compromised as well. For those given devices as such. We highly recommend you limit use of ABP. Two very special circumstances with the OTA, you don't need to share the session keys can be generated per network. This device is using at any point in time. Another facility we have in our toolbox with Lorawan is the so-called firmware update over the air in short photo. Now, no matter what you do, for one reason or the other, you would probably need to upgrade or update the software running on the end devices. Maybe you will add some new features, or maybe you'll identify some bug in the application, whether it's a security bug or otherwise. You'll have to touch that device now instead of instead of doing this update by coming close to the device and then using a serial port or short range Bluetooth, or or. Or any other technology with the Laura when we provide the ability to update the software remotely over the lore and connectivity. Now when we talk about photo, actually in the context of security, there are two dimensions. On one end we provide the foster facility securely as well, meaning the firmware or the software downloaded to a device. They get signed. So malicious code cannot be downloaded on the on devices. And the multicast delivery is integrity protected using a group key. So for efficiency we use a group update using multicast for photo. And then we also on top of that we provide integrated protection for the Unix commands using device specific keys. So we have. We have a very tight, highly secure firmware update or dare procedure, so that's one side of the story. The other side of the story is photo itself is also a tool in our security toolbox. If you if you have to update the device in the field, you can rely on the Laura Van Photo feature so it becomes more like insurance to safeguard your deployements against any bugs or absence of any features you may feel the need in the context of security or otherwise in the future. Through using folder, you can make such updates in the field. So if I were to summarize what we have and this, this picture puts everything in in the context. So between the end device and the application server we have entered encryption and it's different segments of the data path. One being between the end device and the network server, we have the link layer integrity protection. Terminix protection is in short for having mutual endpoint authentication, data, origin authentication, integrity protection and replay protection. And on top of that we have data encryption not only over the air segment but also for the entrance segment between the device and application server. And then I also talked about the photo which provides insurance for being able to deliver future updates on the on device plus for any hardware level security where. If you want to safeguard the the. Topographique keys. Andy cryptographic algorithms running on the end device one can do so by using so-called secure elements on the end device. These are additional hardware components which provides equivalent hardware level security as you would have with the SIM cards. With the GSM technologies. So through that we we not only have the communication channel security through our standard, but then you can also secure the store and use the keys on the device as well. Now the secure elements are not necessary for for all sorts of application, but for the types that the adversaries have very high motivation to physically attack the devices, you can resort on using secure elements. Similarly on network side, the infrastructure like the joint server can be using the hardware security module which provides edit hardware level security in safeguarding the device credentials and device keys stored on the joint server side. And with all of that, we achieve communication, technology, security or the OR secure communication channel which comes out of box with the little one specification as part of the standard. As we have built it. To the standard from the very beginning. And obviously this is only one part of the puzzle. The other part of the puzzle of security is to have a secret implementation and deployment, and when it comes to the implementation, there is the device side and also there is the network infrastructure side and between the two. Typically the end device side requires more attention because most of the vendors and the network providers already know how to secure the infrastructure. It's an experience the whole industry is built. Coming out of Wi-Fi, 3G and 4G. Now on the device side, we have a very wide ecosystem, an an A lot of attention needs to go into the end device, platform security as well and this is. This is what we have in the second part of our web and R and this is where I stop and turn it over to Christoph to talk about the end device security and then like I said we'll have a Q&A at the end and we'll come back to any questions you might have regarding the part that I have just presented and with that. The floor is yours, Christophe. Thank you at birth with this recap of lower transport security. Welcome to this law has security webinar. I'm still disappointed project that could see a UTI chairman of Security working group at the islands. So we have focused mainly on prediction back in need protection too far. With the new legislation. Rising in Europe and in the US, more attention is needed on the device side. The security is a war, an event. If the link is fully secured, the system can still be attacked. If the device is not correctly secured. Of course today, actually immediate access to 1 device. What they mean by that is if that one device is compromised, it will not impact other devices. It will not compromise the network, but the device. The service that use the device or the service that this device feed can be impacted. This is a demonstration that secretly needs to be addressed at the wall. The service can be compromised by the device without the need to interfere with the link prediction. If the device is not fully secure. I would like to take the opportunity to speak a bit about this secretly working group to give a few words on the objective of the security working off. The main objective of the Security Working Group is to review the rawana structure and protocols will notify potential security issues that may have been considered in the injury die. A secret is a constant involving feared. The group will be responsible for proposing an evolution of the specification needed for these evolving secreted pigs. We need to discuss the security, architecture, evolution and the implication that this could have been the trend architecture. We need to consider the external publication so we don't if I any findings that require our attention to assess the seriousness of the situation and take remediation, action is needed. Not all conclusion will be bringing valuable information and submission form might be related to external factors such as device implementation that have nothing to do with this specification. We need to provide technical guidance to the Member and the device manufacturer to help them implement the security in the device. We need to promote the already existing technical recommendation as well. I would like to set up a requirement lists and frameworks that will provide a General Securities Corp. Security is not only the encrypted connection between the device and the backyard or observer, the security should cover the connection between the various system in the backyard and it covered the secrety in the device itself and the device provisioning process. How the kiosk generated it or for example. As I feel, explain the segment between the values components of their health system are secure an in the constantly evolving world and you approach like for example they would trust actually need to be explored, those they would trust approach is primarily focus on that island service protection. As security design is not one size fits all, we need to focus on the different type of devices and what security is needed for a different type of device. So I want to speak about the secret in life cycle so fast or secure upon arrival. So new I device should be ready for the use with no additional steps and no further configuration to be fully secured. Take your operation of manufacturer. The device should be for use according to a set of security practices and operations. This is to avoid any security breach. You can provide network security or lack of security process. The device manufacturer should comply with secretly stand up best practice. Fred mother reserves required the threat and risk around the product use case needs to be understood and the security requires to match the use case. Need to be assessed? The device should not leak data. It should be resistant together, privilege he compromised and take control of the process or the account. Monday Bridge preparations. So the device manufacturer should have the means to respond to cyber security incident. Both countermeasure should be proposed. An operational response and eventually that the devices are active. Life Time security upgrade devices along last time must have a remote software updates via a network download or a local software updates. There are removing medium to update new software on iOS device to add functionality and to fix. Issue or secure the device so the supply chain security integrity, the device manufacturer, miniature security standard and any piece of software or library used little device. The device software should be updated according to External Library. Secretive, never repeat released. This is a very idealistic and truthful approach to security, but we need to keep those principles in mind while implementing the new IoT device. So security is when aspect of the trespass yet and we understand that there is an overlap of security with other considerations such as privacy and safety liabilities resilient in many cases. In some cases cybersecurity is on the enabler of auditing such as privacy and safety. In other situation, the implementation of the Treaty can affect previous series or introduce safety risk. There is no one size fits all because the view of the risk of these five aspects would depend. On the risk profile associated with the use case, the environment, and the organization that is using the device. These high school principal guide our efforts earlier to start at the very high abstract level when we start to formulate a cybersecurity scope in the working group, there are five principal. Anything we do need to be based on understanding. This is because the device and the risk associated with that device is not only depends on the capability of the device or the behavior of the device, but also the development department of the device, the environment of the device, and integration that the device might have. Only use cases and therefore any approach we have to manage. The exist is rooted on in understanding and how I would she can affect that. The one size 1 feet tall. When we say IoT device when we initially started out looking at the aspect of reality, whether it be consumer or whether it be industrial, it is broad. An end compared to many types of IoT device that recognized that older is not going to be a one size fits all. As you might not, government have made several initiatives to issue Recommendation on requirement on cybersecurity. This recommendation or requirement on cybersecurity also cover IoT devices. NIST defines an IoT device cybersecurity capability core baseline, which is a set of device capability generated needed to support common cyber security controls that protect and organizations device as well as device data system and ecosystem. Many IoT device interact with the physical world in a way conventional ID device usually do not. We did a nice has released a set of documents that provided scope for the device that needs to be compliant. If that device is to be used by the US government agency, please provide publication and recommendation for the authorship to also. The open network and Information Security Agency and Open union agency dedicated to preventing and addressing network security an information security program is working on the Indian running. Walking will plan to fix the objectives of the working group. This work is expected to be completed by September 2021. The ATS Cybersecurity for Consumer Internet of Things would follow the standard. Florence is a member of a Qian will be participated in these new cybersecurity communication efforts. The specification should be in the scope of the Radio Equipment Directive and introduce data protection and privacy protection against fraud like financial and military and the combination of hardware and software. The applicability of is any Internet connected device, wearable device charge device except the Commission is aware that six which is new in the Radio Equipment Directive and will impact many member in implementation and conformity assessment, manufacture, testing, House market surveillance authorities, service provider. They have a different approach than the US. the US eyes issue a set of capability and Mr ability should be enforced for device directive reach with the US agency, but not for the figure. You know consumer, yes, but may be required later at the time to determine what in your they would like to be. This capabilities on which the Commission is working to be enforced there determine time probably isn't exciting here. It is clear that countries are moving toward or regulation toward IoT, or more generally connected devices. The goal is to secure the infrastructure and the consumer. Just a couple of days ago, the US White House issue an executive order asking government dependency to work on a complete framework for 11 fund that cover the information sharing about the threat. But isation of the federal government cybersecurity. So provide. The same work. With definition and get out of wedlock, I didn't expect for the device implementation. The goal is to protect all the key material and all the critical data and to protect the device the secret level is an ongoing work and the definition and the name of cylinder discussion at the Security working group. So I encourage device manufacturer to join these groups so we can define with the device manufacturer the secret level that definition and their feature. So today we're working on a basic. That prevents basic attacks, such as implementations may have serious limitation and should be used with caution. Any attack made on the device affected device only a good sound implementation that is adequate for IoT device comforted with schedule risk. This level would require at a trusted execution environment that she is an international specification. The API specification have been developed into which by global platform, the T is a citrus. State of the main processor in a device. It ensures that sensitive data and store process are protected in an easily trusted environment that she offers is rated safe execution authorize security software known as Trusted application. These trusted app enabled the provisioning of the antiquity by enforcing prophetic execution and rainment of authenticated code. Confidentiality, authenticity, privacy and system integrity. Compared to other security environment and the device that you also offer high processing speeds and a large amount of accessible memory. And then we have the last one we should best the best in class implementation that enable coverage of all comma new skills. Generally satisfied common criteria. This level will order trust, also known as a sexual amount. Common criteria. EAL 5 Plus the secure boot mechanism will ensure the device protection it will not be possible to inject or modify code to the dealer. And all geotagged test interface should be closed and locked. Will ask. Also the user satisfaction to library like FIT Certification which is mandatory for the US government agencies. It is worldwide recognize and development life security is not impacted. The certification of substitution will not be a formal process. There are certification scheme that already exist which are weaponized to name a few. We have armed TSA like platform, security, architecture, authorship, security evaluation, standard for IoT platform which is particularly interesting for its aim for IoT devices. It defines different security level, adapt. Why you keep it from you comma they should be fined 5 labeled from a self assessment bays. The developer has to provide a simplified security target describing the security claim. Of the produce together with the rational, why he believes these claims are made, only minimal evaluator effort is needed. Checks on constantly and clarity of the self assignments are performed to level 5 which require a comment Italia evaluation against an E L4 player that is used for smart guard securement epassport. Think the level provide high level of insurance. These are more certification standard available. The security working group will eventually provide a list of recommended come out based on satire such as specific use cases and application. So. There is. For reminder, security is. Keisha generated randomly and per device deliverance or sexually. So Dave Huatian complain too long as the situation in respect of the IEEE or UE they've address shall respect Lawrence is net ID network ID allocation, Johnny Way application. You will share directly with John Server with a legitimate IEEE Ivy. Used trusted Oswalt software, an overseas security for sensitive app, and you the best security level recommendation according the use case and ensure end to end world stack security system. This is really. The first level of secrecy that we will act also device make doctor enforce. This is basic recommendations that we've seen that some time wonders in serville completely followed. And as a conclusion. One secret is drones realizing preventive topography security the wall and is as strong as the weakest point in the chain. It's time to focus on the device. Device is an important element of the security chain to preferred device to the upcoming session. We would love to help our Member for the to help them to be prepared for that. The security at the newly station data protection and privacy protection, foot protection hardware and software protection. This or this area where? We can help and we will try to streamline the specification and provide the security that is expected in next couple of years in the world. Thank you for listening. So and now I will handle world to help further to moderate the Q&A session that we start right now. Alright thank you crystal. So now we can turn our attention to the questions we have been getting in the Q&A box. So let's see. Alright, starting with the first one from Jake question is. Is it possible to move? Is it possible to move from AS 128 two AS 256 within Laura van Communication so Kristoff? What do you think? So today out today the keys are AES 128. The protocol is defined at AES 128. So if we want to turn into AES 256, it won't be with the current spec. It will be like a later date. Maybe if there is some requirement for that, especially if there is a legislation requesting AES 256. But this is feasible, but it won't be backward compatible, so today. It's a yes 20 years and maybe tomorrow and as the legislation is moving on and then you standardization is coming, maybe we would have the need for yesterday 26. Right so info for the moment AES 128 is sufficient and moving forward like you say we have the ability to add that through specification revision and also when we talk about AES 128 this is the crypto we use at the at the link layer. Obviously at the application layer people are free to add an application layer security on top of the link layer and they have the freedom to use AES. Took the 6th or other cryptos which as well. Yes he did, and I'm so I would say I would add maybe some today for the 128 years when finish is very is is is good. It's strong. It's it's very strong. So one AES 256. I see that maybe for no counter cryptography or those questions raised when comes up clean up fee would be available but there as long as we don't want through a stir, anything's for more than 10 to 15 years. AES 128 is very strong, so it's sufficient. Right, OK, so the next question is from Phil. Field Day doesn't place have to be able to persist the frame counter across reboots, power cycle, etc. So as you had seen, we have two modes of activation over the air activation and activation by personalization. In case of OTA over the air activation, actually the frame counters can be reset appana successful activation procedure. As such, the device does not have to retain the frame counters across reboots. After rebooting, it has the option to run the joint procedure, run the activation again and after which it can start from frame counter 0. Having said that. If the device wants to optimize this operation and it can retain the frame counter, then. It would it could avoid having to run the activation again by preserving the security context across reboots. That is, that is definitely at its disposal. Now coming to the AVP devices where they do not run the over their activation, they shall not reset the frame counter to 0 even across reboots. They have to retain the frame counter in an envelope type memory nonvolatile memory. And keep using death after the reboot. Now we have mandated that in the latest linkedlist spec, version 1.0 DOT 4. Because in the past we have seen devices. Resetting frame counter back to zero after reboot without generating new session keys. And that opens up security risks so we have fully prevented that in our specifications. And the next one is, does OTA consumes more power than ABP? Overtime, let me take that one up as well. So the OTA has the additional joint procedure that involves sending a single joint request message on this thing at single joint accept, and then that initiates the joint procedure which can have a very extended lifetime like days, weeks, months or even year or years. Uh, so it wouldn't really consume much more energy than a VPN for its. Strengthen security. We highly recommend using OTA unless there is a reason not to. For example, if you are running a device that is uplink only, which is a very corner case, then you wouldn't be able to run the OTA and you would be stuck with a BP. Or you might have some other very special corner cases. That that requires you to live with a BP. Alright, the next one is. The next question from a Sandro Oralis does all the little one device in the market support AES 128 encryption? So, Christophe. Yes, absolutely. Security is mandatory. This is built in so there is no way that the device won't be able to support AES 128. So this is absolutely mandatory. Yeah, this is one of the strong things we have done, which is security is not an add on. It's been built into the specification from the very beginning, so there's no option to disable security with Laura well. Unless you are running your broken device, a device that is not using crypto security is not compliant with the standard and it won't be certified. It will be a broken device. Alright, the next one is from Simon Arnel. Are there any joint server implementations depth back? Do HSM's. So that I would say I would guess because that supports or that are integrated with the HSM's yes activities theme park activation which is it's which joint server it does support HSM. There's a integrated HSM with that. And to the best of my knowledge, that's the only one. That I am aware of. Alright. The next question is from field. A lot of device still seem to come with an Fey rather than. Join you, I might be at you. I can't be used to resolve the name of a joint server. Can you talk about the difference in that case? So. Historically, what used to be called at you, I got your name to join, EY? In the linked list specification. But in either case. It serves the same purpose, which is to identify the joint server. Now there exists an and the joint server and the Fey or the join you I as a globally unique identifier of join server. Needs to be generated out of an IEEE assigned or UI organizational unique ID an we do run into some devices that are using randomly set join you guys. And that's a problem, because when they when they're in a roaming situation. And when they send a join request with their random joining UI, the visited network. Cannot identify the matching join server to discover the home network of the device. As such, the joint request can never be forwarded to the home, and device can never join the network under roaming circumstance, so we highly, as you have seen in crystals presentation, we highly discourage people from assigning random AP wise random join you ice. Instead they should. Use identifiers. That are assigned to their joint server, which can only come out of an IEEE or UI Black. And that requires the vendor or the operator to get such a block from IEEE. That's the only way we can ensure global uniqueness an robust operation otherwise. Random numbers cannot can can just lead to random behavior. An unpredictable end result for an device, and in most cases your roaming device will never find home. **** *** anything you want to add. Hey, just to let you know that if the journey why is not set properly your device we have will not be able to gender the network, by the way because basically no join server will be able to answer the request. Yep. Alright, and the next question is again from Phil Day. Can you talk about insecurity differences between Laurel and one that screwed up X and one that one dot X? So let me take this question as well in Lorawan link layer 1.1 we have we have some security improvements. The most significant significant one is. Instead of using a single root K root key, which we call FT. Now we have two distinct root keys at key and network key so that root key separation gives us a full security around separation. Between the network layer and application layer and all the session key is generated out of the distinguished keys. They're they. They live in their own realms. And that helps with the management of the root keys and and the security domains or signature else. And along with the distinct root keys, we also fully separated the frame counter down. So we have one for the application layer and one for the for the link layer. And that's having having single frame counter down in the past create little complexity in the back end side. For synchronizing the downlinks. Generated by the application server versus the downlink changed by the network server using the same frame counter. Required them to stay in synchronization. Now that we have distinct frame counter down, they can manage their frame counter down independently without in a synchronization between the two. And then we have also enhanced our key hierarchy we have in our richer key hierarchy with with a purpose built session key. We now ensure no session and each session key is used only for one purpose, not for two purposes or more. And that's also a very good practice in cryptography. That provides a stronger cryptographic protection for for the use of those keys. And we also have a way to reset. Sorry to have a way to rekey. The little one session. Without resetting the data session. In 1.0 family, in order to rekey the device needs to go through the joint procedure again, which resets the data session, including the RF parameters. Now we have the ability to regenerate session keys without disrupting any non security related context. On the device and the network. And we have also adopted a counter based join nuns. So instead of relying on a randomly generated join months, which which gets harder to keep track on, the on device, now the join nuns in 1.1. Spec is a counter. And it's easier for the end device to keep track. So we have. I mean, this is the list of security improvements in the lot of 1 link layer 1.1 spec, and right now we're working on a revision of that spec called one that one that one. Which we are intending to publish by the end of the year. And along with that, just like we have done with 1.0 dot four, we will not only publish the link their specification, but also we will publish the certification program and the reference implementation and the LCT testing tool, all as a single package. So we would highly recommend waiting for that before moving to Linklater 1.1 specification. OK. Alright, so the next question is, is Porter available today? Uhm? Yeah, let me take this one up as well. And yes, photo feature. Has been already published. Maybe like a year and a half ago at least. Look up version 1 firmware update over the air and it's been made available. Well, not only the specification hasn't available, but. At this three or four vendors have implemented that and made it available. And meanwhile we're working on version two or footer, which comes with some refinements. OK, the next one is also related to footer. Uh. Little one spec doesn't define photo mechanism. Can you clarify? Mainly for recovery photo sales? OK, so the lower one. Sup. Yes, for the for the recovery if they fail, so I want to say that it's a. It's really depending on the design of the device because that we specify the foot as specification. How to carry the information etc. But there is no classes for this up to the device to recover from a Fed filter, so it's done with the bank and basically you downloading and bring the Fulton Bank one for example and you still have the old firmware bank too. So if you have any issue. Booting the device, you fall back on the previous bank, so this is kind of mechanism are absurd. Department of the device. Right, alright? And then the next question is what is the difference in terms of security between 5G and Laura M? So what do you? What do you think Crystal? So yeah, to make a short answer. So without deep diving into the cryptography, which is a bit different because 5G network or like your mood in general like LTE network are using some pretty private cryptography. The main difference is really the use of a secured amount, which is the common criteria. In five plus certified. So that's the major difference. You know I want today we don't have such a requirement and this is what I explained during the presentation that we are working on the security level definition for the device and I would like to introduce like multiple level and the best levels of the top level. I would like that top level use the same equivalent security mounts, common criteria or five please. So in that perspective that brings. You have one security on the cryptography said, almost the same level of what you can find on the 5G or LTE network. Alright. A question from Robert Sample in an uplink only scenario with using the. And notes why would we be stuck using ABP security features as opposed to OTA security? Well, the reason is for OTA the end devices run a joint procedure that involves the end device to send a join request and wait for a join except. If the if the device is uplink only, then the device cannot receive join except. To complete the handshake. That's why it would be stuck with ABP. But obviously we do not recommend even using public only devices because. ADR, the adaptive data rate procedure requires BI BI directional communication in order to optimize the use of radiofrequency resources. So an uplink owned device would not only be stuck with ABP, but it will also be not able to use adaptive data rate. So it will have a very suboptimal use of the RF resources. But yeah, basically join except needs to be received by the end device in order to complete the activation. Only after then Ortie device would be able to successfully communicate. Uhm? OK, Keith Hill is asking what's the relationship between the device you eyes? And I triple E registered othewise. I can jump on that one, so in our linked list specification, we provide guidance on how dare you, I the device ID is generated on how the joint E UI the joints are right. The ideas are generated and for both of them. The prefix of those 64 bit identifiers. Need to come out of needs to be based on IEEE registered othewise. So if I were to give you a daily why or or join you, I, you or anyone should be able to identify. The. The vendor could put its own all UI embedded in that. In that identify? Well, that's not really the objective, but the objective is to ensure global uniqueness. The only way to ensure global uniqueness is to use globally unique prefix. And that can only happen if the prefix, which is the beginning part of the ID, comes from an assignment authority that assigns each a given prefix to a single company. That's what IEEE does, right? So we simply rely on IEEE assignment for global uniqueness. Today the same kind of identifiers are used for, for example Ethernet Mac addresses. To prevent an Ethernet interface coming from vendor a, another one coming from vendors be enough to have the same Internet Mac address. The same technique is used, they both rely. It's in. That method relies on IEEE all UI, so we just adopted the same thing instead of reinventing the wheel or starting a new registry, we just rely on the well established, well working IEEE or UI. Assignment registry. So OK, there's a photo question. Let me jump to that little one. Payload is around 50 bytes. Means photo will need many. Chunks and fragmentation mechanism and turn. And that that will make for the complicated. What do you recommend? OK, well, I mean. So that's that's the correct observation. Well, the little 1 frames are not always 50 bytes. Sometimes they're even less. For example, in United States and in the US region RF region in the harshest RF conditions, the payload might be as small as 11 bytes. An in the most favorable or if conditions. Anywhere around the world. And the payload size can increase up to 250 bytes. But but nevertheless it's small and that's why we need to have fragmentation. And then so we have this fragmentation support. OK, so we have this fragmentation. Anne support protocol that that is built well that that is has its own specification and I wouldn't say it's a complicated since then additional piece of protocol that you rely on. And I mean it's it's the same thing with even IP. The Internet Protocol you need to have fragmentation. When you're guaranteed at this sorry, go ahead, go ahead. Yeah, I was gonna say do you want to add anything crystal? Yes, because you're so so like there is fragmentation and the protocol will range the packets in the right order for you. And also one night things. I think we should emphasis and this is not always available and maybe not a lot of network is multicast. So basically yes you have a small payload, but you can upgrade more than one device at the same time. So basically you can basically agreed a set of devices that need to be agreed on the same time. So you don't have to basically take bandwidth to upgrade 1 device and then the other one and so on like in the case on LTE. You can just send for a group of device that you want to upgrade and you can send once over the air and your grade multiple devices at once. So that was kind of efficiency. This is not available on the on the lot of network. Bra alright man, let me work this. So. OK, so Muhammad is asking joint key is not specified in little one spec one or three isn't being that you don't recommend device with the specification. I believe you're referring to join in UI, but as I was saying join EY&FY, they're the same identifier. We just renamed the identifier in the specification. We just renamed the identifier in the specification for it to be more representative. But otherwise in terms of that identifier, was this caitians are equally secure, but for for various other improvements we had in wander through the four. Obviously we highly recommend using the latest link, their specification, which is 104. Uh. OK, and the fill is asking. Thanks for the answer so far. Thank you for the good questions. Just to be clear, is the APU I renamed to join you. I only in. Lot 1110 do this that happened at some increment. Of the 10 X yeah, actually we have done this renaming in one that showed up 4. So in 104 you will see join EY? Being used instead of APY. Well, with that we have reached the end. While timing is near perfect. Alright, are there any other questions before we? Close this session. I'm seeing no questions and we're right on time. So well, thank you for joining this webinar. Ann especially. Thank you for all the great questions. We hope you enjoyed it and you found it informative. And we welcome you to our future destination littleone weapons as well. And with that, and thank you, Crystal, do you have any final closing remarks? No thank you, Lord and thank you, helper. Had very good session. Come too soon. Alright, talk to you soon. Everyone have a good day. Bye bye. Bye bye. _1624312008347

LoRaWAN® security has previously been discussed from the network point of view, but in this webcast, panelists will open up the conversation to look at security as a whole and focus on the device aspects as well.

Security is an essential aspect of the LoRaWAN specification, and it relies on the implementation process as well as embracing best practices and industry standards. The LoRa Alliance® ensures its interoperability specifications are secure while recognizing the overall security of the solution also depends on the implementation and deployment security. On the other hand, implementation security issues need to be taken up by the relevant manufacturers and deployment issues need to be taken up with the relevant network operator(s).

With the introduction of new regulations like NIST in the US, or the European Commission yet to come to a directive about security, the device now has the spotlight and will require more careful attention on how security will be implemented.

Join Christophe Buffard, LoRa Alliance Chair of the Security Working Group, and Alper Yegin, LoRa Alliance Vice-Chair of the BoD and Chair of Technical Committee, for a presentation and discussion on LoRaWAN security – from the network, to the link layer, to the device.