 Okay, thank you all for coming here today. Our presentation is titled Secure Software Update for embedded devices with SW update and TARF. So before we dive into the detail, let's even introduce myself. My name is Koshiro, and I have been working as a software engineer at Toolshipper Corporation since last year. And I'm mainly involved in research and development of software update, that's all. So look at the agenda for today. So first is exploring about methods for embedded devices with SW update. So next, I will dive into attackers and attacks. So to understanding the security challenges, and next, Osloy. Our third is when we discuss SW update security and exploring countermeasures against well known attacks and vulnerabilities. And next year, I'll introduce the update framework TARF, and how TARF enhance the existence update process so with using SW update. And I'm giving you an example of how these concepts are executed. Finally, we discuss the challenges that we face, and what the future might hold. Yes, let's start. First is there are update methods for embedded systems. So why update system, embedded devices need a plate? So as well known, the system of embedded devices being more complex, at the same time, cyber security is increasing now. So there are growing need to fix bugs and fix the security issues. As well as today's keynote session, any bugs become a more of a security issue, yeah. So, and additionally, there are high demands for adding new features. So after these devices are released. And from this perspective, updating embedded devices is crucial. So however, so the devices are like embedded devices located in extensive or inaccessible areas. So we need to use over the air update, remote update extension. And next, the side is, I'll describe about overview of simple OTA update process. So the OTA update process can summarize into four main actions. So first is detecting. So the device check to see if it needed an update. So this is, oh, yeah, this. And the second is downloading. So if they are an update, the device downloading their update image. The third is install, yeah. It's simple, so device installs a downloaded image. All the process of updating such as an apt, like a pipe here, like something like that, a library, but embedded devices require additional step to the status or to the target. Yeah, these are four as we need to implement it. So first step is notify. So yeah, this device shares data with the server. There are multiple tools for OTA updates, so we've chosen SW update. So next I'll describe about what is SW update. So SW update is highly suited for embedded devices. If it's a fancy design for limited device resources like a lamp or a flash, and offer flexibility and compatibility adapting to various situations. And moreover, there are a lot of practical implementations, applications, so we can check the website using SW update. And next is, it's a 100% open source, so I can develop it actively. So we've chosen SW update. And next, so as I mentioned earlier, it is easy to imagine that this update process with SW update could be attacked. So first is an example. So with many embedded devices, contact to the network for convenience or OTA update. So cyber attack is increasing now. So this can impact public service or infrastructure services. It is not just a Celtic risk. Some infrastructure have already experienced these attacks. So let's explore the well known attacks starting with their attacker's motivation and goal. So this slide is attacker goals and multiple methods. So we can categorize their goal into three main types. First is their deny installation of updates. So the aim here is to prevent system updated to exploit existing vulnerabilities. And second is impair the function of the device. So here, the goal is to interfere always normal operation and render the system unusable. For the studies, this is the worst case scenario. So hijacking the device. So the attacker aim to take control to execution and execute all sorts of activities. Yes, there are three goals. And there are four main attack methods that can be used to achieve these three goals. And we will briefly explain them. Yes, so let's quickly go over the key player involved. So first, we have device. So this is the device and this is the server. So first, we have this device connect to the server. So this connection is very crucial for detecting upload image, update image and downloading update and notifying status to the server. And this is a package, a distribution package. And this package is signed with a signing keys. And this device, the verification of this signature. Yeah, and if valid, the device is installed this image. So we assume that an attacker is able to modify this communication. And it's also be assumed that the key, this key, the signing key can be stolen. So now let's look at some actual running attacks. So first is deny solution about updates. So there are two types of attacks here. So first is drop release attack. So block network traffic, both inbound and unbound. Preventing the device from detecting the existence of update or even the presence of attacker. And next is the freeze attacks. So it's like a similar drop release attack by continuously receiving all the images or added images the device are able to locate the new file version. So there are methods effectively abstract the update process. Now, next is the interfere with device functionality. There are three types of attacks here. So first is this involves a first forward attack and rollback attack, which manipulates the version number and to interfere with the device functionality. If of 30 increasing a version number, the device might see all version as outdated after installation. And conversely installing all the version can exploit past vulnerabilities. And next is the ender attacks. So during the update image downloading, the attacker send infinity storing of data to the server device. So this consume a significant space and disk space and it can lead to several issues for the client system, a device system. So aiming to cause a functional breakdown. So there are three types of attacks for us to partially or completely destroy the functionality of the device. Oh, this is the worst case, our controller device. So the avatar to ensure attacks involves installing the file without verification or when completely control over the device. Next is the exploit key. So this involves the misuse of key to create them install any sending file on the device. Again, allowing complete control over the device. We will continue our discussion as shown that attacks use these seven methods to target embedded device. So SW update implemented signing and verification to counter these seven attacks. So for signing and verification use SW description. So first I'll talk about what is SW description. So SW description indicates a content of the update image like this figure. So this SW description lists image file and files. So it organized essential elements within of the image such as file name, version information and hash value, I'd like that, yeah. Now this is an example of the real actual SW description. Here, and this 2.0.0 is a version. And there it is. Upper side is images, root file system and below is image file. And it also indicate hash value. Oh, don't worry, yeah. Also indicate find value and this information value by configuration. Okay, so please wait, yeah. So by signing this SW description, we make a certification. So this means that update image will contain a SW description, yeah, a SW description or this thing. And image file elements, essential elements like image file, files, like root file system and certification, yeah. So SW description ensure update into agility in SW update via digital signature authentication. SW update has RSA and CMF. Now this ensures the version, information as a critical data cannot be tempered with. So protect this data. So, and finally, yeah. F2D prevent attacks such as a rollback or forward attacks. In addition, a SW update has already been improved to reduce risk such as rollback attacks and understate attacks which interfere with device functionality. So version related items are compromised is made between the value of the SW description and the version already indicated the configuration file. This is an example of configuration. Or this, here is a version, a no downloading and no reinstalling. Version can be set for the desk, yeah. Then SW update use this configuration. First slide, so let's look at the table. Summarize how well SW update can defend against seven previous attacks. So A line A represent no countermeasure. And while B represent using SW description. So naturally without any defense or attack success, yeah. However, even the use of signatures of request attack, yeah, here. And the freeze attack and the vulnerability of two key compromise can still be successful. So SW description, so this right there update, the future and component key risks. So SW description alone cannot full address job request attack and freeze attacks. For instance, even if this threat exists, there is a possibility it might go unnoticed. Certainly it is possible to detect, for example, different version when installing. However, forcing error message for update failure could lead to excessive response in the non threat scenarios, yeah. Even notification due to update failure could be abused. And additionally, if the signing key is compromised, it is not feasible to replace it. It's essential to recognize the key can be compromised and run accordingly. And in response to these attack, we consider combining SW update specification known as the update framework TAF. So TAF provide a security framework for software update systems. It's mainly covers the detect and download step in the update process. So the key goal of TAF here enhance, enhance the security for existing and new system and adapt to various system needs. And I think this is important thing that mitigates risk from key compromise. So we choose TAF for its ability to handle key compromise and its adaptability to existing systems. So this is right, the security is in principle. So let's look at actual principle of TAF. First is trust. So trust downloading file really mean achieve that file were provided by a party without malicious design. Second is freshness. So by setting an expiration date and the need to stay update, a client should be able to recognize the update may exist, that they haven't been able to obtain. And sorrow is mitigating key risk. So a secure software update system must not nearly achieve that, provided key is always safe from compromise. So TAF is designed based on the three principle to achieve this. Yeah, the TAF use metadata and role. And this slide shows the metadata and role in TAF. So TAF has a four main role. Yeah, main role, so root and timestamp, a snapshot and a target. Yeah, target. So first let's talk about metadata. So the metadata hold different information for each roles. So and these roles have different levels of importance. So the timestamp metadata, yeah, timestamp metadata list the hash and size of snapshot metadata here. And snapshot metadata list the hash and size of target metadata. So this here is actual image device wanted to download. In this presentation, this is the update image. So target metadata list the hash and the size of this update images. So they are guaranteed as shown with dot lines, yeah. And by linking like this, like a chain spoofing is prevented. And root metadata is so very, very important. And that's very important. So root metadata has all keys information. So a root guarantee, sorry, a root guarantee all keys held in by the law indicated by red line, yeah. Okay, next let's talk about the signing key. So they are used to sign the metadata indicated by blue line. Blue arrows, yeah. This prevents a tampering with metadata. For instance by ability root, you can ensure that the correct key are being used. Yes, and the keys present here are all key used in tough. So since the device doesn't need to manage the key, so device don't need to manage the key, so the key can be exchanged only on this server side, this metadata server side. So the three metadata managed automatically and it can function in a network environment. Yeah, and therefore metadata must be continuously updated. We need, here is a part of the root metadata. So, you know, this side is information. So include the version, this root file metadata version is number one. And it also lists the key information for each row. Here is the key information. And the details are signed using keys and display this section, this is our signature. Yeah, so this is our metadata. So now let's begin at how to combine tough with SW update. So we use Python tough, so the reference implementation of tough for easy metadata signing and management. So we use fast API for making the metadata server. And this server only delivers the metadata and management of the metadata. And nothing else. So in addition, the client has to have a script for refreshing metadata and downloading and botficking images. So here's the overall structures. First is the server. Here, here is the metadata server, mentioned earlier, here is the metadata server. And we need to, the metadata server does not manage update image. So we need to prepare file server to manage update images. And we use the WFX for sharing the update status with the device. So this is our status sharing server, WFX. And this is a GUI server for managing these three servers using each API. Now next are on the device side. Now there is the update. It do basically job confirmation and the status sharing with WFX. And metadata handling file download handled by small script client by, this is using a Python tough, yeah. And this script are used from SW update as a command. Our next is, I need to describe about what is WFX. Yeah, WFX is a lightweight, generated purpose workflow executor. So workflow models are the fine state machine executed as a job. A real WFX and client collaboration. So synchronize the status through polling and the status share for job on WFX. A workflow called device artifact update has been implemented. This allows to update the status of SW update to be synchronized with the status of the job. Now I use this WFX for sharing the status. So next is UI and file server. So you are developed using next years for simplicity and efficiency. File server created with first API focusing on easy overuse. So please note that this is a simple run created for demonstration on purpose. And let's briefly review the update for the combination. The first is polling. So there are two polling process. First is a polling process to update metadata. This we call a refreshing. And the latest version is always available. And next is for detecting job. This, there are the two polling process. Next is a flow of detecting that there is an update and downloading it. So here is a detecting job through WFX and based on this, check the metadata again. And if this version, the download image about it, butifies the download image, then install and execute it. So this flow is the install and the state share. So when the SW update is sharing, installing, it sends the status to the WFX server. Thus each the service or application will perform a combination update. Yeah, now let's move on to the actual operation. So this is our experimental environment. So use bison.3.1.0 and prefer host. And we prepare host, the host and a device. So host is this spec here. And we use QM to emulate the device. And the device run on a Debian-based OS using CIP kernel and the CIP core. And let's proceed with actual operation demonstration. This left side, left side is QM, so like a device. And the right side is applications, top page. And then device is managed and meant with AV partition. With AV partition, here is partition A and here is the partition B. So currently it's partition A and revision two. So we will install to the partition B and we aim to the revision two are three. And this device pulling to the WFX server in five second. Yes, now I'm using this application. Now this right side is our management devices. And we choose this, okay, we choose a QM. And this place, also if you pick the QM, this place your management platform. So firstly, we need to upload the image. So clicking upload and choose the second one and upload. And enter the version number, okay, upload, okay. Who, who, okay, sorry, again, upload server, upload file. And then the version and upload. So this is applet. So next I need to installing, so downloading and installing. So before this install download, we need to create a job. So we make a job clicking and make a job. So now status is, now status is created. So the device is no, doesn't have a response. So next time we need to download the image to the device. So we click the left side of the devices. And at the same time devices download images. Our next step is installing. So this I click to install. Suddenly start, yeah. This is running the installing. And the device has stopped working and rebooting now. So device rebooting now. I enter the login and it shows the partition information. Yeah, this is a new partition and don't work. Okay, here is a B partition. A partition B is an activity, it was success. And the vision is updated to number three. So this is the applet process. This demonstration shows that the applet for just described can be easily implemented on existing systems. So let's examine how security is specified and how. So first against double request attack and freeze it attacks. Suppose the update of timestamps is hindered. So the device can't update the timestamps. So with timestamps, explanation is leached. A device to attempt to upload, update timestamp. But if it can't be updated, we can detect the presence of attackers. A similar explanation applies to other roles and version files are linked in like a chain. So allow for detecting of attackers. This key point is there are continuous metadata checks help clients that detect attackers. And yeah, timestamp is accessed frequently. So it is explanation is set to about one day. Yeah. Some, so complete forging is in practical without all keys. If they are going to attack, they need to talk all keys. The attackers need all keys. And now let's see what's happened if key A is compromised. So let's talk about root key, the rotation. So here is an example. The device, no, sorry. As a metadata server has a root key A and key B. So if key A is stolen, if key B is stored securely, key rotation is very, very easy. So the compliance key is removed from the metadata like this. Remove from metadata and add new key C is adding. Then metadata is signed with all three key include key A, yeah, and update it. As a client doesn't know management key. So with these simple steps, key rotation is possible. And for example, in the case of root, rotation is possible as long as a special number of key is not compromised. So in this case, a special load is two. So this measure can be easily taken in case of big. So consider this, let's update our tables. She represents our new result of combining SWR plate with tough. As shown, we've achieved resistance against the potential attacks. Yeah, finally, I talk about challenges and features. So however, there are still challenges in implementing these update process. Let me mention two things one, two significant ones. So first, there are remaining mined material attack risk. So the presence of update can be detected. Some bars seem to interfere with status sharing. So if an update files fails and the failure message is altered by an attack, it's undetectable. And this necessary, so this necessary is the implementation of robust device authentication. And second, there is a risk of intercepted update vulnerabilities. There is a risk that the update images can be reverse engineered and must be encrypted with a common key. This is also implemented in the standard SWR update functionality, but the problem is that this key cannot cope in the event of compromise. So optimize SWR plate and pricing tough WFX or hotend team technology. If client implementation are to be used, there need to be well-coordinated and strong next. This include consideration of these use of OSS like notary. So protecting a common key for encryption and device notification also requires an idea of how to manage key securely on the device or the private key for encryption. And this is a summary slide. So yeah, the update process and no attack were organized. A combined with tough, it could demonstrate resist to drop a request attack and freeze attack. It was also able to show that it is easy to replace key and can resist a key compromise. Our demonstration show how it works in combination with the SWR update and tough. Other challenges, mine the middle attack, this end and clip to image need to be considered. Finally, continue improve should be made based on current issue and the other tech sources. And finally, so today's demonstration show this CIP booth. If you want to more details, please come here and I explain about that. And other technology about include CIP please come here. Thank you. So this is just an FYI. There is an version of tough that's actually specifically for IOT called Uptane that's used in automotive and AGL that does do image encryption and also does the, has better kind of man in the middle protection for that situation you're worried about where you send sign manifests back to the repository. So I know the Uptane and I did our specification of Uptane. So I, maybe I need to go to Uptane but our current has a lot of CPU, so main CPU and partial CPU. But the devices don't have a lot of CPU, only one CPU. So yes, Uptane is very, very good but we need to adjust to the embedded devices, yeah. Okay, I'll chat with you about that later. Thank you. Any questions? Any harm? No? Okay, thank you.