ROS 2 Security Working Group, 11 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: ROS 2 Security Working Group, May 11 2021

Description

Discussion about adding PKCS#11 support to ROS 2

A

Being recorded um and yeah two meeting minutes from our last two meetings actually uh ready to be approved, I sent the link out, there's uh just two pull requests.

A

uh Does anybody have any comments or any concerns on that? Or is anybody willing to say uh give that the okay to go ahead and publish this.

B

A

Okay, all right so we'll go ahead and push those out um and didn't have anything else on the agenda. I think we've got a great topic uh that cali's gonna uh uh introduce for us on um how to pull uh potentially pull security bits for raz from uh pkcs uri or potentially a data uri.

A

I think there's lots of possibilities in there, but I think there might be some practical hurdles to overcome, uh but with that I'm going to hand it over to cali to just introduce your use case, and then we can start walking uh walking through uh where to get from here.

C

Yeah thanks it. Can you hear me all right.

A

C

Yeah you're good awesome. So let me let me see my.

C

Screen yeah, I I also uh included or forwarded this invitation to uh two of our developers, manuel and tianci, who are also on the co-op. So that's why we have some new faces, at least so. Are you able to see my screen yep? I can see yes, sir excellent, so um so, basically, first I would like to tell a little bit what we are doing to give a little bit background and who we are so so um I represent tii, which is the technology innovation institute located in uae and uh okay. Oh there we go.

C

uh The organization basically consists of multiple research, centers, um basically all more or less related to information, security and cryptography.

C

um We have like quantum research, cryptography and so on, and what we are part of is this last one here: secure systems, research center and uh what we do is basically we deal with topics such as the hardware hardening software, hardening uh system, integrity, communication, hardening and cloud integration and then uh secure resilient platforms, which is very core of this project that we are doing with drones.

C

So the very project we are doing is uh autonomous drone drone fleet, and basically this is uh quite a big big project. We have a lot of university collaboration as well around the world, including uh europe, u.s and and uae.

C

um This is uh meant to be a platform for further development and for different use cases, enabling research and, and maybe some business business cases as well. um So, but we are not productizing this as this project, so so we are working on uh on a platform and and doing a lot of research on different related topics on this.

C

um Here are some use cases that potentially this drone platform could be used. The idea is that we have a ground control which is based in the in the cloud there. We can run some heavy computation, computational things such as data analysis and and yeah machine learning and and sort of things. Then we have the middle layer, which is what we call drones. These are relatively heavy duty drones with some computing power.

C

They communicate with with each other in a mesh network, but also uh 4g 5t lte connectivity to the cloud, and then they work more or less like a as a motor ships for what we call edge drones, which are much more limited, small drones um and so on. So this is the this is the high level uh concept.

C

The idea is that the throne system can do missions autonomously, so we define a mission in the cloud push it forward to the swarm and they start to divide the tasks and and do what they are supposed to do, and so what this means in the ros2 context is that um we have this computer on board. uh We are now focusing on these um uh drones, which are these sort of like a minor shifts in between so so they are.

C

These heavy-duty um uh drones with some comp computing powers, uh everything there runs in ros network, so so components inside the drone, as well as between different drones, communicate over uh rus rush nodes.

C

Pump uh what else so, basically, uh the idea is that we have these virtual environments on this computer. um They are logically divided on according to different trust zones or or um actual operational features.

C

uh It's it's like a moving target, but the idea is that we are having a hypervisor and then virtual machines on top of this, and so the basic uh beef of the whole thing are different. Ros notes, collecting data controlling sensors controlling the flight commands all this mission um execution. All this is like a big rush to network um what we have had in mind and we will come to this very topic soon.

C

uh What I have also raised in the chat in matrix earlier is that we are basically looking to have this enclave on the board of its its drone, and this works as uh on the port 87 more or less uh it's a crypto back end where we store keys um safely. So uh it's in a rush context.

C

That would mean that uh we are storing the private keys there like for sure we have some other use cases for it as well, but but in this uh use case there or rush context, the idea is that all the esros private keys for all these different environments or components are in this one hard and isolated crypto packet.

C

And then, similarly, we are looking to have the all the cas in the cloud, so we have the root of trust of the root ca in the cloud and also the intermediate cas uh there and during the provisioning of the system, we will be signing this uh artifacts, like public artifacts, like acls, as well as the identity certificates for each each of these environments in the cloud and and moving them here, as we are not productizing it.

C

I think at this point we can assume that doing this moving the certificates and moving the certificate request by hand is totally fine um yeah. So basically I went a little bit ahead of myself. This is basically explaining what I just went through so currently, as we have been playing with esros.

C

