- iot-wg - mailman.ripe.net

Events of interest : IoT / Security
by Vesna Manojlovic 07 Aug '23

07 Aug '23

Dear colleagues, as part of cross-community connections, I am sharing these upcoming events with you: as an invitation to attend, and to promote/represent RIPE Community if you go there -- and to invite those participants back to RIPE community! Regards, Vesna === Chaos Communication Camp 15.-19.08.2023, Ziegeleipark Mildenberg, Zehdenick, Germany https://events.ccc.de/camp/2023/infos/ === BalCCon2k23 - Balkan Computer Congress 08-10 September in Novi Sad, Serbia https://2k23.balccon.org/ === The Things Conference 21-22 September 2023, Amsterdam https://www.thethingsconference.com "event about LoRaWAN® and Low Power Internet of Things. Join 1500+ top IoT professionals, 70+ leading industry players, learn from 90+ curated keynotes and 20+ workshops, learn about the latest developments in the LPWAN market and become a LoRaWAN expert. " === The 9th IEEE World Forum on Internet of Things 12-27 OCTOBER 2023, Aveiro, Portugal THE BLUE PLANET: A MARRIAGE OF SEA AND SPACE https://www.ngi.eu/event/the-9th-ieee-world-forum-on-the-internet-of-things… === For more events, follow: - https://www.ripe.net/participate/meetings/calendar) - https://nsrc.net/calendar - https://pch.net/calendar - https://foss.events/ -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

2 1

Summary on our last Session at RIPE 86 in Rotterdam
by peter.wehrle＠t-online.de 01 Jun '23

01 Jun '23

Hello, as you see in the steno <https://ripe86.ripe.net/archives/steno/43/> we had a quite intensive discussion on the focus of the IoT workgroup at RIPE 86 <https://ripe86.ripe.net/programme/meeting-plan/iot-wg/> to stay broad but also be specific in applications of IoT. As the new co-chair along with Peter Steinhäuser I first like to send a big thank you to all participants of the IoT working group at RIPE-86 joining personally in Rotterdam or online. The IoT Working Group Meeting at RIPE 86 in Rotterdam on 24th May was the last meeting for Sandoche Balkrichenan as chair of the IoT Group. Sandoche relocated back to India and did not apply to renew the term as chair. We are grateful for all the good work and support Sandoche gave as chair to IoT Working Group. As Peter Steinhäusers current term as chair is ongoing until RIPE 88, a new candidate for the Co-Chair was required. I, Peter Wehrle saw the opportunity to support the great idea of working groups and to give something back to the very open culture of the RIPE community. Im 56 years old and have a degree in communication engineering topped up by an MBA. I live and work in Germany, Frankfurt area and works as department leader for a smaller Telecommunication- and Cloud-provider, running the Business Support Applications from CRM to billing, Processes digitization, Project management, Data Security and ISO certifications for data centre operations. IOT kicks in with my hobby as radio amateur and the passion, to melt together old ham amateurs and the current maker scene with all kinds of projects, where IoT is the core for applications around all kind of solutions to optimize energy and resource consumption, meter environmental conditions like weather or humidity on fields to achieve data driven insights. I found a great appreciation from the IoT Working group on this view towards applications of IoT especially in some personal talks after the session. In turn Im looking forward being better connected to all the professionals in the IoT Working group, who does work in this field and can provide expertise and insights on the latest technology and solutions around IoT. The intention is to foster the discussion between the technical possibilities and the application of IoT - driving the groups take on necessary guidelines for i.e. IoT device security, addressing of devices etc. and to sharpen the mission of the RIPE IoT Working group in connection to other RIPE working groups like IPv6, Open source and so on. Feel free to share any thoughts on it to intensify the activity of the IoT Working group also between RIPE meetings. We are looking forward to this enhanced exchange. Peter & Peter

1 0

[Peter Wehrle] for co-chair
by peter.wehrle＠t-online.de 23 May '23

23 May '23

