ROS 2 Security Working Group, 15 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: ROS 2 Security Working Group (2020-12-15)

Description

Invited talk on Privaros.

A

I should be stock now.

B

All right so thanks everyone for coming, um we'll, go ahead and get started, um go ahead and the designated presenter can go ahead and share their.

B

A

Can you all see my.

C

Screen not yet I don't see it it's anybody else. Oh there we go.

D

Okay, now it's working.

A

Okay, so uh welcome everyone. uh uh We are a team from a computer system security lab at indian institute of science bangalore in this paper. In this presentation I will present our work. Prevaros.

A

Our paper concerns the problem of privacy in the age of drones. End user drones are now commonly available for few hundred dollars and it is predicted that this use case will grow even more in the future. Drones are equipped with sensors such as camera and gps, which poses threat to individual privacy.

A

Unfortunately, regulations regarding the use of drones are either used in various countries and there is a lack of mechanism to enforce privacy policies on drones.

A

This is where our work comes in, while the problem is challenging to tackle in its entirety. We focus on subclass of drones,.

A

Which have a reputation to protect as a result, there is no incentive for these companies to operate a road drone, a drone with a malicious intent. In fact, they have a strong incentive to comply with the local privacy regulations.

A

However, even in this setting, we need mechanisms to enforce a privacy. This is because delivery drones visit various host airspaces as a part of their delivery route. Each host airspace may have different privacy needs. The responsibility lies on the guest delivery drone to prove to the host airspace that they are in compliance with the privacy requirements of the host.

A

Moreover, e-commerce companies may contact out the drone operation to the third party delivery service. Although e-commerce company may require drones to comply with certain hardware and software requirement, these delivery services may not be entirely trustworthy.

A

In this paper, we contribute privacy, which is a drone. Software stack with mechanism to enforce privacy policies specified by the host airspaces privacy adds mandatory access control policy enforcement to ross, which is a middleware in robotics and drone platform. Priveros runs on the guest delivery drones and enforces the host privacy policies.

A

It uses hardware attestation on the guest drone to prove to the host space that the drone is in compliance. Trusted hardware is not a far-fetched idea. In fact, many upcoming regulations, such as a digital sky, which is proposed by the government of india, requires uh commercial drones to be equipped with trusted, hardwares and associate cryptographic keys.

A

Drones can be identified by its public key, which is registered with the country's aviation authority.

A

Now we'll see how we envisioned our policy to be enforced with upriveros and later I'll, give you examples of privacy policies which the host can.

A

Have to begin with the host airspace, specify their privacy policies and communicate these to the aviation authority.

A

When a drone fleet operator wishes to send a drone on a delivery route, the drone contacts, the aviation authority with its identity and a proposed drone uh a delivery route and also presents a hardware based attestation to its software stack. In particular. A drone must prove to the avsn authority that it is running preveros, enable software stack.

A

The aviation authority looks up its database and responds with a set of privacy policies uh of all the host spaces. The drone will encounter on its delivery route.

A

Note that we are assuming the policies will be joe tagged with the host airspace's. Gps coordinates.

A

The drone loads, all these policies on a local storage and then start its delivery.

A

When a drone approaches a host airspace, as determined by the gps, coordinate a cleveros agent running on the drone triggers the loading of the corresponding host privacy policy, prevaros mac enforcement then enforces the privacy policy upon the request from the host airspace.

A

The guest drone can prove to the host by a hardware based attestation that it is running rivera's base software stack and that the host policy is being enforced.

A

This is optional, since the drone has already proved to the aviation authority that it is in compliance and the host trusts. The avs authority.

A

And the final step, of course, is entering the airspace and delivering the product.

A

So now I will go through the example policies here. I'll just give one example policy consider, for example, a drone that transmit its video and image feed to an external entity.

A

This may be a cloud server, or that makes a real time navigation decisions for the drone, or it could be a ground-based remote control operated by an untrusted ground-based operator.

A

The host may require that all privacy sensitive objects in the drone's camera feed, such as people faces and car registration plates, be obscured before they are transmitted out of the drone.

A

In privacy policies are specified as communication graph. The node of the communication graph are applications that run on the drone. The edges denote communication that is allowed via inter process, communication, sockets, segmented and so on.

A

In this case, you can see the company communication graph specifies that the camera output must pass through this green trusted application before being consumed down downstream, such as the navigation software or any other network facing.

