This is the first working prototype of DRIP the Drone Remote ID Protocol, which will be used to identify and track drones while they fly.
Hi, I'm Aaron Parecki.
Right now is a very interesting time for Remote ID.
The FAA created this rule a few years ago, which requires that all drones that need to be registered will also need to use remote ID.
Every drone will have to broadcast its location as well as the location of the operator.
The only exception to the rule is drones that don't need to be registered, which means drones that are smaller than 250 grams that are flown recreationally.
So why is this such an important time in the lifecycle of remote ID?
Well, the clock is ticking.
The FAA regulation says that any drones manufactured after September 2022 have to be manufactured with remote ID.
that is less than two months away.
But the even more critical deadline for you is September 2023, which is when all drones have to actually have remote ID turned on.
What this means for you is that this is basically the worst possible time to buy a drone right now.
There aren't any drones with remote ID right now because the remote ID protocol was actually finalized only in July.
And a year and two months from now, you won't be able to fly your drone unless it has remote ID.
So that means if you're buying a drone now, you're crossing your fingers that the manufacturer can ship support for it in a firmware update, or you'll be able to buy a
remote ID module to physically attach to the drone as well.
So drone manufacturers have to start building their drones with Remote ID capabilities starting this September.
The weird part is the FAA didn't actually specify how to do this.
The FAA defined the information that they want to include in the broadcast, but not actually how to do it.
The standards organization ASTM, which are responsible for a whole bunch of different standards, usually involving materials, physical materials, including things like defining
the threads on screws.
So they stepped up to develop a standard that meets the FAA's requirements.
But they left out a few important details and a few pretty critical safety features.
Plus, that document was actually only finalized a few weeks ago.
So if a drone manufacturer took a look at that document and used that to build remote ID into a drone, basically what they would end up with is broadcasting some sort of
identifier, probably the serial number of the drone and the location of the drone and the location of the transmitter.
This has some pretty obvious security and privacy concerns.
The FAA rule specifically says that these messages cannot be encrypted and that's by design so that they can be received by anybody's phones.
However, if the drone is broadcasting its serial number or really any persistent identifier, then it would be very easy for anybody to read those messages and find out all
the different places that you, the individual, are flying, this one particular drone.
And of course, there's the security issue, which is that really anybody could capture and replay or just craft their own messages using arbitrary serial numbers.
That's not super great either.
So we're going to look at the solution that is being worked on for this right now.
And to do that, we're going to take a little trip to Philadelphia.
This is the IETF 114 meeting in Philadelphia.
This event is a meeting of a bunch of different standards groups, and it's where a lot of the invisible technology that runs the Internet gets created.
One of the groups here, known as DRIP, is working on the protocol that will be used by drones to meet the remote ID requirements set up by the FAA.
I sat down with the folks in the DRIP working group to try to get an understanding of exactly what they're doing and how remote ID will actually work.
One of the main goals of the DRIP working group is to be able to follow the remote ID rules while also maintaining the privacy of the person flying the drone.
This is really important because otherwise there would be a bunch of ways to abuse the system.
So what is the alternative that you came up with that avoids those issues?
ADAM: So the alternative that we started fitting into was the single use session ID, which is basically an identifier that is just ephemeral.
It is given at one particular flight or one particular operation.
AARON: So only the session ID is broadcast over there, not the drone identifier.
ADAM: Correct. So the drone identifier, which would be the serial number, is not broadcast over the air.
Just the session ID.
But in DRIP, we also mandate in our standards that authentication be broadcast as well.
AARON: Okay. So somebody on the ground with a phone can be receiving these broadcasts from the nearby drones over the air, not over the Internet.
ADAM: Correct.
AARON: Yes. And that's only going to contain what exactly.
ADAM: So that will only contain the single use session ID, the location and velocity of the aircraft, the location of the pilot.
And then finally, drip authentication, which is designed to help authenticate all of those detached or independent messages.
AARON: So the purpose of this is to be able to tell where the drone is and where the operator of the drone is, but not to be able to identify who it is or persistently
identify the drone.
ADAM: Exactly. Exactly.
AARON: But some people obviously do need to know who is flying the drone and the serial number of the drone in flight.
ADAM: So who would need to know who's flying is law enforcement officials on ground and who would want to know the serial number of the aircraft is the FAA.
AARON: So there is a way for them to get that information from the broadcast messages?
ADAM: Not directly. So the broadcast messages would send them the lookup key to then go into databases to find that information over the Internet.
AARON: Okay. So it is a two part system.
There's the over-the-air broadcast and then there's an Internet based system to look up more like the registration information, correct?
ADAM: Exactly.
AARON: So another problem with the
bare minimum requirements of the FAA published is that authentication is not required as part of that.
Right. So and that was what the PC wanted to fill in with this.
STU: Yes. I mean, I could put up an aircraft and it could be going all day long.
"I'm Adams drone. I'm Adams drone." And the problem there is a truly malicious operator can masquerade as someone who is
non-threatening, causing them to effectively fly below the radar of anybody who's defending, I don't know, the Super Bowl or the White House and also would allow them to
frame innocent parties.
We don't want that.
AARON: You're trying to use authentication so that every drone in the sky can be transmitting these authenticated messages so that it can all be trusted?
STU: Everyone that the FAA rule applies to in the United States or that corresponding EU directives apply to in the EU.
AARON: Before the meetings this week, there was a hackathon.
Yep. That was building a prototype of two different devices using the drip protocol.
Right?
ADAM: This was the first time at the hackathon ever where we had basically a full end to end system stood up, from
the aircraft not having a session ID, generating one, registering it, then flying with it and broadcasting it, an observer
device, picking it up, decoding it, and then actually performing that query and getting data back.
So that was the first time that full end to end system had been stood up in some way with more than one party.
AARON: And so what are we seeing on the phone?
ADAM: So what you were seeing on the phone at the hackathon was the broadcast coming in and being shown as what we would call a detection of that single aircraft,
displaying all the information that came over broadcast, which was in clear text.
AARON: So why are hackathons important part of the process of building these standards?
ADAM: So there's an old mantra in IETF, "rough consensus and running code", and we strongly believe that the hackathon enables this
because we need the ability to put something together and test to make sure that the standards we're writing actually line up.
At the hackathon, we uncovered some shortcomings in our registry architecture, which we now have plans to rectify in the standards.
Without that hackathon that never would have happened.
We might have put out a registry RFC.
Nobody would have been able to interoperate with each other.
So this was a huge milestone for us to be able to do that.
AARON: It is July right now in the IETF meeting.
The next IETF meeting is in November in London.
The deadline is in September, right in the middle.
What do you see happening between now and September and between September and November?
STU: Well, the first thing - I'll preface the answer with is that we're already seriously late, because the only way that this can be done cost effectively is with an application
specific integrated circuit an ASIC.
And an ASIC, even if you've built them before, takes you six months at a minimum to spend an $1,000,000.
And of course, you get it wrong the first time.
So now it's another six months and another million dollars for the second spin, and then it's going to be another six months to get that ASIC on a board and get that board into
the aircraft that you're manufacturing.
So this needed to be done 18 months before this September, and here we are in late July.
So the manufacturers are really between a rock and a hard place.
Any aircraft that is manufactured after, I don't know, September 15th or something like that of this year, either in the United States or for sale in the United States is
supposed to be equipped. So what do we need to do between now and then?
We need some prototyping of a complete DRIP ASTM ICAO system to prove that the whole system works end to end
so that people can have some confidence in starting to roll it out.
AARON: Well, in that case, I will see you in November in London.
Cross your fingers everything goes smoothly between now and then.
STU: Thank you.
AARON: All right. Thanks. It's super exciting to see this stuff come together, and it's really interesting to be able to watch it at this level as it's being built.
If you're interested in learning more about remote ID, either what it means for you as a drone operator or the technical details of how this actually works, I will leave links to
everything down in the description below.
If you're actually interested in building systems to implement various parts of the remote ID protocol, I'll leave links to the DRIP working group where you can read all of
their documents and get involved in those discussions.
I had a great time meeting with Adam and Stu, so let's all give them a big thanks for taking the time to chat with me today.
And with any luck, I'll be back at the next IETF meeting in London in November and we will hear from them again about how it's going.
That will be two months after manufacturers will need to be implementing remote ID in drones.
So we will get an update then and see how it's going.
So that's it for today.
Give this video a thumbs up if you enjoyed it.
And I will see you in the next one.