Hi, I promised Peter Steinhäuser, that if there is no volunteer yet Im brave enough to step up and apply for the co-chair for this IOT Workgroup. Im a complete newcomer this RIPE is my first RIPE and I joined this work group mailing list this afternoon. Im 56 years old and have degree in communication engineering driving my passion for electronics and radio communication. On top I did an MBA which helped to settle with English apart from my mother language German. I live and work in Germany, Frankfurt area and while Im more IT Application driven in my professional live (I work as a department leader for a small Telecommunication provider running the Business Support Applications from CRM to billing, Processes, Project management, Data Security and ISO certifications), the IOT kicks in with my hobby amateur radio and the passion, to melt together old ham amateurs and the current maker scene. We do run in our area a network on Lora just switched to chirp stack various projects going on which are about to combine (partly self-developed) very low energy consuming sensors and radio links to build up various data driven smart solutions. Im the president of an amateur radio club, running a yearly exhibition where we more and more go into the mission of IOT sensors and radio interfaces as a base of many clever solutions. Hence, I do not have a professional background on IOT (yet), however Im connected to various groups who just drive initiatives on measuring humidity on fields to optimise the water consumption for growing plants, monitor bees health, urban weather project and so on. So, if you dont mind getting somebody on board being passioned about the subject IOT, settled with the electronics, the radio link and being nosy about all the project you can do with it but not being linked into a professional provider Im happy to jump in. If you dont find, that is a good solution, please be honest and speak up. Its an idea and I find IOT too important to just let it down without any volunteer. Maybe that encourages others to apply as well? We will see us tomorrow in the workgroup session. Best Regards Peter Wehrle (contact data and a picture is in the participant list)

2 1

[Reminder] Call for volunteers or nominations for RIPE IoT Working Group co-chair
by Peter Steinhäuser 15 May '23

15 May '23

Dear Colleagues, As Sandoche's term as IoT WG co-chair is about to end with RIPE 86, this is a call for nominations or volunteers to co-chair the RIPE IoT working group. *********************************************************************** Please DO NOT reply to this message if you wish to propose a volunteer. *********************************************************************** I would ask for each candidate to start a new thread with, e.g., "[name] for co-chair", and for members to utter their support by replying to the respective thread. Provided there are no reasoned objections from the WG, I'd like to set May 22nd as a deadline for showing support on the mailing list, so that we can announce the decision on 24th May during the IoT WG sesssion at RIPE 86. More information about WG co-chair responsibilities (https://www.ripe.net/publications/docs/ripe-692). If you'd like further information, don't hesitate to contact Sandoche or me. Thanks for your support, Peter — Peter Steinhaeuser RIPE IoT WG Co-Chair

1 0

RIPE-86 IoT Working Group call for Presentations
by Peter Steinhäuser 07 Apr '23

07 Apr '23

Dear Colleagues, RIPE-86 is being held in Rotterdam, and the IoT working group will have a slot there as well. This e-mail is our official call for topics at the RIPE IoT working group session at the upcoming meeting. Our working group session is currently scheduled for Wednesday, May 24th 2023) at 10:30 CEST (08:30 UTC). Please send your presentation proposals and discussion topics to iot-wg-chairs(a)ripe.net. Please also indicate how much time you would need for your presentation. As usual, both in-person and remote participation in the working group is possible. Thank you, Peter — Peter Steinhaeuser RIPE IoT WG Co-Chair

2 1

Call for volunteers or nominations for RIPE IoT Working Group co-chair
by Peter Steinhäuser 03 Apr '23

03 Apr '23