A

A

In privacy, we use trusted application to declassify sensitive information. In this case, we, the trusted blood, filter application, is entrusted with the task of identifying sensitive objects such as faces and blurring them suitably. We rely on host to identify these applications to perform the job of declassification.

A

For instance, we do not attempt to verify that the faces have been properly blurred.

A

Rather, the goal of privacy is to enforce using mandate access control that applications communicate as specified by the host.

A

Host provided policy, that is the communication graph. Thus, for instance, a camera application cannot directly send pictures or video to the navigation software or any other network facing application.

A

Now, let me go over the basics of app armor. Apparmer is a linux security module for enforcing mac? It is a whitelist model where programs are confined using policies.

A

Main drawback of vanilla, app armor is that network checks are coarse-grained. That is only allowing or disallowing the network connection. This is a problem because at the sockets send and receive lsm hook the recipient, even if it is running locally. That information is not.

A

A

Now, coming to the basics of ross I'll quickly go through these, so a ross is a piece of a middleware implemented as a library library that is linked with the application.

A

Applications running on a ros platform publishes a message under a topic such as camera. In this case publishing to a topic. Camera output applications such as navigator can subscribe to this topic. Ross uses a dynamically a dynamic discovery protocol offered by the dds to match up the publisher, and subscribers once the match up has happened. Raw establishes direct a network socket-based communication via the underlying operating system.

A

As it stands, vanilla ross does not perform any security checks. It is easy to spoof message messages, impersonate application and inject a message to address this issue. Secure ros is developed which encrypts the communication between applications also prevent obvious attacks, such as message, spoofing message, injection and also authenticates application.

A

To show the shortcomings of sros, let's take an example, as shown in the figure here. Camera application is publishing to two two topics with the same name, that is the camera output with different types here here. The types are imaginary just for the example.

A

The primary goal of camera output status type is to monitor the camera operating status since sros uses applications, name application name to look up the application certificate.

A

We can replace a benign camera status, application with a malicious application and we can still use the b9 camera camera status, certificate.

A

Let's take another scenario.

A

Let's, if a host requirement is that no network facing application should directly subscribe to camera output, image type, it could instead require that camera status should pass through a tested application. That is the let's say, a scrub status which performs sanity checks.

A

One way to implement this in sros would be to decouple different types with different topics with different types, so here, in this case, we'll have to change the camera output to make it into two different types: two different topics, one can be image feed and another one can be the status feed.

A

This will require uh application code, and this will basically require us to modify the application and also to regenerate the manifest and also the introduction of tested application, since the applications are not written in such are not written in such a way such that they will communicate with trusted application to perform the redirection.

A

It is not possible without modifying the existing.

A

Application so uh so a perivarous enhances these uh shortcomings.

A

First, we'll look into the app armor part.

A

So, first, so we need three additional things in the policy. So first is we need to add a label. This can be a hash of the binary so that we can perform a hash check.

A

The second is, we need a way to specify if an application is trusted or not, and the third is specifying application to which the current process can communicate. To.

A

I remember the problem of network checks where, at the level of lsm, uh socket, send and receive message. The recipient information is not available in order to solve this problem. What we did is we attached a process identifier and we propagated it down uh to the network stack and then, while receiving at the receiving end, we performed the check.

A

So this is how uh we were able to uh reduce the network checks to fine grained uh that is specifying to which process the current process can communicate to why this network, via the sockets.

A

Coming to the ros modification.

A

To perform the redirection, we need the ability to send commands to all the applications in a domain. Therefore, we make all the applications subscribe to one topic: let's call it the flow controller.

A

We did this in the rcl cpp layer.

A

We make the rcl cpp node subscribe to our default topic to receive commands. This can be done in rcl also and in r or in our mw also, but for the prototype we did it for rcl cpp.

A

Now the question comes: who can publish to this default topic? So the answer is only the trusted application can publish to this a default topic. These trusted applications are specified via the app armor.

A

This check is performed in the dds, where the publisher and subscriber is created by doing an ioctl call to the kernel to check the app permit profile. If the current process is trusted or not,.

A

In the sros manifest, if topics are not present, then application cannot publish or subscribe to it. So so without any change, we cannot perform the redirection. Therefore, what we did was we over a provisioned application with the temporary topics so that the so that we can redirect flows by the trusted applications.

