This document discusses using IEEE 1609.2 security standards for drone communications. It begins by overviewing current drone communication methods, including drone-to-drone, drone-to-controller, and drone-to-network. It then discusses needs for drone identification, tracking, and secure real-time communications. The document provides an overview of the IEEE 1609.2 security model used for vehicle-to-vehicle communications. It describes implementing 1609.2 in an experimental demo to securely transmit ADS-B messages between drones to enable collision avoidance. The demo showed 1609.2 could mitigate message spoofing and manipulation threats. Overall, the document argues IEEE 1609.2 is applicable for securing drone-to-drone and
4. Drone Communications
Drone-to-Drone
– Not standardized today
Drone-to-Controller
– Proprietary
Drone-to-Network
– Various options such as Cellular
Drone-to-Backhaul (through Network)
– Traditional network security approaches
– X.509/TLS/OATH, etc.
Network
Backhaul
Services
Backhaul
Services
Backhaul /
UTM
4
5. Drone Communications: Drone to Drone
Not standardized, though standardization efforts underway
May be via network or P2P
Airborne applications will highly depend on these links
– Communicating state (traffic separation / sense-and-avoid / intent)
– Collaboration and swarming models
Some considering DSRC-type solution as well as C-V2X
(LTE/3GPP); both support network modes as well
5
6. Drone Communications: Drone to Ground Station
Proprietary or common industry protocols
Various radio modems, Link and higher-layer protocols
Examples:
– WiFi 802.11, 433MHz, 900MHz, 2.4GHz
– Mavlink protocol
– Lightbridge (DJI) for telemetry and payload comms
Under development for larger drones: CNPC link (RTCA SC-228
and NASA)
6
7. Drone Communications: Drone to Network
“Choose your Network”
Cellular / Cellular gateways
Proprietary gateways
Large role in safe/secure drone communications
Doesn’t provide end-to-end security (i.e., app-to-app, machine-to-
machine)
7
8. Drone to Services (backhaul, UTM, etc.)
Traditional network/web security approaches:
– TLS
– X.509 certificates
– Authorization and Identity
(e.g., OAuth2, OpenID Connect, etc.)
– Can provide App-to-App or App-to-Gateway security approaches
Backhaul
Services
Backhaul
Services
Backhaul /
UTM
8
10. Needs
Drone identification and tracking
– FAA ATC awareness, UTM, law enforcement
Realtime: Sense/detect-and-avoid, Collision avoidance
Secure communications for drone apps that haven’t been invented
yet (e.g., collaboration apps between ground and air vehicles)
Security, for all of the above
– Authentication, integrity, non-repudiation, and confidentiality when needed
10
11. UAS Identification & Tracking
High Level Recommendations (ID & Tracking ARC)
– Employ a solution that supports
DIRECT BROADCAST
NETWORK PUBLISHING
– Possible Tier-based Approach
Tier-0 (No Identification needed)
Tier-1 (Option to publish via network)
Tier-2 (Broadcast AND network publish ID & tracking data)
Tier-3 (Adhere to Part 91 requirements)
– Mandatory transmission of identifier, tracking info, owner, etc.
Optional transmission of other data (e.g., route or state info)
11
12. Threats
Identity and/or position spoofing
– E.g., ADS-B easily spoofed today – requires
direction-of-arrival/multi-lateration techniques
to help mitigate
Message spoofing, masquerading
Unauthorized message content (based
on sender)
Replay attacks
RF or network jamming
– will always be an issue for every medium
Eavesdropping (for private messaging)
ALL of these spell
‘DISTRUST IN DRONES’ at a
time when we want to scale
Communications and
Applications security for
manned aviation are slow in
coming
12
14. 1609.2 Purpose
1609.2 was engineered to provide security and privacy in a large,
scalable, heterogeneous community of vehicles based on the
assumption that network connectivity is NOT always present
14
15. The Connected Vehicle V2X 1609.2 Security Stack
IEEE 1609.2 is an application-to-
application security layer
independent of the transport
Engineered for use on top of DSRC,
but is self-contained and may be
used outside of it
Works at data layer, so also works
over networks, C-V2X, etc.
15
16. 1609.2 Signing
An application on a device has a
credential that it cryptographically
binds to a message
Demonstrates it originated a given message and
the message has not been altered
Credential is called a “certificate” (1609.2, NOT
X.509!)
Cryptographic binding is called “signing”
Credential is issued by a Certificate Authority or
CA
16
17. 1609.2 Signing
An application on a device has a credential
that it cryptographically binds to a message
Credentials state your permissions
– Provider Service Identifier (PSID) – “application
area” (e.g. sending BSMs, traffic management)
– Service Specific Permissions
Specific to application (PSID)
E.g. BSM: Can set LightBarInUse
E.g. SPAT/MAP: Can do one or the other
If you don’t have a police car certificate, you
can’t claim to be a police car
17
18. Using credentials (1)
How does the receiver
trust received credentials?
The CA has a certificate itself which it binds
cryptographically to the device’s certificate
The receiver knows the CA certificate
– Checks that the CA certificate authorizes and is
bound to the device’s certificate
– Checks that the device’s certificate authorizes
and
is bound to the message
– Trusts the message!
18
19. Using credentials (2): PKI
How does the receiver
know the CA certificate?
CA certificate might be known already
If it’s new, the receiver can construct
a trust chain back to a root CA.
There’s a relatively small set of root
CAs
– These can authorize an arbitrarily large
number of intermediate and end-entity CAs
19
20. Using credentials (3): Bad actors
A device that sends false messages
should no longer be trusted
Misbehavior Detection functionality
detects false messages
An enforcement function removes the
bad device’s privileges
– Either its credentials are “revoked” via a
Certificate Revocation List (CRL)
– Or it uses its existing credentials till they
expire (some apps may use very short-lived
ones) but then does not get any more
20
21. 1609.2 Certificate Under the Hood
(adds message authorization)
PSID A
SSP
SSP
Application
Identifier
Service-Specific
Permissions
(SSP)
21
22. Mechanisms in 1609.2
Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I)
message security
– Authentication
– Integrity
– Replay Protection (timing and message equivalency consistency checks)
– Confidentiality – Optional unicast encryption via recipient public key (ECIES)
– Geographic consistency
Certificates can be constrained to be trusted only in a designated Geographic
area
Message recipients can validate that the message sender was authorized to
communicate a given message ‘in that area’
– Fine-grained Permissions (Service Specific Permissions – SSP)
22
23. 1609.2 and its Security “Profiles”
Application-specific, even if common data dictionary used
Dictated by application specifier
Set or constrain 1609.2 sender/receiver security behavior
Dictates uses, consistency and relevance checking of of 1609.2 credential
attributes against message contents signed by that credential
– PSID (application ID)
– SSP (Security Specific Permissions)
– Permitted Geographic Region
– Start validity time
– Expiry time
– Trust chain
23
25. Uses for Unmanned Aircraft
Security model independent of underlying transport(s)
Drones may be on networks….or not
Able to secure messages/data in transit and at rest
Small credential (~1/2 size of X.509) – nice for bandwidth-
constrained environments
Geotemporal authorizations – static or role-based authorization
capability already built right into this credential
– Note: some authorizations are permissions ‘to ask for permission’ – this is
important in airspace operations!
25
26. Proof of Concept
Wanted to demonstrate utility of 1609.2 in an aviation-centric
message
Partnered with esteemed academic institution, Johns Hopkins
University
Collaborated and selected ADS-B (Automated Dependent
Surveillance Broadcast)
– The ‘identity and location’ beacon for aircraft today
– Critical part of NextGen
– Today, this message is completely insecure (no source authentication, easy to
spoof)
– Only some spoofing mitigations are feasible using RF techniques (i.e., multi-
lateration)
26
27. Proof of Concept
Test collision avoidance
scenarios in insecure and
secure (w/1609.2) modes
Demonstrate aircraft response to
spoofed or corrupted message
vs. legit one
Test Cases
1. Digital signing disabled on both the sender and the receiver
2. Digital signing enabled on the receiver but not the sender
3. Sending a malformed message from the sender and verifying it on the receiver
4. Sending a stored message from the past (more than 600 seconds old)
5. Sending a fake message from future by changing system time
6. Sending a message with a modified payload
7. Digital signing enabled on the sender and the receiver 27
28. Conclusion
IEEE1609.2 can be used for secure remote identification and
tracking
Leverage existing infrastructure (PKI) developed for ground vehicles
Proof-of-Concept showed its ease of integration and how 1609.2
mitigated message replay, modification, forging, and MITM attacks
More detail in our paper!
28
29. Thank you!!
Dr. Seth Nielson
Purushottam A. Kulkarni
Ritvik Sachdev
Praveen Malhan
Experiments
(Johns Hopkins University
Information Security Institute)
Drew Van Duren
Dr. Jonathan Petit
Project Consulting & Support
(OnBoard Security, Inc. )
29
Notas del editor
In this talk we are presenting you how Drone-to-X communication can be authenticated via leveraging the technology developed for ground vehicles. This technology has been tested on real drones.