um We, we basically have been a little bit struggling now to find the find the ways to uh protect these private keys. So so um we would like to suggest some kind of big ss11 based uproads or some some standard crypto api. It seems that dds security extension uh includes big ss11 in the specification, but but yeah it's imp, implementation that robin is to be worked on. I think that this is something that is not only us who who would be potentially looking after.

C

So I think this could benefit any many enterprise level or actual actual um other projects who need to really harden the key management and similarly to the to the ca.

C

uh This is basically just a picture that I already showed in a matrix chat, so external ca. I think this is not rocket science. This is like how any any web server, for example, would would uh be provisioned. So you have the ca and the intermediates in the cloud. Then the drones themselves would generate their own private keys or or the key pair, and also generate. Then the csr or the certificate signing request that will be sent to the cloud to be signed, and then cloud will provide back to the drone.

C

This signed certificate for the throne and a copy of its own cas, and then the signed permissions file um so very very basic thing. I think this is uh much news for for any of us on the call who have ever set up a dls, for example,.

C

uh Then, similarly, to this big acs, 11 use case, we would have this public components here on the local file system as they are today. If you are running this roster security generate commands, it will create this local, local enclave and local keys.

C

uh So basically, what we are looking for is that the only the secrets would be stored in the crypto backend, and these public components can still reside in the in the local file system, and this would mean the certificates and then these uh signed artifacts, so basically, um whether it's big s11 or some other crypto backend end, it would basically need to be able to take key creation, requests and key con consuming uh requests such as sign and encrypt and decrypt. This is very basic because it's 11 use case.

C

The benefit of this, I think, would be that if it's pkcs11 is that, then this is this. Crypto back end is fully replaceable, so so you can use hsms you can use whatever um pkcs11 supported backends. You want whether on-premise on port on cloud. What not? So this is industry standard and should enable a lot of a lot of use cases, and this is pretty much it so I wanted to keep it keep it short so that we have some time to do discussion as well.

C

This is also very high level, so I can I want to emphasize that we are very open for different approaches and and uh if there are some good ideas to forward, we are all ears, um so yeah, that's about it. Are there any any questions about us or the use case.

B

um Hi it's iggy here and I'm working with the fadelius team.

B

I think it's everything's quite clear when you're in your presentation, uh as you already know, fast ideas at this moment does not support a pkcs, but I do see the benefits of of the layout that you that you presented.

B

I don't know how much or how hard it will be to make all this into fast ideas, but I'm really willing to uh at least.

A

B

Have some contact with you and and maybe dig deeper into every uh all the details and all the problems that we you are facing, so that, and maybe you can start working towards that so just for you to know that we are open to to start working on this.

C

Okay, this sounds really good and- and we are also collaborating on different um open source projects uh where we can. Obviously, we also have limited resources, but but I think that uh we should definitely meet up and uh talk in detail and see if we could also maybe help help with something.

A

C

And yeah about uh the technologies yeah, we are definitely using the fast rtps and uh yeah. We are running the foxy version of ross2 right now, so should be the latest. As far as I know,.

B

A

Does anyone have any other questions or thoughts about the design itself, um because this seems like this was what was the intent of the original design of ross ii? um Anyone with any history can speak to that. uh This does fit well with the original design plans.

D

For the um for the certificate, signing requests is that something you foresee would um be uh online over uh ross networks, or would that be uh something other than.

C

That I think I think this would be uh out of bad like a side channel thingy. uh This would be like a provisioning phase of this whole rush network, so so it doesn't need to happen in the ros network. What I I have personally in mind is that maybe there was esro stools that could support support this, like generating the csr showing them on the screen, copying it over to the see external ca and then receive the certificate.

C

um So I I think that implementing this is probably quite trivial, even that everything everything is already happening there. It's just like the flow is a little bit different, probably.

C

D

I I I think uh I think everything here is uh um relatively um achievable. It's just the technical thing is: um does anyone know about the state of uh pk, pk, cs11 and uh python cryptography library?

D

um Well, one thing we kind of have to work on is helping with their sm smi me signing.

D

C

Yeah, so so, basically, where these two different points come together is that uh um when you initialize this enclave on the on the drone or on the robot, and you generate the key, this key must be generated over big ss11 in the in the crypto back end. And then um you know- and this is basically the flow where you're also generating the certificate request and all this, um but when it comes to the actual, uh once once you have the certificate uh it's in the file system.

C

So basically we at least we are not looking for any.

C

I say, certificate, generations or or even csr generates or anything like that over peak ss11, just consuming the private key and again, I think this is very analogical for what how web servers work when they have dls enabled, and they are using hsn.

D

What what would the uh the crypto backend that's um uh interfacing, with the epm modules? uh Kind of look like that's. uh That's like an extension to um rmw to kind of provide the dds vendors were to look or or is that some of the dds vendors already provided.