A

So for this during the manifest checks uh in uh uh we are temporarily, so we have a fixed set of topics. uh uh We do a bypass of such.

A

A bypass checks for such topics.

A

So the main thing is uh how to change publisher and subscribers, which are bound to topic once they are created in the application uh in the application layer. We need to modify code in order to change this, so this is obviously not a feasible approach in the dds layer. We simply cannot replace the publishers and subscribers by creating a new one.

A

This is because these publishers and subscribers they have the callback functions of the applications which are invoked whenever a new message is received.

A

So, therefore, in in order to change so the uh so the application still so, if, if you want to perform the redirection, we cannot modify the publisher and subscribers of the application application doesn't know the topics are changed, but still the redirection happens. uh This uh we were able to achieve this by modifying the our readers and the writers.

A

So here, in this case, we modify the datawriter and we also modify the rtps writer, and so, if we replace the datawriter and the rtps writer means as well as the readers, then the problem is the connection will get terminated.

A

So if the application themself, I won't reestablish the connection, then that connection won't happen. So uh the the problem uh here is, if the connection is terminated, then uh who will initiate the means connection to solve this problem? We leverage the dds discovery protocol so which is means advertised periodically, so that new connections will be formed whenever we replace a data writer with a new one.

A

So this concludes our ros changes. Are there any questions.

B

Anyone in all your audience have it.

A

Or like we can have one at the end, also.

E

So this isn't really a raw specific part of the question, but just kind of thinking about how this is laid out is there an expectation that a host airspace would extend beyond the actual physical boundaries of that particular location, because otherwise I could easily see a route that would say skirt alongside a sensitive location and be completely free to use whatever imagery it could come up with as long as it doesn't cross the line.

E

Even if it's able to take very high resolution photos in that direction,.

F

So roger may I answer that question. This is uh yeah, so um it's it's a very good question. So uh and you know if you were to consider essentially like cylindrical uh zones in some sense, uh this problem would arise where in some sense you know you just have a cylinder rising up from the uh from the boundaries of the area. But um so you know different countries have different regulations.

F

One of the things that digital sky, which is the one that we have studied a little bit, uh is proposing digital sky is the is a standard proposed in india. Is that around certain regions, for example, airports they're, proposing conical regions? Okay, so it's like, so what so? The uh the air space the restricted airspace rises like a cone from uh from the from the uh you know, the location that's to be protected, so you know, as you approach you know, you'll have to go down the boundary of the coal.

F

So when you're, when you're really close to the uh probably only when you're a few meters above the ground, can you be really close to the boundary as you rise higher and higher you're supposed to be further and further away? Does that make sense I was trying to you know.

E

Yeah, I I I see perfectly what you're talking about there, which that leads to the second thing that I'm wondering, because if you do have that capability, then that means that you know adjacent places could potentially have overlapping areas that would be subject to both policies. Absolutely is there any problem with contradictory policies.

F

Excellent question: this is not something that we have investigated yet uh you know our first. uh Our first attempt here was to provide the basic capability to enforce mac. I think there's a lot of potential here to investigate you, know, policy languages and how to investigate conflicts between policies. You know: can policy should policies just be described in terms of gps coordinates, or should you consider pitching the yaw of the drone? All of these things are questions worth investigating. We haven't yet looked at them, so I don't have good answers for you right now.

B

B

Well, I have a few um could: uh could you go back to um maybe the slide about the redirection, the topic redirection, so um I glanced at a bit of your patches um a while ago, and it went one of your modifications that you're you'd, like you stated in rclcbp, is that um you had to account for this um this switching or this sort of indirection, whereas prior uh you had the camera driver, the navigation stack communicating over this camera output topic and you sort of inject your filter application um sort of seamlessly in in between as a sort of a middleman, to provide the the sensor sanitization.

B

um This is like a a kind of common test that we may be doing in the ross ecosystem by um explicitly denoting the node and.

B

Remapping the topics directly in something like rust launch are: are you under the constraint where, like you'd, have to hard code the topics in the application binary, as opposed to using like a launch configuration file to to dynamically change these based on.

B

On incorporating the the filter node in the launch file.

A

Yeah, so for that redirection of either topic uh you need to relaunch the application. Is that right.

B