Dear Colleagues As Sandoche's term as IoT WG co-chair is about to end with RIPE 86, this is a call for nominations or volunteers to co-chair the RIPE IoT working group. *********************************************************************** Please DO NOT reply to this message if you wish to propose a volunteer. *********************************************************************** I would ask for each candidate to start a new thread with, e.g., "[name] for co-chair", and for members to utter their support by replying to the respective thread. Provided there are no reasoned objections from the WG, I'd like to set May 22nd as a deadline for showing support on the mailing list, so that we can announce the decision on 24th May during the IoT WG sesssion at RIPE 86. More information about WG co-chair responsibilities (https://www.ripe.net/publications/docs/ripe-692). If you'd like further information, don't hesitate to contact Sandoche or me. Thanks for your support, Peter — Peter Steinhaeuser RIPE IoT WG Co-Chair

2 1

[BCOP] Adressing Thread & Matter for IoT
by Peter Steinhäuser 03 Apr '23

03 Apr '23

Dear collegues, since the IoT WG released it's first BCOP document [1] some time has passed. Several technologies discussed in the document – i.e. DPP, USP – have become mandatory for large carriers and can be found the majority of their roadmaps. The considerations regarding secure onboarding can also be found in works of other researchers and became common ground – I think this document was a good and useful first step, but technologies are evolving and new options and requirements surface. Recent talks with carriers revealed that all intend to increase their efforts in managing IoT devices in their customer's homes or start such efforts. All of them refer to Thread [2] and Matter [3] as the technologies of choice – which makes sense given that at these standards increase compatibility and are backed up by large players like Google, Amazon & Apple. Since Thread is based upon IPv6 it offers new options and possibilities to integrate with existing network infrastructure an standards. Nevetheless it also requires re-evaluation of threats and attack vectors in such networks. I would like to initiate work on a follow-up BCOP document that centers around the changes Thread and Matter do introduce to networks, but that also takes into account our findings that got incorporated into the fist BCOP document this WG has released. Especially the challenges regarding onboarding and security in general remain the same and would be needed to be evaluated in regards to the new technologies. An IPv6 based IoT networking protocol offers also new possibilities for integrating IoT devices into networks and can change the way we look at such networks. This should also be part of such a document. I would like to ask the members of this WG about their opinion about these considerations. And I also want to ask for volunteers to work an such a new BCOP document and would be glad to initiate and manage the process. Sincerely, Peter [1] https://www.ripe.net/publications/docs/ripe-759 [2] https://openthread.io/guides/thread-primer [3] https://csa-iot.org/all-solutions/matter/ Peter Steinhäuser, CEO embeDD GmbH · Alter Postplatz 2 · 6370 Stans · Switzerland Phone: +41 (41) 784 95 85 · Fax: +41 (41) 784 95 64

2 2

work on revised IoT BCOP
by Michael Richardson 24 Mar '23

24 Mar '23

In a thread that I lost, Peter asked: > since the IoT WG released it's first BCOP document [1] some time has > passed. Several technologies discussed in the document – i.e. DPP, USP – > have become mandatory for large carriers and can be found the majority of > their roadmaps. That's really news to me. I guess maybe this is about USP more than it is about DPP. I'm unware that DPP has become mandatory. As for the USP (TR-369), I'd like to know more: it's quite a fungible spec, and what part exactly has become mandatory, and what transports? In our BCOP, we said we needed a standard phone/browser <-> home gateway API such that we could have innovation at the edge. (Right now, it's a market vertical with a new app for every home gateway) So I'd love to have some discussion, maybe there are even presentations, about where we are here. > Recent talks with carriers revealed that all intend to increase their > efforts in managing IoT devices in their customer's homes or start such > efforts. All of them refer to Thread [2] and Matter [3] as the technologies > of choice – which makes sense given that at these standards increase > compatibility and are backed up by large players like Google, Amazon & > Apple. Since Thread is based upon IPv6 it offers new options and > possibilities to integrate with existing network infrastructure an > standards. Nevetheless it also requires re-evaluation of threats and attack > vectors in such networks. yes, but I think that the carriers are gonna find that they have some serious privacy implications if they get involved. I think that it is gonna bite Google and Apple and Amazon too. > I would like to initiate work on a follow-up BCOP document that centers > around the changes Thread and Matter do introduce to networks, but that > also takes into account our findings that got incorporated into the fist > BCOP document this WG has released. Especially the challenges regarding > onboarding and security in general remain the same and would be needed to > be evaluated in regards to the new technologies. One thing that might be useful is to have a Thread and Matter (they are different and also dependant) reference networks that we could play with in person at a future RIPE meeting. Probably too soon for Rotterdam, but maybe in the fall. (Wherever that will be) > An IPv6 based IoT networking protocol offers also new possibilities for > integrating IoT devices into networks and can change the way we look at > such networks. This should also be part of such a document. > I would like to ask the members of this WG about their opinion about these > considerations. And I also want to ask for volunteers to work an such a new > BCOP document and would be glad to initiate and manage the process. In general, I think that it's too soon to say anything useful in a new document in 2023, but that we should be spending some time understanding what's going on. -- Michael Richardson <mcr+IETF(a)sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

2 1

RIPE 85 minutes
by sandoche Balakrichenan 29 Nov '22

29 Nov '22

Hello all, Please find the minutes from our last meeting @Belgrade: https://www.ripe.net/participate/ripe/wg/active-wg/iot/minutes/iot-working-… Thanks to alun Davis (RIPE NCC) for preparing the minutes. If there are any errors or omissions, please let us know on the list. Sandoche on behalf of the IoT WG chairs

1 0

Reviews of draft-richardson-t2trg-idevid-considerations (part 1)
by Michael Richardson 02 Nov '22

02 Nov '22