C

Actually, the crypto back end is something that we will be creating um ourselves. It's like another, another research project we have going on, and it's it's not only for the trons, it's something that we are doing otherwise, so it's basically like uh our own hsn implementation, very lightweight and versatile, but but uh basically uh the beauty of this whole thing is that it should not matter too much uh what the crypto backend is and how it looks like if it's able to communicate over peak ss11.

C

So you can, you can basically hook anything behind that then like put soft soft, hsn or or you could basically your smart card or whatever you want as a packet. There.

D

So so you guys are gonna gonna have the next and like a modified extension for the dds security plugins that can take and a reference or a pointer to a 2k, uh pks c 11.

D

I certificate storage like some kind of uri of like either.

C

Yeah exactly so.

D

More device to load and then that's that's.

C

Yeah yeah exactly so so looking at how how things have been done in in in the industry before there are different ways to kind of implement this. So very often you have this big ss11 library from the crypto packet vendor and you need to somehow point this key to it.

C

So if looking at the web servers, for example, uh you you can you can point, you can use something called pkss, 11 uri, it's somewhat standardized way, and so basically, when you have your configuration file for rs2 or esros, you would give big ss11 uri instead of the file name for this private.

A

C

Yeah- and I think that would be the most elegant way, then then some vendors use something called wrapper key files. So basically you still have a key in the file system, but it's just basically a pointer to the actual actual key in the enclave. So you this is more like a legacy solution for things like apache that doesn't uh or mod ssl in apache that doesn't really understand anything else than files. So that's why some agencies and vendors- you know, do this sort of approach, but but I think big s11 uri would be.

C

It would be the most elegant and modern way.

B

What, in fact, the security is standard uh does uh define the uh the pkcs uh us as one of the options in order to set the permissions on the the rest of the files. So, apart from the file uh protocol, we could use uh bkscs.

B

I mean it's right there, it's understandable, just that we are not supporting internet right now.

C

A

So wouldn't that require update to the middleware, because, right now the middleware assumes that everything is on a file somewhere. So we'd have to change that to uh to allow accepting a uri.

A

B

Correct uh yeah at this moment uh when, when we are configuring, the middleware uh all the properties uh referring to the security configuration they are uh set, or at least we are on uh only supporting uh file uh your your eyes. So it would be just change that into so that we could uh support the pkcs.

B

Obviously, and we should we will have to- I don't know, link to some library supporting that and and then we would have to change whatever configuration. We are writing on the on the properties to use uh a different url.

A

So is that going to require a change to the roster design dock, just to specify how we're going to locate that similar to what we did last time when we reworked how the enclaves were set up? Is this going to mean that we just have to find a way to support? I mean that it sounds like that's going to be. One of the early things is to figure out nail down what the design is for, how we put in a pkcs uri.

B

Yeah, I think so.

A

Okay, let me ask another question for you um as you're going through this, it looks pretty clear um that you still have a file system on all the drones um yeah.

C

A

uh So so you still have the ability to drop a permissions of governance xml file in a directory for the drone. Is that correct? That's correct, yeah, okay! So there's no at this point, there's no need to support the data uri, uh which allows you to work without a file system. That's a completely separate problem right.

C

Yeah, that's another thing: uh yeah! You are referring to this other other topic in the this course right and uh right, right, right, yeah yeah. I think this is this. Doesn't concern us too much, so we we have. We have file systems in all this environment, so.

A

Okay, yeah all right yeah, because.

C

A

I, when I was looking at that beforehand, I did this- I mean it makes perfect sense right permissions and governance. The permissions of governments, xml signed piles, um still have to reside on disk, so they're still going to be, you know, accessed by a file uri, so that still needs that enclave and configuration set up so.

C

Yeah so those two yeah those two files. They are basically here on this environment next to dca files. um I think they are more or less public components by public I mean that they don't need to be specifically encrypted nor put to the enclave, so we can consume them directly from the from the file system. Okay,.

C

D

A

Just pause for a minute to see if anybody else has any questions or wants to dig into it any further or if you've got a similar use case I mean we don't want to solve for just one problem. I think we want to solve for all of them, but if you get similar use case for thoughts on this before we uh uh kind of figure out where to get from here, um does anybody have any more comments? Dad.

B

Hey I'm tomia with sony. Can you thanks for the talk? Can you share the slides on somewhere that we can access.

C

Yes, yes, I can procrastinate yeah. I think you can probably put them somewhere with the meeting minutes right. Yeah, absolutely.

A

If you want to share with me I'll uh I'll make them uh I'll, add them to the meeting minutes and then I'll uh yeah, if we have them somewhere I'll.

D

A

A note in the matrix chat as well: okay,.

C

A

Sounds perfect.