If so, so in ross you you can like swap topics um but yeah. That does involve a you know like a decons uh destruction of and construction of, a of a data reader and data writer. um As far as I'm aware, um but it's it'd be sort of unusual to um I.

B

I see like this as some kind of merit here that um it would, it would be very uh seamless for the user, and that, like you know, they have some sensitive data flow and they just label it as such, um but being a little bit more explicit uh would simplify a few things in that you wouldn't necessarily have to modify uh the dds layer and the rcl layer with this in direction.

B

The data flow would be could be made explicitly represented in the launch file, and then that could also be easily translated into the dds access control policy.

B

um The the other thing is um here: you describe a scenario where yeah you're correct that um in dds you could use, you could reuse the same uh topic name and it could be po and over that topic could be published. Multiple um uh idl types or different topic types, so you're, correct. There's there's nothing that like enforces you what the topic type has to be over a certain topic name, um but that would be considered uh abnormal.

B

I think in in the ross like um you would you would you would start getting lots of logging errors and a developer would normally try to avoid um ever double using a topic like that. Because of this, it's not um a thing that ross normally supports.

B

um I think like ross speak, because it's all it's all distributed now. I think you know ross kind of work, um but um I'm not sure a single camera process. Node uh could publish over the same topic of two different types. Imagine it it might issue an error, um but the subscribers could sort of work it out, but um yeah. That's that's just something that maybe maybe a remark but cool.

A

True so, uh basically like uh uh the the publisher still can uh means have the means, some multiple publishers with the same topic name, but the application won't crash in ros2.

B

B

And then the the modifications you had to do with the with app armor, I see uh you had some patches to that and uh um the linux security module. um So that's for um having a link security, module, enforce the inter-process communication restrictions.

A

Yeah, yes, specifically to the network rules that.

B

That seems pretty novel there. uh Do you want to dive a little deep there.

A

So yeah, so the main problem in a vanilla, app armor is uh it's not means expressive. So basically, uh you can just specify whether an application can communicate by the network or not so uh here in uh in our settings. Since we are dealing with uh stopping the communication uh among a different processes so and a ros uses a socket-based connection, it can be a udp or tcp. So we've wanted a method in which we can specify to which applications current process can communicate to even by the network. Sockets.

A

So uh here in this case, uh if you specify that camera cannot talk to the navigation software and also so then uh so then in the policy we won't have the navigation software.

A

So the connections will be dropped like at the lsm level. The packets will be dropped, even if the camera application tries to send a message.

E

I was actually wondering on this particular um one here. You know it's showing disallowing. You know sending that to the navigation software and disallowing, sending it to a network facing application.

E

Would it be possible for a developer to create a different node that did not meet those criteria which could access the camera data directly and then forwarded on to something which was not intended to have it.

A

uh If it is there, so uh this problem uh comes uh of uh so uh this is uh basically uh uh will be an information flow control problem. Then so uh here, uh since we are using mandatory access control, then uh yes.

F

No, so so, actually let me answer that so uh in this particular platform, which is a mandatory access control based platform, the owners of uh I of rejecting bad flows, falls on the policy developer. So you know, when you have a platform like this you're expected to have written down these these policies, almost like an essay linux policy and look for bad instances of flows, uh so in some sense the uh the onus of uh of ensuring that no such leaks exist comes via policy analysis.

F

Now we are working on an extension to ross that allows you to do this dynamically. That's what rakesh is saying which allows you to do information flow control by tracking labels at runtime, but that system is not yet ready. So as it stands, you will have to analyze the policy ensure that there are no such applications that leak data like this, without going through a trusted application, um but you're right I mean if there was a node between the camera and the navigation software that didn't go through the trusted blood filter.

F

Yes, you know you would have a leak of data, but that now becomes a policy analysis question making sure that the policy, the policy that you're going to install on the drone, satisfies your your local security.

B

B

To to get back to the app armor.

B

When, when it's inspecting the socket connections, uh supposedly over the local host network um between two process, co-located on the same host,.

B

um I think that's something already that the dds access control plug-in would already kind of inspect it. You know it would verify the credentials and permissions of the other node and decide whether it wants to initiate the communication.

B

Is there another advantage, uh aside from of of having this um this discretion in the blank security module rather than just the dds transport is? This is something that could also be used to control, whether.

B