I wanted to appologize to Sini Ruohomaa for letting eir review languish so long in my inbox. I'll also note that I've presented about this document a few times in the past month under the title: 'Social and Technical metrics for Trust Anchor resilence' 1) IoT Security Foundation meeting, https://iotsfconference.com/agenda/. Oct.5 Youtube coming. 2) TPM.DEV, Oct. 13, https://www.linkedin.com/events/tpmdev2022conference6977630882559864832/com… video links coming. 3) RIPE-85 IoT WG. https://ripe85.ripe.net/archives/video/950/ Slides at: https://www.sandelman.ca/SSW/talk/2022-iotsf-anchor-reputations/index.shtml It's also been presented with different slides a few other times during pandemic. One advantage of doing this in person is that I get to see nonverbal nods of agreement, or looks of confusion from the audience, and I think that the concepts have been generally very well received. But, I'm sure that the actual definitions could use some work, and perhaps that will happen when the RG adopts the document. I've also had about ten private discussions with trust anchor creators/technology creators such as CPU and TEE manufacturers. Getting them on the record has been.... challenging. Taking the document out to industry was the homework I was assigned by SECDISPATCH back in 2022. Sini wrote: > I would like to pass my warm greetings to the authors for the > effort of trying to make this more communicable. I would like > to reference this document when it is ready. It is written in a very > approachable way so I see value in it also as an educational document, > not just an evaluation framework. Thank you for the encouraging words. > "An increasing number of protocols derive a significant part of their > security by using trust anchors [RFC4949] that are installed by > manufacturers. Disclosure of the list of trust anchors does not usually > cause a problem, but changing them in any way does. This includes > adding, replacing or deleting anchors. [RFC6024] deals with how trust > anchor stores are managed, while this document deals with how the > associated PKI which is anchor is managed." > The last sentence is a bit hard to parse. Changed to: + The document {{RFC6024}} deals with how trust anchor stores are managed in the device which uses them. + This document deals with how the PKI associated with such a trust anchor is managed. I wonder if that's actually any better. > "Device identity keys are used when performing enrollment requests (in > [RFC8995], and in some uses of [I-D.ietf-emu-eap-noob]. The device > identity certificate is also used to sign Evidence by an Attesting > Environment (see [I-D.ietf-rats-architecture])." > One closing parenthese ")" is missing. fixed. > 3.6 "what else" question > The identities trust anchor for validating identities of non-web-PKI > devices in case they need to ever talk to each other, or the identity > trust anchor of a vendor specific service that the device must connect > to in order to do e.g. enrolment of other identities, setting up > attestation or zero-touch bootstrapping come to mind (this allows the > device too to know who it is talking to, in addition to having the > device authenticate towards such an enrolment service). > I would cover these with a 'other identity validation trust anchors' in > addition to the public web PKI trust anchors, as the category is > probably too wide to cover satisfactorily an individual subcategory at > a time. I have added sections: Private/Cloud PKI anchors Onboarding/Enrollment anchors Onboarded Network-Local anchors > 4.1: minor > "[ieee802-1AR] defines a category of certificates that are installed by > the manufacturer, which contain at the least, a device unique serial > number." > Had trouble parsing the sentence, is the comma right? Changed to: {{ieee802-1AR}} defines a category of certificates that are installed by the manufacturer which contain a device unique serial number. > "This may be a software setting, or could be as dramatic as blowing a > fuse." > I really appreciate the author's hearty writing style here. :D :-) You should imagine a Star Wars/Genosis-Droid-Factory and/or James Bond/Dr.No with a huge laser gently browsing across defenseless router parts on a conveyor belt, permanently stencilling them with an identity. (With so many droids in the Star Wars universe, surely "R2D2" isn't a serial number, but rather a model number? ) > 4.1.2.2 > "Generating the key off-device has the advantage that the randomness of > the private key can be better analyzed. " > A second benefit that I expect has been more commercially interesting > is that (assuming serial numbers or other relevant identities can be > pre-reserved) the certificates can be pre-issued, which eliminates both > CA latency and CA dependency from the manufacturing process itself. I > still would not recommend off-device generation though. I have emphasized this point a bit at: https://github.com/mcr/idevid-security-considerations/pull/4/commits/4ba7a4… > Due to the leak > potential and wider exposure to insider attack it has a creepy ring to > it that may undermine the trust placed in the PKI. Even if we 'never > store' the key (as is suggested later in this section) we will leave > computational traces of the key around. I agree. Yet, this reduction in cost might be the difference between having a real IDevID certificate loaded into your microwave, and having some BS attempt to do fake security. A major point of this document is for manufacturers to feel that it's okay to tell us what they did. The judgement can come later through market opinions. > 4.1.2.3 > Agree with the conclusion that this method shares the downsides of both > above. Do you have any suggestions as to a better name? The CPU/MCU makers are very keen on this method, and it accomodates the whole "PUF" mechanism too. I am personally not convinced PUF is truly random, but I don't think we'll know until someone clones one. > 5. PKIs > "A PKI which discloses one or more private certification authority keys > is no longer secure." > Technically, subCAs exist for the sake that they CAN be revoked by a > higher level CA, to recover from compromise of an issuing level CA > which is typically more exposed than the higher levels. > However, > everything issued from that subCA is indeed due for hardware recall so > the event is major. But the most major event is leaking the root CA, as > there is no way to recover from that within the same root chain. Yes, so subordinate CAs limit the damage of key lost to a malicious actor. > To get really into detail though, a well managed CA is able to keep > track of public keys it has intentionally signed into certificate, and > depending on the use case even a compromised subCA key could > theoretically be worked around in the field through administrative > means that basically let go of the cryptographic protection of the PKI > chain in favour of administrative tracking. This basically turns into some kind of administrative CRL if you take it far enough. > I think that part would be > hackish and beyond the scope of this text, however. Just can't help > myself going through the what-ifs; these PKIs have to be seriously > robust. Well, again, they need to be robust enough for the purpose that expect. At one IoTSF conference, a pen-tester describes finding a building-control management system for a major airport on the Internet with **default** passwords. No amount of good HTTPS certificates on this server side of this system helps you out here. A system of good trust anchors and client-side certificates would be better, assuming that the system needed to be reachable. OTH, an Internet connected alarm clock (with a cartoon character) for my kids' bedroom might not need such a robust PKI. Just one strong enough to onboard it to my network > Just imagine a full hardware recall of a car manufacturer for a > "oops need a quick bootstrapping identity PKI fix". Or of anything > resembling a home wifi access point box that end users don't even touch > if it's still working. Yes, agreed. Imagine a fleet of ambulances that had to be grounded because the radio had certificates whose CA was compromised. > 5.1 > "It is quite common to have a three-level PKI, where the root of the CA > is stored in a Hardware Security Module, while the level one > subordinate CA is available in an online form." > This formulation implies that subCAs would not be in hardware security > modules or that they cannot offer CAs available in online form. I think > we should definitely underline the importance of keeping subCAs in HSMs > as well. So, I wrote that text trying to emphasize that the root CA had to be in an HSM that was offline. While the subordinate CA had to be online to be able to issue EE certificates. I wasn't trying to say that it couldn't be an HSM! Reading it also reveals that I've messed up the level text as well. > I would separate the two dimensions explicitly and say "where the root > of the CA is stored in a Hardware Security Module in a way that it > cannot be continuously accessed ('offline'), while the subordinate CA > can sign certificates at any time ('online')." Or potentially even > another formulation that mentions completely separately that "CA keys > are stored in Hardware Security Modules so that the root ... and the > subordinate ...". I've adapted your text. > The section below talks about this in more length so this could also be > migrated there. > 6.1 > "first-stage initialization" focusing on the raw number of people > 'involved' feels maybe a bit arbitrary. Okay. > - it is also important what level of access these people have to the > device in practice, or are they performing primarily a monitoring task > - considering a factory shopfloor, it may be misleading to think that > only 3 people are involved because 3 people actually are *supposed* to > be touching the board, if in fact 300 other people have access to the > actual space and could pop by to intervene with the process if it's not > happening in a separate locked room. (Note that the janitors could also > be bribed and planted/instructed even though no one would count them as > 'involved' by default.) Your thoughts are very spot on. How many people are involved that could be bribed? If it's not in a locked room, then I would expect to write down 300 people in the factory. How would you rewrite this section to make this clearer? > I might redefine this as 'exposure' of the device while in the process, > where fully automatic closed area might be 'low' and a large shopfloor > where 20+ people have physical access to actually go physically touch > the device or the equipment processing it as 'high', for example. I've changed the metric to be called "first-stage-exposure" > first-second-stage-gap: This factor is not formulated as a question. > (Some later factors are not capitalized and punctuated consistently.) Changed to: first-second-stage-gap: : how far and long does a board travel between being initialized with a first-stage bootloader to where it is locked down so that changes to the bootloader can no longer be made. For many situations, there is no distance at all as they occur in the same factory, but for other situations boards are manufactured and tested in one location, but are initialized elsewhere. At this point, I'm going to start a new email! -- Michael Richardson <mcr+IETF(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

1 2