B

I got, I got one more question, that's kind of like off topic, but what is the isolated environment.

C

I think I missed it. Did you mention about hypervisor yeah? So in this this context it means uh at least with the current design. It means a virtual machine like a hard and hardened uh virtual machine. So, okay, we have like a basically a computer pc on board and then we are running hypervisor with multiple virtual machines. There.

C

Okay, thank you. So the yellow boxes here are versions.

A

Anyone else have anything to add or questions, thoughts about how this might apply to anything you're working on.

D

The um the hierarchical um intermittent uh certificate authorities, um I think, um are, are a good approach and like handling the permissions uh at scale so like. If you have like a large deployment of robots. Obviously you don't want to have to start revoking every identity certificate for every node.

D

That might be a part of broke, but if a particular robot is compromised, it seems a lot more simple of this to revoke one certificate intermittent certificate authority, that's associated with that device. So I I like that. Do you see um other more advanced means of of identification or.

D

Maybe other decentralized means of authority, then um these these networks, I'm thinking, maybe something more exotic like either using dlt, distributed ledgers or something else for doing the identity management.

C

Yeah, that's that's a good question like we.

C

We have a lot of hooks in the ocean so to say, and we are investigating a lot of different options, um but yeah right now, yeah. This is the way we are currently focusing, but we have like different layers as well. Like I mentioned, we are working in a mesh network, for example, and there is a whole another, basically authentication schemes and and and identity management layer. There.

C

So so yeah for this esros context. This has been the what we have had in mind, but obviously we are very open for hearing other thoughts as well and if you have some good.

D

A

In a question for eaker on uh on dds support, do you currently support um the intermediate certificates and certificate revocation so that, if um you know a drone were compromised, you could actually revoke that certificate and the rest of the drones in this fleet would know about that.

B

I know we do not uh support uh regulation for permissions, I'm not really sure about certificates, but I would say we don't, but I I I would have to check that.

A

Yeah, I think I think la that was part of your design was to be able to uh kick someone out of the fleet. If you will.

B

And that makes sense.

C

Yeah yeah, that's definitely one of the use case. So if we have a compromised compromised unit, for example, we can kick it out. So it's basically a revocation here, but but I think it's, it was also part of your plan. Sit in the documentation right.

A

Yeah- and that was part of uh I know, marco was working on a scenario that that he was looking for that as well.

A

um You mentioned you've dug into a lot of things. Have you looked at all at um just key management and key management protocols?

A

uh I know that seems like that's one of the modern ways to to push keys out to edge devices. Something like that um is there. I honestly haven't looked at that in the context of bras. uh Did you notice any fits there is? Does that does that work at all.

C

Well, another interface that could potentially be be used here is knit, but I uh basically when it comes to the the key management itself, I don't think we have a lot of hierarchies here or the other structure is not very complicated so and we are not pushing keys back and forth, like every every identity, creates their own keys and stored them in their own local enclaves.

C

So we don't have like centralized key management so to say plant. um So that's why I consider our key management seem very simple.

C

But again, definitely if somebody has good ideas in that regard all years and about gamep, it would be a substitute for big ss11 here, um it's more like a key management interface, although they have some overlaps with big sus 11 as well.

C

But I don't think gaming is part of the dds specification either. So that's why I got a little bit fond and fan of picasso 11, for this case.

A

Right but yeah, I just read across it in the documentation and like you, haven't seen it in the tds: it's not in the dds specs, so yeah.

C

Yeah, unfortunately, I have a another call, actually that I need to jump to.

C

But if there are some more questions, I can still stress for a few minutes.

A

Okay, yeah. We appreciate your time, I think we'll follow up on matrix uh and outline some next steps. uh I have a feeling. The next thing is probably for you and and acre, and maybe a few others to just round table on uh where to go from here I have a feeling, there's uh probably some a little bit of design and then a lot of implementations might guess.

B

Yeah I was going to propose that.

A

Okay yeah, so, let's, let's follow up on chat because we are running a little bit over um uh and we'll we'll do that. um So that was a great discussion um uh on phone. Does anybody else have anything else for the meeting uh or anything anything to add from here.

A

Okay, so not hearing anything I'll, go ahead and close the meeting and I'll say yeah, let's again follow up um uh icar and cali I'll leave it to you to kind of drive this for now uh and if you want to have a meeting before our next scheduled meeting in a month, yeah just let us know reach out on matrix.

C

Yeah sure that sounds really good.

B

Okay, we'll keep in touch through matrix.

A

Okay, all right! Well, thank you very much. This has been a great discussion and I'll write up the notes and post them out for you.

C

Perfect and I'll be sending the slides great. Thank you. Thank you.

A

B

Right thanks everybody. Thank you. Thank.

B

B