Any other side channels like shared memory access- or I think you mentioned shared file access in your paper- is this- is something that you could use for. Shared memory transport as well.

A

So I just do again uh just to be a clear on the question. uh A dds itself is just not uh like uh enough for the protection right, because these are, I means at the end processes and they can, let's say open up a socket connection, and if they are written in such a way that they can directly communicate among themselves, then they can still use the network sockets to communicate.

A

Then for such a scenarios, the dds means alone is not enough.

B

Okay, so yeah you're you're operating into a threat model where the applications may have access to additional libraries to initiate a sort of side, channel communication over the network. Okay,.

F

Right so one of the main contributions of this work was to ensure that protection happens both at the ross layer as well as the sorry. uh You know, this access control happens both at the ross layer as well as the os layer, but one an important point.

F

Design consideration was to ensure that the trusted computing base is the os alone, so that you know the only functionality that we leave to ross is actually, uh you know, deny any flows that already exist, but uh so sorry, um the the os can deny flows uh even if they are allowed in draws. So ultimately, the os says no, even if ross allows the flow that's not allowed.

F

So we went to great plains to actually ensure that the tcb the trusted computing base is the os and the oslo.

F

To our knowledge, we have not extended the pcb to the ros layer.

F

So that's something that I think we have. We have. We placed a little bit of thought on. uh We didn't want to extend that to the application layer.

B

um Oh the flow control topic. um So can you explain what was the role every every node has to subscribe to this flow control? Topic is that's. What's.

A

B

A

So, uh at the end, these are distributed processes.

A

So, if you want to, let's say a send any command, we have to send the command to everyone and then like in the message it can contain to which specific process it belongs to so so for that requirement we had to make sure that all the applications subscribe to one topic so that we can send commands to that topic to say: hey, you need to change your publisher from this topic to that topic.

B

Okay, so this is informing which topic to indirect to all.

A

Right so moving on to our evaluation, we now present a snippet where we illustrate the performance impact of redirecting flows through a trusted application, as required, for instance, to enforce blood exported policy. Our evaluation platform is nvidia, jetson tx2, which is equipped with arm dress zone.

A

We reflash the software stack on this board with priveros, so in the paper you can find the evaluations with a micro benchmark.

A

So let let us consider a basic setup where the camera directly communicates with the navigation software. This is the base case and the latency of this communication is 8.1 millisecond and it consumes about 750 milliwatts of power.

A

Now, let us introduce redirection to study the base cost of redirecting flows through another application. We direct the flow via the null blur filter that simply serves as an identity function. We note that this increase latency in this case about 115.

A

This is inevitable and we view this as a cost of privacy. Enforcement power also increases uh by a small amount about 1.8 percent.

A

We now consider a blur filter application that performs some computation on the input image stream. As a result, the latency further increases and power consumption goes up by 8.1 percent compared to the base case. Note that this is highly domain specific, depending upon the nature of the computation that happens within the trusted application.

A

Thank you for your time like. If there are any more questions, we can have a discussion.

B

B

For the impact that sanitizing the data had, um this was done over. This was implemented with a node over at the local loopback or and not necessarily uh compose nodes or um using shared memory. Transport, correct.

A

It it was over a loopback, so touch it up. Yeah.

B

B

B

John luca, did you have any questions.

D

Yeah I was curious about what vinod said about the analysis that they want to do on the mandatory access control policies. So you said you want to use labels right and you're working towards that.

F

That's right, so we are looking at dynamic information flow control on top of cross. But that's not this paper. This paper was just mac, um yeah yeah, absolutely.

C

F

Yeah yeah right, so that is work in progress right now,.

F

So you know just to give a little bit more uh context. Right, I mean one of the pain points here with mac. Was that, although you can enforce these policies of this of this kind, the onus is on the developer to ensure that the policy ensures uh you know, secrecy and site-specific security goals.

F

Instead, what we wanted to do was to have this dynamic notion of tags so that if you read something that's sensitive, you also get tagged as sensitive and so on, and so finally, when the data is being exfiltrated from a sync at that point, you can do your enforcement, so it's much more dynamic rather than having to come up with these static communication, graphs and so on.

F

So so that motivated us to work on this dynamic information, flow control, based approach for ros, and we are working on top of a system called cam query for that which provides you know such tracking within the linux kernel, and we are extending it into the ros layer also. So we want to bring the notion of ros topics together with the notion of information flow labels at the os level. So that's the project, but we are still a ways off from completing it.

