SlideShare a Scribd company logo

Secure Drone-to-X Communication - AUVSI XPONENTIAL 2018

•Download as PPTX, PDF•
•
OnBoard Security, Inc. - a Qualcomm Company
OnBoard Security, Inc. - a Qualcomm Company

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

Related slideshows

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

More Related Content

Secure Drone-to-X Communication - AUVSI XPONENTIAL 2018

  • 1. Secure Drone-to-X Communication: Applicability of IEEE 1609.2 Jonathan Petit, Drew Van Duren
  • 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
  • 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

Editor's Notes

  1. 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.