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

1. Secure Drone-to-X
Communication:
Applicability of IEEE 1609.2
Jonathan Petit, Drew Van Duren

2. IEEE1609.2
authenticated message
Broadcast or unicast communication 2

3. Outline
 Drone Communications Overview
 Needs
 Threats
 IEEE 1609.2 Security Model
 Experimental Demo
3

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

9. What’s missing?
9

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

13. Overview of IEEE1609.2
Security in Connected Vehicle
Systems

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

24. 1609.2 for UAS
and Proof-of-Concept

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