B

What's the linux project cam something oh.

F

Yes, it's called cam query um or uh cam. Query is the one that we are using. That extends another system called cam flow, um it's from the university of british columbia, but I think there was a cambridge connection. Also, that's why it's called cam flow.

B

um I'm trying to remember: um do you know what type of uh of label operations it performs? Is it just uh sensitivity or is it also? Does it have sensitivity and privacy labels.

F

So you know the the the base system is just a label propagation system right and your labels are 64-bit values. You can feel free to assign semantics to them. um So it's it's going to propagate labels at the level of os level, artifacts things like processes, sockets files and so on. um So that's what that is.

B

One thing you have, though, with simple labels is the enable an inevitable label creep where, yes, um as as things as information propagates through the system, it achieves a level of sensitivity um that is almost like no longer usable um that no one can actually, because everyone's.

C

B

And then you have to have some kind of means of of declassification, so you can imagine your your. Your filter operation receives a highly sensitive topic and then has to declassify that um and then yeah you have to account for that t-class. Is that something that the linux project already does.

F

No, no, no, no. The linux project is just basic infrastructure for label propagation. Now you can sort of bless certain applications for declassification and that's what we are doing right I mean we want to bring this notion of trusted applications that that we refer to in this talk to also that problem there. First of all, we want to understand the problem of label creep in a practical raw space system. You know maybe like a real robot. You know.

F

To what extent is their label creep and then sort of figure out how to design these trusted applications where to place them, and so on, so that you know we can declassify the uh the data flows. So all of those will be part of the empirical evaluation of this work uh once it's ready, uh but that's an excellent point. Yes,.

C

D

Actually, I have another question uh since I was going through the github repo and I've seen a lot of notification on the kernel, uh which you know it's it's pretty pretty hard if you, if you have update on the kernel- and you need to bring the code uh here and there so uh about the code, how much of it is, uh you know necessary to be there or has been incorporated. That has not been completely written by you with you guys.

F

Yeah, so I guess rakesh and abhishek are the best place to answer that question.

A

Can you take up this question.

C

Yeah sure so, if I understand the question correctly, you are asking us how much of it is absolutely necessary for our system right.

D

Yeah, because I've seen that a lot of modifications are embedded inside the kernel and I'm always concerned about those kind of modification. You know if something is modified at the kernel level, you need to bring everything uh in the new version and such you know, you're having a lot of code base. That is, you know. Hardcoded uh is usually a pain in he has to manage. That's that's a question. If it's all necessary or it's something that you included, then you learn some somewhere else or something yeah.

C

Yeah, absolutely I understand that concern I mean um that's why we tried our level best to make all our modifications within the security module itself. So I mean you know the the lsm infrastructure allows you to create modules right, I mean in the sense it's not we're, not touching the core kernel components like you know the memory of the sec, the networking subsystem, but um we had to make a slight exception for the networking component uh because it was necessary to you know, propagate uh the pid of processes through the network stack.

C

So, for example, we tried uh doing this via net filter hooks, but to our understanding the net filter hooks aren't in process context in the sense that at the let's say, the ip 4 output hook, you don't know which process actually sent that packet. So we had to you know, um sort of create a workaround which involved modifying the network stack, and that was very little. Actually it was just about.

C

You know, I think, not more than um 30 or 40 lines of code, but apart from that, most of our changes are to you know the security module apartments, security module exclusively.

B

Are other patches uh you'd be willing to uh maybe push upstream, because I think those are fairly valuable.

C

Yeah yeah, it's all in the github repo. It's completely open source.

B

I'm saying to maybe submit a pull request to the code base uh and maintain yourself.

C

Yeah uh yeah, so that is something which will require a lot more work. We haven't thought about that, but certainly that is something we could uh explore. um Yeah. Thank you. We will. We will definitely look at that.

B

Yeah, I think the community, the wider community beyond robotics, I think, would be very interested in that as well.

C

B

um Yeah, so you mentioned the uh policy construction and the the onus of of uh correctness currently on the on the user.

B

um One thing we have in the works with uh s ross is uh this concept of node idl, where you have a description manifest uh describing what interfaces the node itself and the on the more abstract level and the terms of its interactions with the computation graph, what it requires for what it minimally requires for a basic operation, and then that is something that we would use and the sros tooling to auto generate the access control permissions.

