Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Secure Drone-to-X Communication - AUVSI XPONENTIAL 2018


Published on

The presentation "Secure Drone-to-X Communication: Applicability of IEEE 1609.2" from OnBoard Security's Drew Van Duren and Jonathan Petit explores using Aerolink V2X security libraries with Unmanned Aerial Vehicles.

Published in: Technology
  • Login to see the comments

  • Be the first to like this

Secure Drone-to-X Communication - AUVSI XPONENTIAL 2018

  1. 1. Secure Drone-to-X Communication: Applicability of IEEE 1609.2 Jonathan Petit, Drew Van Duren
  2. 2. IEEE1609.2 authenticated message Broadcast or unicast communication 2
  3. 3. Outline  Drone Communications Overview  Needs  Threats  IEEE 1609.2 Security Model  Experimental Demo 3
  4. 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. 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. 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. 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. 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. 9. What’s missing? 9
  10. 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. 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. 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. 13. Overview of IEEE1609.2 Security in Connected Vehicle Systems
  14. 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. 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. 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. 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. 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. 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. 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. 21. 1609.2 Certificate Under the Hood (adds message authorization) PSID A SSP SSP Application Identifier Service-Specific Permissions (SSP) 21
  22. 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. 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. 24. 1609.2 for UAS and Proof-of-Concept
  25. 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. 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. 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. 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. 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