B

And so we have something a prototype where you can have an existing running system and then audit that system by taking a snapshot of the uh connectivity, topic connectivity and uh then translating that into a um yep. So jeremy, let's put up the node.idl um docket um and then that's something that that srs would would consume, generate the minimum spanning policy that they would translate to the dds security artifacts.

B

But, like you said, it would take a little bit more analysis on the data flow to verify that you know you aren't uh leaking sensitive information through a side channel or that you left a loophole.

B

F

So this is upcoming, you say.

B

We we have the policy generation, uh the idl is um still, I think they have canonical's been working heavily on, that they have a a prototype and a design dock. You can read right now, um so I think that's something that could probably be incorporated into this larger scheme of validation.

B

um Certainly something me and charluka are really interested in as well.

F

So I'm just curious, so this is at the manifest level for each application right. uh What you just mentioned.

B

Yeah it's this sort of additional manifest we've that is is uh authored. On aside from the so aside from the uh there could be the you know there could be. I think it might be pretty hard some code analysis and maybe where you could acquire.

B

This manifests either through static analysis of the code to figure out what topics it's using or again through runtime measurements, um but that might be a more advanced topic. I think right now we're just thinking about where library maintainers, who are domain experts for the sub application, that they're that they're designing, would then provide sort of default, sane, idl files or node.edl files. That would then be appropriate for end users to incorporate when generating their unique security. Artifacts.

F

I see, but the runtime context of how the application is used. You still have to sort of take a snapshot of the system and extract it. Is it.

B

Yeah yeah, so I mean that sort of inherent difficulty in, like you know, secure dds and that um the permissions are sort of static once you've once you've loaded the dds participant and it's acquired its credentials.

B

um The default plugin at least doesn't have like a means of like changing that dynamically, um which makes it easy for like this centralized like governance, but um that rigidity yeah. It's not quite as flexible um there's, been discussion with some uh dds vendors on.

B

How we may be able to uh update so if, if, if a say a ross node finds that needs to dynamically subscribe to a new topic, it could self-update its own credentials if it had a key server request mechanism of like contacting a ca for new credentials. But that's that's a bit far in the future.

B

um Yeah, I think uh I think the the patches, though, like this indirection, seems pretty tough to like I'm, not sure if we would be able to upstream that into like rcl cpp um is, uh would would it be more sane to take like eventually take the approach where you would be explicit on these redirections for sanitizing the data in the launch file, as opposed to um having the flow controller.

F

Yeah, so you know this is so one of the things that we were trying to work, one of the constraints that we were trying to work within was you know if you had a commodity or off the shelf, sros application with a with a manifest that was baked in then you know: how do we get everything to still work? um If you had the ability to, let's say, tailor the manifest files to a particular.

F

um You know communication graph or to a particular scenario. You don't need to go through all of these things right where you have these additional topics and so on.

F

So all of these things uh arise only because we were working within the constraints of existing applications and baked in, uh in some sense manifest files where we can't really change the manifest files without having to, without issuing a fresh certificate for the application.

F

B

Right so that makes.

C

Sense, yeah yeah.

B

Yeah, because the entire um stack is um cryptographically signed exactly on the disk and uh you still need a way of of modifying it. Okay,.

F

So so that was a design consideration as well. That went into the system. I mean clean slate right yeah, you can just say look, this is the communication graph I want and then go top down generate all the manifest files and that's all, uh and then you know you issue the certificates for the applications. It all works within the sros framework.

F

But of course you know you still have to do os level enforcement uh in case there are any malicious applications that try to communicate outside of the the dds and ros framework, but that's the app armor stuff so ross alone. If you had the ability to go top down, that's what we would have done, but we also wanted to have the ability to support existing ros applications, while only probably minimally requiring this additional topic.

F

um And so that's that's the reason we did things the way that we did.

B

So you guys were using uh arm trust zone and the the jetsons. What's what's your experience uh with that.

F

So rakesh can share some so.

A

Stories, I guess yeah, so uh you mean to know about the documentation regarding the zoom.

B

It's it's it's something that the working group has been interested in with like uh uh having a dds plug like I, I think arm was working on a little project for a while and uh implementing the dds security plug-in with arm trust zone.

B

um But I just wanted to hear your thoughts on uh the merits, the benefits or, and maybe any difficulties you had in uh working uh with those features.

F

So one thing I must clarify is that our use of the trust zone was. It was only for the purposes of attestation uh in the sense of testing the normal world. Where you know ross and everything runs, we didn't build anything. uh We didn't incorporate any ros components inside the secure world. If that's what you are you're uh you're asking.

B

Yeah, I I remember that from the paper I was just like yeah more in.

C

A

Yeah the main problem with uh nvidia's adjacent tx2 is lack of the documentation and also the forms of form support is not that good.

A

So, uh in the beginning, like it's a bit of a struggle to uh to know like what exactly is happening like uh how does the normal world communicate with the secure world once uh these things are uh like unknown, then it becomes easy, but it's a little bit of struggle to get started with the dress zone. Part.

B

To what extent is the is the other station? um It's it's verifying that this is my file system. This is the processes that have been launched from the executables on this file system. Is there any is there? What else do you end up having to verify or do.

F

B

F

Anything static is what we are doing right now, which is you know in some sense it's an overkill for transom uh I mean we are doing standard tpm like attestation right now, but we want to make richer use of the truss zone.

F

So, if you're familiar with samsung knox the technology they use to protect the normal world at runtime by shepherding sensitive operations through the secure world, we were trying to mimic that for a while outside of this project, of course, um but you know that's not described in this paper this paper, uh it was mostly just the priveros side on the normal world with bare bones attestation, just to show that you know without I mean in the sense that, without a root of trust, a hardware root of trust, you can't really trust anything on the drone.

F

So we took the bare minimum route of trust and date, attestations which are tpm-like. Of course, you know that has known problems. Also, time of check to time of use, you might measure everything and then the adversary may replace the software stack of the drone. So as it stands as described in the paper, we are vulnerable to that, but samsung knocks like uh enhancements, which is basically a bunch of current enhancements, would allow you to prevent that, to a larger extent that we currently do so even samsung knox is not perfect, though.

F

um Yeah, so I don't know if that, if that explanation made sense, but the nox technology is also described in another paper from 2014, it's called hypervision across worlds, so they describe how kernel modifications can extend to beyond just spot checks that are obtained from attestations. You can extend it to kernel lifetime integrity, module or certain characters.

B

Can you repeat the paper right across something across the world yeah.

F

It was called hypervision across worlds that describes the basic technology that goes into samsung knox, which is what is found in all our phones now, um so it's called hypervision across words, and then there was something else in the title. I think real-time kernel integrity, protection or something like that, uh but it was from a team from samsung at ccs 2014.

F

If memory serves.

B

All right, thank you.

B

Anyone else have any uh general questions or topics they want to.

B

B

Well, um it's a little past the hour, so I don't want to keep people for too long but uh um feel free to contact the speakers. uh If you have follow-up questions, um I wanna thanks the speakers for coming and giving this awesome talk and then um you guys are also presenting um so thursday or friday at the uh cyber security robotics conference.

F

uh No no, no. This was that uh our work was presented at ccs in november.

B

The original publication, I'm thinking of uh the announcement that I think uh dieber put out on this course, I'm sorry. Let me go get that.

F

No, not to my knowledge, at least so.

B

All right- hey- maybe I missed this- remembering um you know, drop the link uh you will. Certainly uh everyone here is attending will probably be interested in this as well. um It's happening um uh later this week.

B

F

A

All right, okay,.

C

Thanks thanks, I appreciate roughly for setting this up and and thanks to the members for presenting um again like ruffin said. I think it was really interesting and valuable as well for us um are you able to share the slides um that you presented, so I can upload them for the group.

F

Yeah, let me just share a link to the paper and to this, uh to a shorter version of the slides. Rakesh can post everything, uh so we also have like a demo video and all that uh they're all at this link right here. I just posted it on the chat window.

C

Great, thank you thank you and then often, if you have the video afterwards, if you shoot me the link I'll drop it in the next for today,.

B

Will do thank you I'll also update the uh op post. People can find it as well.

B

All right, thanks for coming guys.

F

Yeah, thank you and uh any feedback. We are more than happy to hear from the community. Please feel free to just uh write us email. All our contacts are in the paper. Thank you. So much for inviting us.

D

C

Thank you for the presentation.

C

Bye-Bye thank you. Bye.