Patent Publication Number: US-2023139748-A1

Title: Integrated secure device manager systems and methods for cyber-physical vehicles

Description:
CROSS REFERENCES 
     This application is a continuation of U.S. application Ser. No. 16/560,865, filed Sep. 4, 2019, for INTEGRATED SECURE DEVICE MANAGER SYSTEMS AND METHODS FOR CYBER-PHYSICAL VEHICLES, which in turn claims the benefit of U.S. Provisional Application No. 62/727,455, filed Sep. 5, 2018, entitled INTEGRATED SECURE DEVICE MANAGER SYSTEMS AND METHODS, both of which are incorporated in their entirety herein by reference. 
     This application relates to U.S. application Ser. No. 16/565,339, filed Sep. 9, 2019, now U.S. Pat. No. 11,134,380, which is a continuation of U.S. application Ser. No. 15/729,550, filed Oct. 10, 2017, now U.S. Pat. No. 11,064,363, which claims the benefit of U.S. Provisional Application No. 62/406,834, filed Oct. 11, 2016, all of which are incorporated in their entirety herein by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates generally to vehicle management, and more specifically to cyber-physical vehicle management. 
     2. Discussion of the Related Art 
     A cyber-physical vehicle (CPV) is a vehicle that operates either autonomously or via remote control. There are many varieties of and uses for unmanned CPV systems (e.g. drones). From personal use (e.g. hobbyists), to professional use (e.g. photography, product delivery, etc.), to scientific research, to law enforcement (e.g. use in unsafe situations, surveillance, and patrol), to their use in military operations. Decreasing cost and rapid improvements in technology continue to open up new and exciting applications. However, as with many rapidly developing technologies, there have been undesirable side effects of the growth in the use CPVs. For example, the use of personal drones may interfere with law enforcement or fire safety operations. Drones may also contribute to violations of privacy, or may cause safety hazards when operated by untrained or reckless operators. Regulation is being considered to provide guidance on the safe and authorized use of autonomous or semi-autonomous cyber-physical systems such as drones. However, limitations in technology, security, and legal precedence hinders the development of a legal framework for enforcing the laws and regulations that are in place or that are being proposed. 
     Similar licensing and registration regulations are normative in the ownership and operation of nearly all vehicles, including motorcycles, automobiles, boats, and airplanes. Enforcement of these regulations on these types of vehicles is made possible due to the cooperation of manufacturers and retailers, the traceability of their sale, their operators typically being physically near or in the vehicle during operation, and the physical constraints on where and when they can operate (e.g. few cars can drive on the ocean, planes may take off and land at an airport). Drones, however, do not share these same qualities, making enforcement of any regulations extremely challenging. 
     The strong binding of a licensed operator to a registered drone is also of importance. Without such binding, the takeover and theft of a drone becomes possible. However, this binding needs to be balanced with the need for a lawful takeover of a drone should it be deemed necessary and authorized (e.g. if a drone is behaving illegally). 
     Naive or voluntary solutions to licensing the ownership and operation of drones may not be sufficient for real-world situations. For example, circumstances may arise in which an operator may wish to forge a credential, impersonate another operator, or broadcast deceptive data. Similarly, some CPVs may encroach on geographically restricted areas, which may interfere with the operations of law enforcement, emergency response, or other authorized operations. 
     SUMMARY 
     Several embodiments of the invention advantageously address the needs above as well as other needs by providing a method for determining authorization of an Integrated Secure Device Manager (ISDM) Module belonging to an ISDM system, wherein the ISDM Module is mechanically coupled to and associated with a Cyber-Physical Vehicle (CPV), comprising the steps of: broadcasting, by the Module, of a Module message including a current time and a Module token associated with the Module and including a Module public key and a Module ID, wherein the Module message is signed under a Module private key; receiving of the Module broadcast by an ISDM device of the ISDM system; determining, by the ISDM device, whether the signature of the Module message is valid; upon determining that the signature is invalid, identifying the Module as unauthorized; upon determining that the signature is valid, extracting by the ISDM device of the Module token from the Module message; upon extracting of the Module token, performing by the ISDM device of at least one authorization test, whereby the Module is identified as authorized if each of the at least one authorization test is passed. 
     In another embodiment, the invention can be characterized as an Integrated Secure Device Manager (ISDM) system, comprising: a Cyber-Physical Vehicle (CPV); an Integrated Secure Device Manager (ISDM) Module belonging to the ISDM system, wherein the ISDM Module is mechanically coupled to and associated with the CPV; and at least one ISDM device belonging to the ISDM system and configured to receive ISDM broadcasts, wherein the ISDM system is configured to perform the steps of: broadcasting, by the Module, of a Module message including a current time and a Module token associated with the Module and including a Module public key and a Module ID, wherein the Module message is signed under a Module private key; receiving of the Module broadcast by the ISDM device; determining, by the ISDM device, whether the signature of the Module message is valid; upon determining that the signature is invalid, identifying the Module as unauthorized; upon determining that the signature is valid, extracting by the ISDM device of the Module token from the Module message; and upon extracting of the Module token, performing by the ISDM device of at least one authorization test, whereby the Module is identified as authorized if each of the at least one authorization test is passed. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIGS.  1  through  2    show examples of a Cyber-Physical Vehicle (CPV) management system that supports authentication, authorization and secure communication according to aspects of the present disclosure. 
         FIG.  3    shows an example of a CPV that supports authentication, authorization and secure communication according to aspects of the present disclosure. 
         FIG.  4    shows an example of a drone management Authority (DMA) that supports authentication, authorization and secure communication according to aspects of the present disclosure. 
         FIG.  5    shows an example of an authoritative drone command (ADC) system that supports authentication, authorization and secure communication according to aspects of the present disclosure. 
         FIG.  6    shows an example of a relay Node that supports authentication, authorization and secure communication according to aspects of the present disclosure. 
         FIG.  7    shows an example of a polite drone identification (PDI) device that supports authentication, authorization and secure communication according to aspects of the present disclosure. 
         FIGS.  8  through  23    show examples of a process for authentication, authorization and secure communication according to aspects of the present disclosure. 
         FIG.  24    shows an example of a CPV detection and intervention system that supports identification, detection, capture, seizure, and immobilization of CPV systems according to aspects of the present disclosure. 
         FIG.  25    shows an example of a CPV detector that supports identification, detection, capture, seizure, and immobilization of CPV systems according to aspects of the present disclosure. 
         FIGS.  26  through  27    show examples of a process for identification, detection, capture, seizure, and immobilization of CPV systems according to aspects of the present disclosure. 
         FIG.  28    shows an example of a process for identification, detection, capture, seizure, and immobilization of CPV systems according to aspects of the present disclosure. 
         FIG.  29    shows an example of a CPV detection phase according to aspects of the present disclosure. 
         FIGS.  30  through  33    show examples of a process for identification, detection, capture, seizure, and immobilization of CPV systems according to aspects of the present disclosure. 
         FIG.  34    shows an example of a CPV seizure phase according to aspects of the present disclosure. 
         FIGS.  35  through  36    show examples of a process for identification, detection, capture, seizure, and immobilization of CPV systems according to aspects of the present disclosure. 
         FIG.  37    shows an example of a collision avoidance system according to aspects of the present disclosure. 
         FIG.  38    shows an example of a system for CPV management according to aspects of the present disclosure. 
         FIG.  39    shows an example of a process for deployment initialization according to aspects of the present disclosure. 
         FIG.  40    shows an example of a process for new Module initialization according to aspects of the present disclosure. 
         FIG.  41    shows an example of a process for friend of foe Node identification according to aspects of the present disclosure. 
         FIG.  42    shows an example of a process for friend of foe Module identification according to aspects of the present disclosure. 
         FIG.  43    shows an example of a system for CPV management according to aspects of the present disclosure. 
         FIG.  44    shows an example of a process for CPV management according to aspects of the present disclosure. 
         FIG.  45    shows an example of a process for Nodes to store a token and Authority token to be stored as trusted according to aspects of the present disclosure. 
         FIG.  46    shows an example of a process for registering Module ID and public key with the Authority according to aspects of the present disclosure. 
         FIG.  47    shows an example of a process for flight readiness according to aspects of the present disclosure. 
         FIG.  48    shows an example of a process to determine if the Module broadcast confirms to the Authority reply according to aspects of the present disclosure. 
         FIG.  49    shows an example of a process to identify a UAV according to aspects of the present disclosure. 
         FIG.  50    shows an example of a system for CPV management according to aspects of the present disclosure. 
         FIGS.  51 A and  51 B  shows an example of a process for CPV management with a public observer according to aspects of the present disclosure. 
         FIG.  52    shows an example of a process for Nodes to store a token and Authority token to be stored as trusted according to aspects of the present disclosure. 
         FIG.  53    shows an example of a process a Module ready for use according to aspects of the present disclosure. 
         FIG.  54    shows an example of a process for token to be issued and stored to an operator according to aspects of the present disclosure. 
         FIGS.  55  through  56    show examples of a process to determine if token data is valid and drone is compliant according to aspects of the present disclosure. 
         FIG.  57    shows an example of a process to update a Module token according to aspects of the present disclosure. 
         FIG.  58    shows an example of a system for CPV management according to aspects of the present disclosure. 
         FIGS.  59 A and  59 B  shows an example of a process for CPV management with an updated Module token according to aspects of the present disclosure. 
         FIG.  60    shows an example of a process for deployment readiness according to aspects of the present disclosure. 
         FIG.  61    shows an example of a process for deploying a new drone or Module according to aspects of the present disclosure. 
         FIG.  62    shows an example of a process to register a drone or Module according to aspects of the present disclosure. 
         FIG.  63    shows an example of a process for verifying a beacon according to aspects of the present disclosure. 
         FIGS.  64  through  65    show examples of a CPV system according to aspects of the present disclosure. 
         FIG.  66    shows an example of a process for performing Real-Time Kinematic (RTK) positioning according to aspects of the present disclosure. 
         FIGS.  67  through  84    show examples of a process for cyber-physical vehicle management according to aspects of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     The following description is not to be taken in a limiting sense but is made merely for the purpose of describing the general principles of exemplary embodiments. 
     The scope of the invention should be determined with reference to the claims. 
     Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment. 
     Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software Modules, user selections, network transactions, database queries, database structures, hardware Modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention. 
     The following description is not to be taken in a limiting sense, but is made merely for the purpose of describing the general principles of exemplary embodiments. The scope of the invention should be determined with reference to the claims. 
     Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment. 
     Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software Modules, user selections, network transactions, database queries, database structures, hardware Modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention. 
     Cyber-Physical Management System 
     As previously disclosed in related U.S. patent application Ser. No. 15/729,550, filed Oct. 10, 2017, a cyber-physical vehicle management system may include algorithms, protocols, and a distributed system for supporting public key infrastructure for, and providing novel utility to, the domain of unmanned vehicles, robots, manned vehicles (including airborne vehicles, automotive vehicles, personal mobility devices, and maritime vessels), both autonomous, semi-autonomous, and human-controlled (henceforth collectively known as “drone(s)” or “CPV”(s)). Generally, public-key infrastructure (PKI) is understood to define a set of identities, policies/procedures, and technologies, needed to manage (i.e. create, store, revoke, and distribute) digital certificates useful in encryption, integrity, authentication, and digital signature schemes (such as, but not limited to, Rivest-Shamir-Adleman (RSA), digital signature algorithm (DSA), advanced encryption standard (AES), and data encryption standard (DES)). A cyber-physical vehicle management system may leverage the concepts of PKI to provide a system for the registration, identification, authorization, control, and other functionality of CPVs (as defined above). 
     At the core of the system is a drone/CPV management Authority (DMA), which is a collection of algorithms, protocols, and systems—as well as the business entity and practices that uses the same—to provide a licensing scheme for CPVs. The DMA is an Authority for managing CPV operator licenses (DOLs), which contain identifying information about a CPV operator and the CPV itself. DOLs are useful for enforcing legal restrictions on operation and ensuring safe movement and operation of CPVs. In one example, a cyber-physical vehicle management system may be applied to an unmanned aerial system traffic management (UTM) system. However, a cyber-physical vehicle management system may also apply to any cyber-physical vehicular system (which may be generically referred to as “CPVs”) such as high-value inventory management by robots in a warehouse. 
     A cyber-physical vehicle management system may enable cryptographically-assured confidentiality and authentic communication channels. To this end, the cyber-physical vehicle management system may utilize cryptographic primitives optimized for constrained devices in constrained environments such as small size, low-power, unguaranteed connectivity, bandwidth-constrained, or low-computational settings. This may prevent CPVs from being eavesdropped, disrupted, or impersonated. 
     Thus, the cyber-physical vehicle management system may provide services including: legitimate authentication and authorization of CPV movement plans (such as flight plans); application of temporary, permanent, or dynamic geofences; authentication of CPV Nodes that seek to communicate with a CPV or other CPV Nodes; and cryptographically binding together CPV Nodes, CPV, and movement plans. 
     As known in the art, geofences are designations in space which can be displayed on a visual map. They can either be fixed or dynamic in position and either two dimensional or three dimensional in shape. 
     Minimally a geofence requires at least a longitude and latitude pair of coordinates and a radius to create a circle. If three or more coordinates are entered, then a polygonal is formed. Additional coordinates can be used to create more complex shapes. At least one altitude can be used to create a defined three dimensional geofence. Otherwise, the geofence is assumed to extend from the ground up into space. 
     Once the shape (either two or three dimensional) is designated for the geofence, then the positioning of the geofence can be determined. If fixed, then the geofence maintains position without relativity to any points. If dynamic, then the geofence coordinates adjust relative to a single point which could be the location of a mobile sensor. The single point may or may not be within the geofence. 
     Geofences can have various levels of attributes, such as limitations and permissions required. CPV or CPV behavior that does not abide by these attributes can be managed in a preset manner that is determined by the setting of the geofences. For example, only CPV that are under a certain weight might be able to enter a set geofence. Then if a CPV exceeds this weight, then based on set levels of weight that the CPV is will determine the response how to manage it. An example of CPV behavior is if the CPV is flying too fast in a given geofence, then there will be an appropriate response to this. An example of an attribute for the geofence can also be based on timing such as a geofence that only allows CPV that are rated to operate at night to carry out their movement plans. Response can be passive (e.g. logging) or active (e.g. takeover). 
     Cyber-physical management techniques may be extensible to larger systems for enforcing the safe and authorized use of autonomous or semi-autonomous cyber-physical systems. This includes unforgeable licensing of vehicles and operators, enforcement of pre-registered flight plans, and, when appropriate, the lawful interception and identification of the CPV. 
     In some cases, implementation of a cyber-physical vehicle management system may include updating PKI solutions (which include identity attestation, authentication, and revocation) with cryptographic primitives and protocols designed specifically for a distributed and computationally-constrained CPV environment. A cyber-physical vehicle management system may be applicable to a variety of CPV systems including aerial drones, autonomous cars, ships, trains, and other suitable types of transport. 
     Detection/Identification/Capture/Seizure 
     In some cases, it may be appropriate to gather identification information from a CPV to enforce laws or regulations that may have been violated. For example, local law enforcement may issue citations for violations of law, and if a CPV was taken into custody, it must be legally impounded or taken as evidence. There is a therefore a need for uniquely identifying CPV information (beyond immediate capture or rerouting the threat), which can be used to prove a particular CPV physically recovered at a crime scene was the intruder CPV, i.e. the CPV that entered into an area that it shouldn&#39;t or did something that it shouldn&#39;t have done. 
     In some cases, a CPV may be removed by firing upon it with a weapon or jamming radio control channels. Firing a weapon may create safety risks. For example, debris from a projectile or CPV hit could be dangerous to those on the ground. Batteries carried by CPVs can be highly flammable and even explosive in such situations. Jamming of control channels can affect other radio gear, including gear used by the first responders or support aircraft. Jamming the control channels of an unauthorized CPV may have unpredictable effects on the CPV&#39;s behavior. This may increase the risk of collisions in the air or damages to those on the ground. 
     A cyber-physical detection and intervention system may provide a low risk, effective, convenient, and field ready solution to the problem of CPVs intruding into airspace controlled by first responders. The system may also be applicable in other circumstances. A cyber-physical detection and intervention system may offer authorized users an effective, portable, self-contained device that will detect all remote control devices in range; identify them as far as possible for determination of threat status; capture the threatening devices&#39; control channels from the original controllers (with or without their knowledge); and then seize control of the intruders&#39; physical control systems and to visually choose a safe location to send them to and inevitably deactivate them. 
     Thus, a cyber-physical detection and intervention system may provide for: effective detection of all remote controlled devices in the immediate area and within RF range; identification of CPVs including deriving, recording, and displaying all available information on the individual device under CPV detection and intervention system surveillance; identifying a “whitelist” of devices that are authorized to be part of the mission, eliminating them from “threat” status to prevent CPV detection and intervention system from mistakenly interfering with them; capture of intruder devices that are a threat, taking full and exclusive control of a device from its original controller; ability to choose a location where the device would not be a threat, a target location for its destination and deactivation; use of a detachable, standalone subsystem that gives precise position of an object that is merely visually spotted using an optical scope; command and control capability for the threat device&#39;s movements in order to direct it to physically move: to the target location for deactivation, to immediately land or otherwise deactivate it in place, to return it to its own point of origination; ability to ensure that the threat does not cause further risks (such as collisions with other objects) when it travels from the high risk area to the target location for deactivation; potential for physical seizure by authorities for further action or prosecution; “anti-tamper self-termination” interlock to ensure the integrity of the system itself: unauthorized tampering with the enclosure results in memory erasure; and methods to perform RF analysis on a raw data stream from a remote controlled device and determine the manufacturer&#39;s protocol for encoding and decoding command, control and other telemetry. 
       FIG.  1    shows a diagram  100  of a cyber-physical vehicle management system that supports authentication, authorization and secure communication in accordance with aspects of the present disclosure. Diagram  100  may include one or more cyber-physical vehicles (CPVs)  105 , CPV operator  110 , drone management Authority (DMA)  115 , authoritative drone command (ADC) device  120 , ADC user  125 , ADC agency  130 , relay Node  135 , licensing agency  140 , internet  145 , interested groups  150 , and local sensing data  155 . 
     A cyber-physical vehicle management system may allow for highly reliable and authentic identity management of cyber-physical systems, unforgeable legal interception devices, and robust relay Nodes  135 . A cyber-physical vehicle management system may be applied to a system of unmanned aerial vehicles (UAVs) (i.e., an unmanned aerial system traffic management (UTM) system), but it could equally be applied to other autonomous vehicles, automated manufacturing, and other cyber-physical applications. A cyber-physical vehicle management system may provide for human and object bi-directional authenticity verification. 
     A CPV  105  may be a device such as a UAV or an autonomous car. The CPV  105  may contain computing, sensing, GPS, movement, and communications subsystems. A CPV  105  may also interact with other CPVs  105 . A cyber-physical vehicle management system may enable an identity management scheme for authenticated communications between CPVs  105  and other devices. In some cases, a CPV  105  may be an electro-mechanical device intended to move through space under partially or fully automated control. 
     In some cases, a CPV  105  may be a component of a cyber-physical vehicle system (CPVS). A CPVS may include a CPV  105  and a cyber-physical vehicle Node (CPVN) (secondary cyber-physical systems and subsystems that support the functionality and application of the CPV). For example, CPVN might be a weather station one-way communicating to the CPV  105 , it may be a remote controller operated by a human that is providing one-way communication for control, or it may be a two-way communication such as the case of an aerial CPV  105  coordinating its flight plan with an automated ground station. 
     A CPV  105  may communicate with radio signals to other systems such as other CPVs  105  (e.g., in the case of CPV swarms). This communication could be to coordinate with each other or simply as one-way communication broadcasting the CPV&#39;s existence (and possibly location and other relevant data). CPVs  105  may utilize either one-way receive radio signal communication (e.g. control), one-way send radio signal communication (e.g. data), or two-way send and receive radio signal communication. CPVs  105  may be unmanned in that they lack a human operator within the vehicle (such as drones, remote controlled cars, and bomb disposal robots), but they may have a human controlling them or receiving data from them from afar using radio signals from a CPV  105  Node (e.g. a control station, controller, computer). 
     CPVs  105  may have humans internally acting as either an operator (e.g. an autonomous car like) or as a non-operator (e.g. a sky taxi where the human is an occupant). Radio signals either going to or from the CPV  105  may be detected using a CPV Detector. A CPV detection system may be utilized to control and manage threats such as wirelessly remote-controlled devices, autonomous devices that have a telemetry and control wireless link, drones and robots. The CPV&#39;s components, such as the battery in this case, may transmit their own telemetry via a transmitter. 
     CPV  105  may forward a challenge from an authoritative command device (e.g. ADC device  505 ) to a CPV operator controller; prepare a cryptographic CPV response based on the operator response, the challenge and a CPV token stored on the CPV; and send, from the CPV to the authoritative command device (i.e. the ADC device), the CPV response and the operator response. CPV  105  may incorporate aspects of CPV  305  and  2410  as described with reference to  FIGS.  3  and  24   . In some cases, a cyber-physical vehicle management system may include of a plurality of CPVs  105 , each vehicle including a computing device having a unique identity and an operator associated with the vehicle. 
     A CPV operator  110  may control one or more aspects of CPV operation. For example, a CPV operator  110  may compare a challenge to an operator credential stored on the CPV operator controller; prepare a cryptographic operator response based on the operator credential; and return the operator response to the CPV. 
     DMA  115  may be an example of a management Authority in communication with a licensing Authority and receiving licensing information for each licensed vehicle, wherein the management Authority is configured to issue at least one cryptographic authentication token associated with each licensed vehicle and verify the at least one token issued to the vehicle prior to operation of the vehicle. DMA  115  may incorporate aspects of DMA  405  as described with reference to  FIG.  4   . 
     In some cases, the management Authority is configured to verify the identity of the relay Node  135 . 
     In order to prove its identity, a CPV has to first register its license with the DMA  115 . The DMA  115  returns a cryptographically signed drone token (CSDT), which allows for the CPV to prove its identity in the future. Once the CSDT has been received by the CPV it can be used to verify its identity. The DMA  115  can also be queried by a third-party agency with sufficient court order to verify the registration and licensing. 
     An authoritative drone command (ADC) device  120  may be an example of an authoritative command device associated with an authoritative command user  125  and an authoritative command agency  130 , wherein the authoritative drone command device  120  is configured to query and intercept licensed and unlicensed remote-controlled vehicles; send, from an authoritative command device  120  to a CPV), a challenge requesting a response from the CPV; verify the CPV response and the operator response; determine that the CPV is included in a mandated intercept definition; and intercept the CPV. ADC device  120  may incorporate aspects of ADC device  505  as described with reference to  FIG.  5   . 
     In some cases, the authoritative drone command device  120  is licensed by the licensing Authority. An ADC device  120  may be issued to authorized users, such as public safety personnel (e.g. police and firefighters) and governmental agencies. The ADC device  120  allows for lawful query and intercept of CPVs  105 . The ADC device  120  should register itself to the DMA  115  to get a valid token allowing for proof of identity. The use of this token allows the ADC to prove its Authority to CPVs  105  when it issues an interrogatory or intercept request. Properly using this proof of identity in requests makes it cryptographically unfeasible to implement and deploy an imposter ADC device  120 . This allows for CPV  105  operators to be confident that if their device is taken over it is done so legitimately. Furthermore, when a request is made the user is alerted about the identity of the ADC agency  130  empowering them to follow up on perceived unlawful actions. 
     ADC user  125  may incorporate aspects of ADC user  540  as described with reference to  FIG.  5   . ADC agency  130  may incorporate aspects of ADC agency  570  as described with reference to  FIG.  5   . 
     Relay Node  135  may be an example of a component configured for communication with the plurality of vehicles and the management Authority. Relay Node  135  may incorporate aspects of relay Node  605  as described with reference to  FIG.  6   . A relay Node may also be referred to as a Gateway. 
     A relay Node  135  may be a local or gateway communication device for other CPVs  105 . The relay Node  135  can be, among other embodiments, fixed stationary (e.g. ground station) or mobile (e.g. UAV, handheld device, or temporary ground station). The relay Node  135  establishes mutually authenticated communications with CPV  105  requesting connection. The CPV  105  is then able to request local sensing data  155  (e.g. traffic or weather data) as well as connect to the Internet  145 , if the relay Node  135  is configured for Internet connection. 
     Licensing agency  140  may be an example of a licensing Authority configured to verify the identity of each licensed vehicle and the operator associated with the vehicle, the licensing Authority further configured to license vehicles. 
     In some cases, cyber-physical vehicle management system may include or coordinate with a third-party licensing agency  140 . The licensing agency  140  can either be a government agency, such as the Federal Aviation Administration (FAA), or an independent organization, such as an independent certificate Authority. The licensing agency  140  authenticates and authorizes the CPV and CPV pilot but has no method to continually monitor and verify whether the CPV is properly licensed. A cyber-physical vehicle management system may provide two components for monitoring the license issued by the licensing agency  140 . 
       FIG.  2    shows a diagram  200  of a cyber-physical vehicle management system  205  that supports authentication, authorization and secure communication in accordance with aspects of the present disclosure. Diagram  200  represents logical sets wherein the set of cyber-physical vehicle management systems  205  may include the set of fully and semi-autonomous vehicle coordinated movement  210 . Similarly, the set of fully and semi-autonomous vehicle coordinated movement systems  210  may include a UTM  215 . The present disclosure indicates that a cyber-physical vehicle management system  205  may be applied to mode applications than the fully and semi-autonomous vehicle coordinated movement systems  210  and UTM  215  scenario described in much of the present disclosure. 
     A cyber-physical vehicle management system  205  may allow for highly reliable and authentic identity management of cyber-physical systems, unforgeable legal interception devices, and robust relay Nodes. A cyber-physical vehicle management system  205  may be applied to a system of UAVs (i.e., a UTM  215 ), but it could equally be applied to other autonomous vehicles, automated manufacturing, and other cyber-physical applications. A cyber-physical vehicle management system  205  may provide for human and object bi-directional authenticity verification. 
     Beyond the applications to UTM  215 , a cyber-physical vehicle management system  205  can be applied to a breadth of other applications. These applications include manned and unmanned un-, semi-, and fully-autonomous vehicle systems such as aquatic-, aerial-, and ground-based. Some other application examples include personal moving systems (e.g. wheelchairs and golf carts), supply chain management, and authenticated service providers. 
     A cyber-physical vehicle management system  205  may also be used to manage unmanned autonomous aquatic vehicles, both submersible and non-submersible. Defense applications include unmanned aquatic anti-pirate vehicles for high value targets. It is also just a matter of time before hobbyist boats and submersibles proliferate in numbers. Beyond hobbyist applications, it is conceivable to have scientific and industrial applications. For example, small submersibles could be used for surveying before drilling, tracking animals, or measuring currents. In the case of autonomous boats and submersibles, the proposed technology could trivially be extended to include sonar and other under-water communications. Given the slow speeds of underwater radio, the signature and encryption algorithms chosen would need to minimize communications. This is feasible due to the extensible nature of our process. The ability for an Authority to use an ADC-like device has many useful applications. For one, a military ship could be equipped with an ADC device to intercept hobbyist devices that wander too close. Similar devices could be used on oil platforms and in the protection of delicate natural resources, such as protected animal species. 
     Self-driving vehicles including passenger carrying cars, personal transportation systems, unmanned delivery vehicles, and manned (or unmanned) first responder vehicles are all on the horizon. An unmanned first-responder vehicle, could be used to patrol streets for reckless driving, speeding, and looking for suspicious behavior. Manned autonomous first-responder vehicles could also be used to allow for police having more freedom in observation. Self-driving delivery vehicles could allow for a reduction in labor and decreased delivery costs while improving the efficiency of last mile delivery. Similarly, personal moving systems could allow for small vehicles to deliver people to their desired endpoint. In all of these applications, identity may be maintained, and legal intercept allowed. 
     For example, consider a personal delivery system. If someone is able to load an explosive into the delivery vehicle and tell it to deliver to a random person, this could lead to bad scenarios. In order to avoid this, a user credential, like the one we propose, could be used to bind the identity of the loaded product. This would allow for tracking of all deliveries. This would also allow for lawful inspection by law enforcement agencies using an ADC-like device. A supply chain is another natural application of our process. Potential things to include are robots, equipment distribution, manufacturing process, automated supply chain management, and fixed or mobile warehouse robots. 
     A cyber-physical vehicle management system  205  can also be applied to authenticating a privileged or trusted service provider. For example, it may be that you are meeting with a new lawyer and want to prove their identity. In order to do this, a cyber-physical vehicle management system may verify they are both a licensed lawyer and the specific lawyer they claim to be. Likewise, verification for law enforcement officers and doctors is of immediate need. Before having to submit to your vehicle being pulled over, you can verify that the flashing lights behind you is indeed from a law enforcement officer. Hospitals can use a cyber-physical vehicle management system for bidirectional verification of credentials and required actions, such as a patient verifying the person administering medicine or performing surgery is who they say they are and the doctor or nurse verifying that the correct patient is being administered the correct medicine or having the correct operation. 
     A cyber-physical vehicle management system  205  may be applied to robots used by law enforcement and other agencies to investigate and dispose of potential explosives or other safety-threatening objects will ensure that only commands from an authorized agent are accepted by the robot. Else, the robot may accept commands from a nefarious agent which could cause the robot put the law enforcement officers in danger. Further, the data received by the authorized agents needs to be validated to ensure that a nefarious agent is not relaying false information with the intent to deceive law enforcement, and therefore potentially causing them to make an incorrect threat assessment. 
     A cyber-physical vehicle management system  205  may be applied can be used to ensure keyless entry systems are only used by authorized users at authorized times with authenticity ensured, for example, a person could allow a delivery person to open a door to leave a package ensuring only an authorized delivery person could do so and that the action is traceable to the delivery person. 
     A cyber-physical vehicle management system  205  may have a wide variety of applications where secure, authenticated, and trusted communication is desired and would enhance the user experience or security, or would allow for further innovation that requires the features that a cyber-physical vehicle management system provides. The communication can be omni- or bi-directional, i.e. purely broadcasting or creating a communication link. The scope of a cyber-physical vehicle management system extends beyond the example used for UTM into un-, semi-, and fully-autonomous vehicles and other platforms, whether manned or unmanned. The scope expands further than that into any need for secure identity management and authentication, specifically beneficial for applications that do not have constant access to the Internet or systems that need a failsafe or backup in the event that an internet connection is lost. 
     Fully and semi-autonomous vehicle coordinated movement  210  may include coordination across land, water, sky and space. The coordinated vehicles may include drones, robots, airplanes, cars, and wheelchairs. The UTM  215  may also include a system of legal entities to interrogate and seize control of unlawful CPVs. 
       FIG.  3    shows a diagram  300  of a CPV  305  that supports authentication, authorization and secure communication in accordance with aspects of the present disclosure. 
     The CPV  305  may be a device such as an unmanned aerial vehicle (UAV) or an autonomous car. The CPV includes a CPV battery  355 , a CPV processor  360 , and a GPS/telemetry Module  365 . The CPV  305  may contain computing, sensing, movement, and communications subsystems. A CPV  305  may also interact with other CPVs  305 . A cyber-physical vehicle management system may enable an identity management scheme for authenticated communications between CPVs  305  and other devices. A CPV  305  is an electro-mechanical device intended to move through space under partially or fully automated control. In some cases, the CPV  305  may be a component of the CPVS. 
     The CPVS may include the CPV  305  and a CPVN (secondary cyber-physical systems and subsystems that support the functionality and application of the CPV). For example, CPVN might be a weather station one-way communicating to the CPV  305 , it may be a remote controller operated by a human that is providing one-way communication for control, or it may be a two-way communication such as the case of an aerial CPV  305  (e.g. drone) coordinating its flight plan with an automated ground station. 
     The CPV  305  may communicate with radio signals to other systems such as other CPVs  305  (e.g., in the case of drone swarms). This communication could be to coordinate with each other or simply as one-way communication broadcasting the CPV&#39;s existence (and possibly location and other relevant data). CPVs  305  may utilize either one-way receive radio signal communication (e.g. control), one-way send radio signal communication (e.g. data), or two-way send and receive radio signal communication. CPVs  305  may be unmanned in that they lack a human operator within the vehicle (such as drones, remote controlled cars, and bomb disposal robots), but they may have a human controlling them or receiving data from them from afar using radio signals from a CPV Node (e.g. a control station, controller, computer). 
     CPVs  305  may have humans internally acting as either an operator (e.g. an autonomous car) or as a non-operator (e.g. a sky taxi where the human is an occupant). Radio signals either going to or from the CPV  305  may be detected using a CPV Detector. A CPV detection system may be utilized to control and manage threats such as wirelessly remote-controlled devices, autonomous devices that have a telemetry and control wireless link, drones and robots. The CPV&#39;s components, such as the battery  355  in this case, may transmit their own telemetry via a transmitter. 
     CPV  305  may be one of a plurality of vehicles, each vehicle including a computing device having a unique identity and an operator associated with the vehicle. The CPV  305  may forward a challenge to the CPV operator controller; prepare a cryptographic CPV response based on the operator response, the challenge and a CPV token stored on the CPV; and send, from the CPV to the authoritative command device, the CPV response and the operator response. CPV  305  may incorporate aspects of CPV  105  and  2410  as described with reference to  FIGS.  1  and  24   . In some examples, CPV  305  may include drone authentication component  310 , radio receiver  340 , radio transmitter  345 , drone database  350 , the CPV battery  355 , and the CPV processor  360 . 
     Drone authentication component  310  may verify, using a drone public key  325  and a drone token stored on a remote controlled drone, a signature on a drone token using a cryptographic signature verification algorithm; 
     verify that the drone license  320  is valid; perform a challenge and response protocol between the drone and a controller; verify that the drone operator license is valid; and exchange future cryptographic keys by the drone and the drone controller. In some examples, drone authentication component  310  may include drone attributes  315 , drone license  320 , drone public key  325 , drone private key  330 , and drone DMA token  335 . 
     Radio receiver  340  may scan a radio frequency spectrum and receive radio transmissions, wherein the radio transmissions include data sent from a vehicle or from a vehicle controller. In some cases, the data includes at least one of information about the vehicle, information about activity of the vehicle, and telemetry data. Radio receiver  340  may incorporate aspects of radio receiver  635 ,  2475 , and  2525  as described with reference to  FIGS.  6 ,  24 , and  25   . 
     In some cases, a CPV comprises a radio transmitter  345 . Radio transmitter  345  may incorporate aspects of radio transmitter  640 ,  2480 , and  2530  as described with reference to  FIGS.  6 ,  24 , and  25   . 
       FIG.  4    shows a diagram  400  of a DMA  405  (also referred to as an Authority or an Authority device) that supports authentication, authorization and secure communication in accordance with aspects of the present disclosure. In some cases, DMA  405  may be an example of an organization, which may utilize computer systems to implement the functions described herein. 
     DMA  405  may be an example of a management Authority in communication with the licensing Authority and receiving licensing information for each licensed vehicle, wherein the management Authority is configured to issue at least one cryptographic authentication token associated with each licensed vehicle and verify the at least one token issued to the vehicle prior to operation of the vehicle. DMA  405  may incorporate aspects of DMA  115  as described with reference to  FIG.  1   . In some examples, DMA  405  may include DMA authentication component  410 . In some cases, the management Authority is configured to verify the identity of the relay Node. 
     In order to prove its identity, the drone/CPV has to first register its license with the DMA  405 . The DMA  405  returns a CSDT, which allows for the drone/CPV to prove its identity in the future. Once the CSDT has been received by the drone it can be used to verify its identity. The DMA  405  can also be queried by a third-party agency with sufficient court order to verify the registration and licensing. 
     DMA authentication component  410  may receive data associated with a drone/CPV operator, the data including an operator license, a plurality of operator attributes, an operator cryptographic public key, and an operator cryptographic private key via a secure channel; determine that the operator attributes match the operator license and that no operator token has been previously issued for the operator license; generate a cryptographically signed operator token including the operator attributes, the operator license and the operator cryptographic public key; and send the operator token to a drone/CPV operator. 
     DMA authentication component  410  may also receive data associated with a drone/CPV, the data including a drone license, a plurality of drone attributes, a drone cryptographic public key, and a drone cryptographic private key via a secure channel; determine that the drone attributes match the drone license and that no drone token has been previously issued for the drone license; generate a cryptographically signed drone token including the drone attributes, drone license and the drone cryptographic public key; and send the drone token to the drone/CPV. 
     DMA authentication component  410  may also receive data associated with a controller of an authoritative command device, the data including a user license, a plurality of user attributes, a user cryptographic public key, and a user cryptographic private key via a secure channel; determine that the user attributes match the user license and that no user token has been previously issued for the user license; generate a cryptographically signed user token including the user attributes, the user license and the user cryptographic public key; and send the user token to the controller of the authoritative command device. 
     DMA authentication component  410  may also receive data associated with an authoritative command device, the data including a device license, a plurality of device attributes, a device cryptographic public key, and a device cryptographic private key via a secure channel; 
     determine that the device attributes match the device license and that no device token has been previously issued for the device license; generate a cryptographically signed device token including the device attributes, the device license and the device cryptographic public key; and send the device token to the authoritative command device. 
     DMA authentication component  410  may also receive data associated with an authoritative command agency, the data including an agency license, a plurality of agency attributes, an agency cryptographic public key, and an agency cryptographic private key via a secure channel; determine that the agency attributes match the agency license and that no agency token has been previously issued for the agency license; generate a cryptographically signed agency token including the agency attributes, the agency license and the agency cryptographic public key; and send the agency token to the authoritative command agency. In some examples, DMA authentication component  410  may include device database  415 , agency database  420 , user database  425 , DMA private keys  430 , and DMA public keys  435 . 
     In some cases, the operator cryptographic public key includes the operator license and the operator attributes. In some cases, the operator attributes include at least one of a name, an address, an expiration date, an issue date, and a unique identifier. In some cases, the drone cryptographic public key includes the drone license and drone attributes. In some cases, the drone attributes include at least one of a drone operator name, a drone operator address, and drone date of manufacturing. 
       FIG.  5    shows a diagram  500  of an ADC system that supports authentication, authorization and secure communication in accordance with aspects of the present disclosure. Diagram  500  may include ADC device  502 , ADC user  516 , and ADC agency  528 . In some cases, ADC user  516  and ADC agency  528  may utilize computer devices (e.g., personal computers, mobile devices, or servers) to implement the functions described herein. 
     ADC device  502  may be an example of an authoritative command device associated with an authoritative command user and an authoritative command agency, wherein the authoritative command device is configured to query and intercept licensed and unlicensed remote-controlled vehicles; send, from an authoritative command device to a drone/CPV, a challenge requesting a response from the drone/CPV; verify the drone response and the operator response; determine that the drone/CPV is included in a mandated intercept definition; and intercept the drone/CPV. ADC device  502  may incorporate aspects of ADC device  120  as described with reference to  FIG.  1   . In some examples, ADC device  502  may include ADC device  502  authentication component and geofence component  514 . 
     In some cases, the authoritative command device is licensed by the licensing Authority. An ADC device  502  may be issued to authorized users, such as public safety personnel (e.g. police and firefighters) and governmental agencies. The ADC device  502  allows for lawful query and intercept of CPVs. The ADC device  502  should register itself to the DMA to get a valid token allowing for proof of identity. The use of this token allows the ADC to prove its Authority to CPVs when it issues an interrogatory or intercept request. Properly using this proof of identity in requests makes it cryptographically unfeasible to implement and deploy an imposter ADC device  502 . This allows for CPV operators to be confident that if their device is taken over it is done so legitimately. Furthermore, when a request is made the user is alerted about the identity of the ADC agency  528  empowering them to follow up on perceived unlawful actions. 
     In some examples, ADC device  502  authentication component may include device attributes  506 , device license  508 , device public key  510 , and device private key  512 . 
     ADC user  516  may incorporate aspects of ADC user  125  as described with reference to  FIG.  1   . In some examples, ADC user  516  may include ADC user  516  authentication component. In some examples, ADC user  516  authentication component may include user attributes  520 , user license  522 , user public key  524 , and user private key  526 . 
     ADC agency  528  may incorporate aspects of ADC agency  130  as described with reference to  FIG.  1   . In some examples, ADC agency  528  may include ADC agency  528  authentication component. In some examples, ADC agency  528  authentication component may include agency attributes  532 , agency license  534 , agency public key  536 , and agency private key  538 . 
       FIG.  6    shows a diagram  600  of a relay Node  605  that supports authentication, authorization and secure communication in accordance with aspects of the present disclosure. 
     Relay Node  605  may be an example of a component configured for communication with the plurality of vehicles and with the management Authority. Relay Node  605  may incorporate aspects of relay Node  135  as described with reference to  FIG.  1   . In some examples, relay Node  605  may include relay Node authentication component  610 , radio receiver  635 , radio transmitter  640 , and relay Node DMA token  645 . 
     A relay Node  605  may be a local or gateway communication device for other CPVs. The relay Node  605  can be, among other embodiments, fixed stationary (e.g. ground station) or mobile (e.g. UAV, handheld device, or temporary ground station). The relay Node  605  establishes mutually authenticated communications with CPV requesting connection. The CPV is then able to request local sensing data  155  (e.g. traffic or weather data) as well as connect to the Internet, if the relay Node  605  is configured for an internet connection. 
     In some examples, relay Node authentication component  610  may include relay Node attributes  615 , relay Node license  620 , relay Node public key  625 , and relay Node private key  630 . 
     Radio receiver  635  may incorporate aspects of radio receiver  340 ,  2475 , and  2525  as described with reference to  FIGS.  3 ,  24 , and  25   . Radio transmitter  640  may incorporate aspects of radio transmitter  345 ,  2480 , and  2530  as described with reference to  FIGS.  3 ,  24 , and  25   . 
       FIG.  7    shows a diagram  700  of a polite drone identification (PDI) device  705  that supports authentication, authorization and secure communication in accordance with aspects of the present disclosure. 
     PDI device  705  may be a device capable of communicating with a CPV. In some cases, a PDI device may be a mobile communications device. In some examples, PDI device  705  may include PDI authentication component  710 . In some examples, PDI authentication component  710  may include PDI attributes  715 , PDI license  720 , PDI public key  725 , and PDI private key  730 . 
       FIG.  8    shows a flowchart  800  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. 
     A DMA may interact with a drone/CPV and a drone/CPV operator. For example, the DMA may provide cryptographic signatures for the management (e.g. creation, verification, and revocation) of unforgeable, authentic drone licenses and DOLs. Thus, a DMA may verify the identity of a drone/CPV and drone/CPV operator as well as issuing a cryptographic token that can later be used to authenticate their license. The DMA can be a public or private entity with a public key distribution system as well the maintainer of secure private key(s). A cyber-physical vehicle management system includes verification components similar to the distribution system for digital rights management or digital certificate authorities. A DMA can be implemented to support a public key cryptographic scheme that is extensible to a large number of end-users, a revocation scheme that allows for informing end-users of cryptographic tokens that are no longer trusted, and a generation and issuing of scheme for verifiable CSDTs. 
     The CSDT is a token that is cryptographically signed by the DMA and includes information about the DMA as well as the public key(s) used by the DMA. The information the CSDT may also include, but is not limited to, the cryptographic schemes used, necessary protocols, or parameters. In a cyber-physical vehicle management system, the CSDT and all protocols for the DMA public key scheme are pre-installed, pre-distributed, or securely pinned to the drone. The CSDT may be stored in software or with trusted hardware Modules. Regardless, the CSDT, and corresponding algorithms, may be installed such that the processor that verifies other credentials, (including the drone, drone operator, ADC device, ADC user, ADC agency, and relay Node credentials) can securely access it. Distribution of the CSDT should be secure, and can be accomplished in software or hardware using various schemes, not discussed here. 
     A DOL may be a license linked to digital drone operator attributes. The drone operator attributes can include, but are not limited to, the drone operator&#39;s name, the drone operator&#39;s home address, and the drone operator&#39;s date of birth. In addition to the attributes, the DOL may include, but is not limited to, a class of license, the expiration date of the license, the issue date of the license, unique identifier, restrictions, and special exemptions. The drone/CPV and DOL should be generated by a trusted third-party organization such as a government agency, for example the FAA, or an independent organization. 
     The verification process may be performed prior to the issuance of a new DOL. The DOL and drone/CPV operator attributes are stored in various locations which could include, but is not limited to, the drone operator controller, a drone/CPV operator&#39;s personal PC, or a third-party organization. A pair of cryptographic keys including a public key and private key are then securely generated for the drone/CPV operator. This can be done locally or via a third-party service. The details for generating cryptographic keys is dependent on the cryptographic algorithms later used. Ideally, for the drone/CPV operator, the key generation occurs on a local device (the drone operator controller, a PC owned by the drone operator, or a secure hardware device). However, this process can occur with the license Authority or the DMA generating keys. At this point, the drone/CPV operator has generated all the necessary information to verify its identity to the DMA and receive a cryptographically signed drone operator token. A cryptographically signed drone operator token is a token that is cryptographically signed and allows for third-parties to verify the DMA signature if they have the CSDT. The cryptographically signed drone operator token also stores the public key for the drone/CPV operator enabling two functions. First, the drone operator public key can be used to encrypt data which only someone with the drone operator private key can decrypt. Second, the drone operator private key can be used to sign data which can be verified by the drone operator public key. Only the drone operator private key is able to produce signatures that will be correctly verified by the corresponding drone operator public key. 
     To receive a cryptographically signed drone operator token, the DOL, drone operator attributes, and associated public key are sent via a secure channel, such as an HTTPS Internet channel, to the DMA. The DMA verifies the DOL and drone operator attributes either locally, if capable, or through an issuing organization, for example the FAA. If any of the drone operator attributes do not match the DOL, then the license is not signed and is returned to the license requestor with an error message. Optionally, if a cryptographically signed drone operator token has already been issued for a DOL, the process aborts. The DMA then uses a cryptographically secure signature algorithm with the DMA private key to produce a cryptographically signed drone operator token. This token includes the drone operator attributes, DOL, and the drone operator public key. This data packet can be verified by any computer with the CSDT but cannot be forged by anyone that does not have the DMA private key(s), which is securely stored and managed by the DMA. Optionally, the DMA stores the cryptographically signed drone operator token into a database, that can later be used to verify messages signed by drones or verify the issued certificates. 
     The DMA returns the cryptographically signed drone operator token via a secure channel, like an HTTPS Internet connection to the requesting party. The drone operator, or other requesting party, uses a signature verification algorithm to prove the validity of the signature or to handle an error message. The cryptographically signed drone operator token and the corresponding drone operator private key is then stored in the drone operator credential. 
     At block  805  the DMA may receive data associated with a drone operator, the data including an operator license, a plurality of operator attributes, an operator cryptographic public key, and an operator cryptographic private key via a secure channel. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  810  the DMA may determine that the operator attributes match the operator license and that no operator token has been previously issued for the operator license. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  815  the DMA may generate a cryptographically signed operator token including the operator attributes, the operator license and the operator cryptographic public key. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  820  the DMA may send the operator token to a drone/CPV operator. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
       FIG.  9    shows a flowchart  900  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. Flowchart  900  may incorporate aspects described with reference to flowchart  800 . 
     At block  905  the DMA may receive data associated with a drone/CPV, the data including a drone license, a plurality of drone attributes, a drone cryptographic public key, and a drone cryptographic private key via a secure channel. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  910  the DMA may determine that the drone attributes match the drone license and that no drone token has been previously issued for the drone license. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  915  the DMA may generate a cryptographically signed drone token including the drone attributes, drone license and the drone cryptographic public key. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  920  the DMA may send the drone token to the drone. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
       FIG.  10    shows a flowchart  1000  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. In some examples, a CPV may execute a set of codes to control functional elements of the CPV to perform the described functions. Additionally or alternatively, a CPV may use special-purpose hardware. 
     A cyber-physical vehicle management system may ensure that prior to drone/CPV power-on that the CSDT is available for any processor that may verify the licenses. The cryptographically signed drone operator token is installed in or on the controller, or external to the controller, depending on the specific implementation. The cryptographically signed drone token is installed on the drone, or external to the drone/CPV, depending on the specific implementation. For example, the cryptographically signed drone token may be stored in a trusted platform Module on the drone/CPV or on a removable dongle that is plugged in at runtime. 
     When a drone/CPV and corresponding controller is powered on, a drone/CPV and a drone/CPV operator may perform a mutual verification process to ensure that the licenses are valid for flight. The system uses a cryptographic signature verification algorithm to verify the signature on the cryptographically signed drone token with the DMA public keys. Once the signature on the cryptographically signed drone token is verified the drone verifies the license is valid. This verification may include, but is not limited to, verifying the license expiration date is in the future, verifying the license start date is in the past, and verifying the license class has operating privilege in a local area. 
     Optionally, the drone/CPV may verify the revocation list, or list of tokens that can no longer be trusted. The verification algorithm can check various things including, but not limited to, a cryptographic signature using the DMA public keys, date of last update, and current revocation list. If the verification steps fail, then the drone enters a failsafe mode. The failsafe mode could include various actions including, but not limited to, alerting the user of the failure via the drone/CPV operator display or preventing the drone from flying. 
     The verification continues by using a challenge and response protocol between the drone/CPV and the drone/CPV operator credential. Depending on the specific implementation, the cryptographically signed drone operator token may be stored on the drone, the drone controller, or external to the drone controller. Regardless, we assume that the cryptographically signed drone operator token can exchange messages with the controller using local communications (e.g. software pipes, USB, serial, or Bluetooth). The drone controller communicates to the drone/CPV wirelessly. The drone/CPV issues a challenge which can be generated with any number of true or pseudo random algorithms (e.g. amplified thermal noise, yarrow, fortuna, or AES-counter) or using a time stamp. The challenge is then sent to the device with the drone operator credentials. The challenge is combined with the cryptographically signed drone operator token and a cryptographic response is prepared using the drone operator private key. This response is returned to the drone via the local link which cryptographically verifies the validity of the response and DOL. If this verification fails, then the drone/CPV enters a failsafe mode such as those described above. 
     After verification of the licenses, the drone/CPV and drone/CPV controller can use the cryptographic keys from the cryptographically signed drone token and the cryptographically signed drone operator token to exchange future cryptographic keys. This also allows for any cryptographic information to be exchanged for future communications. Similarly, the drone/CPV can use the drone public/private keys to exchange future cryptographic keys with the display. These keys and protocol exchanges allow for authenticated and, if desired, encrypted communications between the controller and drone, as well as the drone and drone operator display. 
     At block  1005  the CPV may verify, using a drone public key and a drone token stored on a remote-controlled drone, a signature on a drone token using a cryptographic signature verification algorithm. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  1010  the CPV may verify that the drone license is valid. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  1015  the CPV may perform a challenge and response protocol between the drone/CPV and a controller. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  1020  the CPV may verify that the drone operator license is valid. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  1025  the CPV may exchange future cryptographic keys by the drone/CPV and the drone controller. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
       FIG.  11    shows a flowchart  1100  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. In some examples, a CPV may execute a set of codes to control functional elements of the CPV to perform the described functions. Additionally or alternatively, a CPV may use special-purpose hardware. 
     A drone/CPV may request the position or other information from other drones/CPVs in a local area. The local area maybe most simply defined as the radio range or may extend into line-of-sight, aural range, or preset coordinate boundaries. A cyber-physical vehicle management system may provide for authenticated non-reputable communications from the responding drones to the requesting drone. This protocol depends on the previous distribution of the CSDT to the requesting drone and the responding drone(s) to have valid cryptographically signed drone tokens. 
     The protocol starts when the requesting drone/CPV generates a request with a cryptographically random nonce, or challenge. This request is sent via the requesting drones radio to all responding drones/CPVs in radio range. When a drone/CPV receives a request packet the cryptographic challenge is combined with the current navigation data and the responding drone/CPV&#39;s cryptographically signed drone token. The navigation may include, but is not limited, the GPS synched time, the location, the heading, and the altitude. The output of the combination is then used to prepare a cryptographic response using the responding drone/CPV&#39;s private key. This response is then sent via the responding drone/CPV&#39;s radio to the requesting drone. The requesting drone/CPV verifies multiple aspects of the response packet. First, the requesting drone verifies that the responding drone&#39;s cryptographically signed token is legitimately signed using the DMA public key(s) in the pre-distributed CSDT. After verifying the legitimacy of the responder&#39;s cryptographically signed drone token, the requesting drone then verifies the response packets signature using the responding drone/CPV&#39;s public key. Once these validation steps have been proven, the requesting drone stores the response in a database for future use. One use of these response packets is for navigation algorithms to cooperatively plan paths with other drones. In some cases, i.e., to limit the amount of traffic for drone location response, drones/CPVs may record the random nonce and use it to record other drone responses. This avoids the need for 2 n  exchanges for n drones to verify locations. 
     To manage airspace that both drones/CPVs and manned aircraft (e.g. personal and commercial helicopters and airplanes) fly in especially airspace that is presently regulated but not controlled (e.g. Class G airspace), we propose a system similar to the above discussed drone-to-drone communication. A key differentiator is that manned aircraft will have priority over drones. In order to put this into effect, the manned aircraft&#39;s identity and status as a manned aircraft would have to be authenticated. We can apply another solution for those who want to fly over their own property (herein known as “property owner(s)”), say a farmer crop-dusting her field. In this situation, the property owner could reserve the airspace above their property for a fixed interval of time within an altitude range where drone operators will not be permitted to submit flight plans that enter the temporarily restricted area. Any flight plans that have already submitted by drone/CPV operators that would have them enter the temporarily restricted would have to be managed with priority determined via regulation (e.g. first-come-first-serve, property-owner precedence, or fees). Alternatively, the property owner could proactively enforce this drone flight restriction by setting up a relay Node to ensure that all drones in the area have been notified of their approved airspace restriction. 
     At block  1105  the CPV may generate a request with a cryptographic nonce. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  1110  the CPV may send the request to all drones in a geographic area. In certain examples, aspects of the described operations may be performed by radio receiver  340 ,  635 ,  2475 , and  2525  as described with reference to  FIGS.  3 ,  6 ,  24 , and  25   . 
     At block  1115  the CPV may receive a response from a drone in the geographic area. In certain examples, aspects of the described operations may be performed by radio transmitter  345 ,  640 ,  2480 , and  2530  as described with reference to  FIGS.  3 ,  6 ,  24 , and  25   . 
     At block  1120  the CPV may verify a cryptographic token of the responding drone. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  1125  the CPV may store the response. In certain examples, aspects of the described operations may be performed by drone database  350  as described with reference to  FIG.  3   . 
       FIG.  12    shows a flowchart  1200  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. 
     A DMA may verify the identity of an ADC device, ADC user, and ADC agency as well as issuing each a cryptographic token that can later be used to authenticate their license. The DMA can be a public or private entity with a public key distribution system as well as secure private key(s). A cyber-physical vehicle management system may have similar aspects to the distribution system for digital rights management. Digital certificate authorities can be implemented to support the following: a public-private key scheme that is extensible to a large number of end-users; a revocation scheme that allows for informing end-users of cryptographic tokens that are no longer trusted; and a CSDT which allows end-users to verify cryptographic tokens issued by the DMA. 
     The CSDT is a token that is cryptographically signed by the DMA and includes information about the DMA as well as public key(s) from the DMA. The information the CSDT may include, but is not limited to, the cryptographic schemes used and necessary protocols or parameters. In a cyber-physical vehicle management system, the CSDT and all protocols for the DMA public key scheme are pre-installed, pre-distributed, or pinned to the ADC in a secure manner. The CSDT may be stored in software or with trusted hardware Modules. Regardless, the CSDT, and corresponding algorithms, may be installed such that the processor that verifies other credentials (including the ADC device, ADC agency, and ADC user) can securely access it. Distribution of the CSDT should, ideally, be secure, which can be accomplished in software or hardware using various schemes which are not discussed here. 
     An ADC user license may be a license linked to digital ADC user attributes. The ADC user attributes can include, but are not limited to, the ADC user&#39;s name, the ADC device user&#39;s agency, and the ADC user&#39;s start date. The ADC user license may include, but is not limited to, a class of license, the expiration date of the license, the issue date of the license, and a unique identifier. ADC user license should be generated by a trusted third-party organization such as a government agency, for example the Federal Aviation Administration, or an independent organization. 
     When a new ADC user license is issued, a verification process may be performed (e.g., by a DMA) before secure operation is possible. The ADC user license and ADC user attributes are stored in various locations which could include, but are not limited to, the ADC device, an ADC device owner&#39;s personal PC, or the FAA. A pair of cryptographic keys including a public key and private key are securely generated for the ADC device. This can be done locally or via a third-party service. The details for generating cryptographic keys is dependent on the cryptographic algorithms later used. Ideally, the key generation occurs on a local device (the ADC device, a PC owned by the ADC agency Operator, or a secure hardware device). 
     However, this process can occur with the license Authority or the DMA generating keys. At this point, the ADC device has generated the necessary information to verify its identity to the DMA and receive a cryptographically signed ADC device token. A cryptographically signed ADC device token is a token that is cryptographically signed and allows for third-parties to verify the DMA signature if they have the CSDT. The cryptographically signed ADC device token also stores the public key for the ADC device enabling two functions. First, the ADC user public key can be used to encrypt data which only someone with the ADC user private key can decrypt. Second, the ADC user private key can be used to sign data which can be verified by the ADC User public key. Only the ADC user private key is able to produce signatures that will be correctly verified by the corresponding ADC user public key. 
     To receive a cryptographically signed ADC user token the ADC user license, ADC user attributes, and associated public key are sent via a secure channel, such as an HTTPS Internet channel, to the DMA. The DMA verifies the ADC user license and ADC user attributes either locally, if capable, or through the issuing organization, for example the FAA. If any of the ADC agency Attributes does not match the ADC agency License, then the license is not signed and is returned to the license requestor with an error message. Optionally, if a cryptographically signed ADC agency token has already been issued for an ADC agency License the process aborts. The DMA then uses a cryptographically secure signature algorithm with the DMA private key to produce a cryptographically signed ADC device token. This token includes the ADC user attributes, ADC user license, and the ADC user public key. This token can be verified by any computer with the CSDT but cannot be forged by anyone that does not have the DMA private key(s), which is securely stored and managed by the DMA. Optionally, the DMA stores the cryptographically signed ADC user token into a database, which can later be used to verify messages signed by ADC devices or verify the issued certificates. 
     The DMA returns the cryptographically signed ADC user token via a secure channel, like an HTTPS Internet connection to the requesting party. The ADC device, or other requesting party, uses a signature verification algorithm to prove the validity of the signature or to handle an error message. The cryptographically signed ADC user token and the corresponding ADC agency private key is then stored in the ADC device. 
     At block  1205  the DMA may receive data associated with a controller or user of an authoritative command device, the data including a user license, a plurality of user attributes, a user cryptographic public key, and a user cryptographic private key via a secure channel. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1210  the DMA may determine that the user attributes match the user license and that no user token has been previously issued for the user license. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1215  the DMA may generate a cryptographically signed user token including the user attributes, the user license and the user cryptographic public key. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1220  the DMA may send the user token to the controller of the authoritative command device. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
       FIG.  13    shows a flowchart  1300  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. 
     An ADC device license may be a license linked to digital ADC device attributes. The ADC device attributes can include, but are not limited to, the ADC device&#39;s agency, the ADC device&#39;s home location, and the ADC device&#39;s date of manufacture. The ADC device license may include, but is not limited to, a class of license, the expiration date of the license, the issue date of the license, and a unique identifier. The ADC device license should be generated by a trusted third-party organization such as a government agency, the FAA, or an independent organization. 
     When a new ADC device license is issued, a verification process may be performed (e.g., by a DMA) before secure operation is possible. The ADC device license and ADC device attributes are stored in various locations which could include, but are not limited to, the drone controller, an ADC devices personal PC, or the FAA. A pair of cryptographic keys including a public key and private key are then securely generated for the ADC device. This can be done locally or via a third-party service. The details for generating cryptographic keys is dependent on the cryptographic algorithms later used. Ideally, for the ADC device, the key generation occurs on a local device (the drone controller, a PC owned by the ADC device, or a secure hardware device). However, this process can occur with the license Authority or the DMA generating keys. At this point, the ADC device has all generated the necessary information to verify its identity to the DMA and receive a cryptographically signed ADC device token. A cryptographically signed ADC device token is a token that is cryptographically signed and allows for third-parties to verify the DMA signature if they have the CSDT. The cryptographically signed ADC device token also stores the public key for the ADC device enabling two functions. First, the ADC device public key can be used to encrypt data which only someone with the ADC device private key can decrypt. Second, the ADC device private key can be used to sign data which can be verified by the ADC device public key. Only the ADC device private key is able to produce signatures that will be correctly verified by the corresponding ADC device public key. 
     To receive a cryptographically signed ADC device token the ADC device license, ADC device attributes, and associated public key are sent via a secure channel, such as an HTTPS Internet channel, to the DMA. The DMA verifies the ADC device license and ADC device attributes either locally, if capable, or through the issuing organization, for example the FAA. If any of the ADC device attributes do not match the ADC device license, then the license is not signed and is returned to the license requestor with an error message. Optionally, if a cryptographically signed ADC device token has already been issued for an ADC device license the process aborts. The DMA then uses a cryptographically secure signature algorithm with the DMA private key to produce a cryptographically signed ADC device token. This token includes the ADC device attributes, ADC device license, and the ADC device public key. This token can be verified by any computer with the CSDT but cannot be forged by anyone that does not have the DMA private key(s), which is securely stored and managed by the DMA. Optionally, the DMA stores the cryptographically signed ADC device token into a database that can later be used to verify messages signed by drones or verify the issued certificates. 
     The DMA returns the cryptographically signed ADC device token via a secure channel, like an HTTPS Internet connection to the requesting party. The ADC device, or other requesting party, uses a signature verification algorithm to prove the validity of the signature or to handle an error message. The cryptographically signed ADC device token and the corresponding ADC device private key is then stored in the ADC device credential. 
     At block  1305  the DMA may receive data associated with an authoritative command device, the data including a device license, a plurality of device attributes, a device cryptographic public key, and a device cryptographic private key via a secure channel. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1310  the DMA may determine that the device attributes match the device license and that no device token has been previously issued for the device license. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1315  the DMA may generate a cryptographically signed device token including the device attributes, the device license and the device cryptographic public key. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1320  the DMA may send the device token to the authoritative command device. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
       FIG.  14    shows a flowchart  1400  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. 
     We define the ADC agency license as a license linked to digital ADC agency attributes. The ADC agency attributes can include, but are not limited to, the ADC agency&#39;s name and the ADC agency&#39;s address. The ADC agency license may include, but is not limited to, a class of license, the expiration date of the license, the issue date of the license, and a unique identifier. ADC agency license should be generated by a trusted third-party organization such as a government agency, for example the Federal Aviation Administration, or an independent organization. 
     When a new ADC agency license is issued, a verification process may be performed (e.g., by a DMA) before secure operation is possible. The ADC agency license and ADC agency attributes are stored in various locations which could include, but is not limited to, the ADC device, an ADC device owner&#39;s personal PC, or the FAA. A pair of cryptographic keys including a public key and private key are securely generated for the ADC agency. This can be done locally or via a third-party service. The details for generating cryptographic keys is dependent on the cryptographic algorithms later used. Ideally, the key generation occurs on a local device (the ADC device, a PC owned by the ADC agency Operator, or a secure hardware device). However, this process can occur with the license Authority or the DMA generating keys. At this point, the ADC agency has generated the necessary information to verify its identity to the DMA and receive a cryptographically signed ADC agency token. 
     A cryptographically signed ADC agency token is a token that is cryptographically signed and allows for third-parties to verify the DMA signature if they have the CSDT. The cryptographically signed ADC agency token also stores the public key for the ADC agency enabling two functions. First, the ADC user public key can be used to encrypt data which only someone with the ADC user private key can decrypt. Second, the ADC agency private key can be used to sign data which can be verified by the ADC agency public key. Only the ADC agency private key is able to produce signatures that will be correctly verified by the corresponding ADC agency public key. 
     To receive a cryptographically signed ADC agency token the ADC agency license, ADC agency attributes, and associated public key are sent via a secure channel, such as an HTTPS Internet channel, to the DMA. The DMA verifies the ADC agency license and ADC agency attributes either locally, if capable, or through the issuing organization, for example the FAA. If any of the ADC agency attributes does not match the ADC agency license, then the license is not signed and is returned to the license requestor with an error message. These error messages can be displayed to the user via, amongst other ways, the user&#39;s smartphone, drone video display, or sent to the user via SMS depending on the application. Optionally, if a cryptographically signed ADC agency token has already been issued for an ADC agency license the process aborts. The DMA then uses a cryptographically secure signature algorithm with the DMA private key to produce a cryptographically signed ADC agency token. This token includes the ADC agency attributes, ADC agency license, and the ADC agency public key. This token can be verified by any computer with the CSDT but cannot be forged by anyone that does not have the DMA private key(s), which is securely stored and managed by the DMA. Optionally, the DMA stores the cryptographically signed ADC agency token into a database, that can later be used to verify messages signed by ADC agency or verify the issued certificates. 
     The DMA returns the cryptographically signed ADC agency token via a secure channel, like an HTTPS Internet connection to the requesting party. The ADC agency, or other requesting party, uses a signature verification algorithm to prove the validity of the signature or to handle an error message. The cryptographically signed ADC agency token and the corresponding ADC agency private key is then stored in the ADC agency. 
     At block  1405  the DMA may receive data associated with an authoritative command agency, the data including an agency license, a plurality of agency attributes, an agency cryptographic public key, and an agency cryptographic private key via a secure channel. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1410  the DMA may determine that the agency attributes match the agency license and that no agency token has been previously issued for the agency license. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1415  the DMA may generate a cryptographically signed agency token including the agency attributes, the agency license and the agency cryptographic public key. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1420  the DMA may send the agency token to the authoritative command agency. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
       FIG.  15    shows a flowchart  1500  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. 
     At block  1505  the DMA may receive data associated with a PDI device, the data including an PDI license, a plurality of PDI attributes, a PDI cryptographic public key, and a PDI cryptographic private key via a secure channel. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1510  the DMA may determine that the PDI attributes match the PDI license and that no PDI token has been previously issued for the PDI license. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1515  the DMA may generate a cryptographically signed PDI token including the PDI attributes, the PDI license and the PDI cryptographic public key. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1520  the DMA may send the PDI token to the PDI device. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
       FIG.  16    shows a flowchart  1600  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. 
     At block  1605  the DMA may receive data associated with a relay Node, the data including a relay Node license, a plurality of relay Node attributes, a relay Node cryptographic public key, and a relay Node cryptographic private key via a secure channel. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1610  the DMA may determine that the relay Node attributes match the relay Node license and that no relay Node token has been previously issued for the relay Node license. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1615  the DMA may generate a cryptographically signed relay Node token including the relay Node attributes, the relay Node license and the relay Node cryptographic public key. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
     At block  1620  the DMA may send the relay Node token to the relay Node device. In certain examples, aspects of the described operations may be performed by DMA authentication component  410  as described with reference to  FIG.  4   . 
       FIG.  17    shows a flowchart  1700  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. In some examples, an ADC device may execute a set of codes to control functional elements of the ADC device to perform the described functions. Additionally or alternatively, an ADC device may use special-purpose hardware. 
     An ADC device may validate device, agency, and user credentials. For a valid verification on start-up, cryptographically signed tokens may be contained for the ADC device, ADC agency, and ADC user. The ADC agency credentials including the cryptographically signed ADC agency token and the ADC agency private key may be stored in software or hardware with local communications to the ADC device. Similarly, the ADC user credentials—including the cryptographically signed ADC user token and the ADC user private key—may be stored in software or hardware with local communications to the ADC device. For example, the software solution could be a trusted piece of code while the hardware solution could be a secure USB dongle; the exact implementation of the storage of agency and user credentials is left to the specific implementation. We also assume that the ADC device has the cryptographically signed DMA token. 
     On power-up, the ADC device may verify the device token, agency token, and user token before it begins normal operation. To verify the ADC device token, the device prepares a cryptographic response based on verification data and the ADC device private key. The verification data can be a random nonce, a copy of the cryptographically signed ADC device token, a timestamp, a combination thereof, or any digital data. An example cryptographic response, would be signing the verification data with the private key. This is then passed to a cryptographic verification algorithm which uses the ADC device&#39;s public key to verify the responses validity. If the cryptographically signed ADC device token is not included in the response, the ADC public key may be passed separately to the verification algorithm. 
     The cryptographically signed ADC device token is also passed to the device licenses verification process either as the output of the signature verification process or separately. The device license verification process uses DMA public key in the CSDT to verify the signature on the cryptographically signed ADC device token is a valid DMA signature. It then verifies selected attributes from the ADC device license and ADC device token. These could include, but are not limited to, a valid license date and the license not appearing on the revoked license list. If any of the verifications fail, the device enters a failsafe mode which may include, but is not limited to, displaying an error message and ceasing operations. 
     If the device level verifications pass, the device then verifies the validity of the ADC user credentials. The ADC device prepares verification data which can be a random nonce or any other type of digital data and sends it via the local link to the ADC user credential. It may then be combined with the cryptographically signed ADC user token or may directly be passed to the cryptographic user response algorithm. This algorithm prepares a cryptographic response using the ADC user private key and then returns it to the ADC device. If the cryptographically signed ADC user token is not included in the cryptographic user response, then it may also be passed to the ADC device. The ADC device then verifies the user response using the ADC user public key. The cryptographically signed ADC user token is then verified. This includes verifying the DMA signature, user license attributes, and user information attributes. If any of the verifications fail, the device enters a failsafe mode which may include, but is not limited to, displaying an error message and ceasing operations. If the device is a user-free device, the user signature and license verification is not used. 
     If the user level verifications pass, the device then verifies the validity of the ADC agency credentials. The ADC device prepares verification data, which can be a random nonce or any other type of digital data and sends it via the local link to the ADC agency credential. It may then be combined with the cryptographically signed ADC agency token or may directly be passed to the agency response algorithm. This algorithm prepares a cryptographic response using the ADC agency private key and then returns it to the ADC device. 
     If the cryptographically signed ADC agency token is not included in the signed data then it may also be passed to the ADC device. The ADC device then verifies the agency response using the ADC agency public key. The cryptographically signed ADC agency token is then passed to verify the agency license. This includes verifying the DMA signature, user license attributes, and user information attributes. If any of the verifications fail, the device enters a failsafe mode which may include, but is not limited to, displaying an error message and ceasing operations. If the device is an agency-free device, the user signature and license verification is not used. If the necessary signature and license verifications finish, the ADC device enters a nominal operation mode. This then allows the ADC to interrogate or intercept drones. 
     At block  1705  the ADC device may power up. In certain examples, aspects of the described operations may be performed by ADC device  120  and  505  as described with reference to  FIGS.  1  and  5   . 
     At block  1710  the ADC device may verify an ADC device token. In certain examples, aspects of the described operations may be performed by ADC device authentication component  510  as described with reference to  FIG.  5   . 
     At block  1715  the ADC device may verify an ADC user token. In certain examples, aspects of the described operations may be performed by ADC device authentication component  510  as described with reference to  FIG.  5   . 
     At block  1720  the ADC device may verify an ADC agency token. In certain examples, aspects of the described operations may be performed by ADC device authentication component  510  as described with reference to  FIG.  5   . 
     At block  1725  the ADC device may interrogate or intercept a drone. In certain examples, aspects of the described operations may be performed by ADC device  120  and  505  as described with reference to  FIGS.  1  and  5   . 
       FIG.  18    shows a flowchart  1800  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. In some examples, a CPV may execute a set of codes to control functional elements of the CPV to perform the described functions. Additionally or alternatively, a CPV may use special-purpose hardware. 
     A drone/CPV may verify the validity of an ADC device. This includes verifying the device credential, user credential, and agency credential associated with the ADC. The ADC user credentials including the cryptographically signed ADC agency token may be stored in software or hardware with local communications to the ADC device. Similarly, the ADC agency credentials including the cryptographically signed ADC user token may be stored in software or hardware with local communications to the ADC device. For example, the software solution could be a trusted piece of code while the hardware solution could be a secure USB dongle; the exact implementation of the agency and user credentials is left to the specific implementation. We also assume that the drone has access to the cryptographically signed DMA token. 
     When a drone/CPV desires to prove the identity of an ADC device the drone/CPV first prepares a piece of digital data, hereafter referred to as a challenge. The challenge may be constructed using various parameters like the GPS coordinates of the drone/CPV, the current time, or a random number. The challenge is sent from the drone/CPV to the ADC device. Upon receiving the challenge from the drone, the ADC device sends it to both the ADC agency credential and ADC user credential. Within the ADC user credential, the challenge and the cryptographically signed ADC user token are combined. The ADC user credential then uses the combined data to prepare a cryptographic response using the ADC user private key. This response is then returned to the ADC device. 
     Similarly, within the ADC agency credential, the challenge and the cryptographically signed ADC agency token are combined. The ADC agency credential uses the combined data to prepares a cryptographic response using the ADC user private key. This response is then returned to the ADC device. 
     At the same time, the ADC device combines the challenge and the cryptographically signed ADC device token. This combined data is then used to prepare an authenticated cryptographic response with the ADC device private key. The authenticated device response, the authenticated agency response, and the authenticated user response are combined and returned to the drone. Upon receiving the response from the ADC device, the drone/CPV verifies the ADC device&#39;s response with the CSDT. Similarly, the user response and agency response are verified. If all of the verifications are validated, the ADC device has proven its identity. For each response the verification has various checks which may include, but is not limited to, the following: verifying the tokens signature is valid using the DMA public key(s); verifying the signature on the response using the corresponding tokens public key; verifying the token has not been revoked; and verifying the license is not expired. 
     At block  1805  the CPV may prepare an ADC challenge. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  1810  the CPV may verify an ADC device response. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  1815  the CPV may verify an ADC user response. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  1820  the CPV may verify an ADC agency response. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  1825  the CPV may identify the ADC device. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
       FIG.  19    shows a flowchart  1900  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. 
     An ADC device may interrogate one or more operating drones for their license information. The ADC device makes a clear text interrogatory (challenge) for identification which includes a piece of digital data, hereafter referred to as a challenge, and a definition of drones that are mandated to respond. The challenge could be a random number, a timestamp, or any other piece of digital data. The mandated response definition may use, but is not limited to, drone IDs, a drone operator IDs, license class, or all drones/CPVs. All drones/CPVs that receive the interrogatory check to see if they are in the set of drones/CPVs that are mandated to respond. If a drone/CPV is in the set of mandated responders it will send a message to the drone operator&#39;s display, if applicable, indicating a request has occurred. If a drone/CPV is in the set of mandated responders it also verifies the credentials of the ADC device using the process shown in  FIG.  7   . If any of the credentials do not verify, the drone sends this information to the user display and the user can choose whether to continue cooperation. If all of the credentials are valid, the drone/CPV then prepares a response to the interrogatory without user approval, although user notification can occur. 
     The challenge is forwarded to the drone/CPV operator credential and combined with the cryptographically signed drone operator token. A cryptographic response based on this token is then prepared using the drone operator private key and returned to the drone. On the drone/CPV, a cryptographic response based on the challenge is also prepared using the cryptographically signed drone token. The two responses are then sent to the ADC device which cryptographically verifies its validity. This information may then be displayed to the ADC user and may be stored in a database for future use. 
     At block  1905  the authoritative command device may send to a drone/CPV, a challenge requesting a response from the drone. In certain examples, aspects of the described operations may be performed by ADC device  120  and  505  as described with reference to  FIGS.  1  and  5   . 
     At block  1910  the CPV may forward the challenge to the drone/CPV operator controller. In certain examples, aspects of the described operations may be performed by CPV  105 ,  305 , and  2410  as described with reference to  FIGS.  1 ,  3 , and  24   . 
     At block  1915  the CPV operator controller may compare the challenge to an operator credential stored on the drone operator controller. In certain examples, aspects of the described operations may be performed by CPV operator  110  as described with reference to  FIG.  1   . 
     At block  1920  the CPV operator controller may prepare a cryptographic operator response based on the operator credential. In certain examples, aspects of the described operations may be performed by CPV operator  110  as described with reference to  FIG.  1   . 
     At block  1925  the CPV operator controller may return the operator response to the drone. In certain examples, aspects of the described operations may be performed by CPV operator  110  as described with reference to  FIG.  1   . 
     At block  1930  the CPV may prepare a cryptographic drone response based on the operator response, the challenge and a drone token stored on the drone/CPV. In certain examples, aspects of the described operations may be performed by CPV  105 ,  305 , and  2410  as described with reference to  FIGS.  1 ,  3 , and  24   . 
     At block  1935  the drone/CPV may send, to the authoritative command device, the drone/CPV response and the operator response. In certain examples, aspects of the described operations may be performed by CPV  105 ,  305 , and  2410  as described with reference to  FIGS.  1 ,  3   , and  24 . 
       FIG.  20    shows a flowchart  2000  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. In some examples, a CPV may execute a set of codes to control functional elements of the CPV to perform the described functions. Additionally or alternatively, a CPV may use special-purpose hardware. 
     An ADC device may intercept a drone/CPV that is previously flying autonomously or being remotely controlled. The ADC device prepares an intercept request which includes a mandated intercept definition. The intercept request is then sent wirelessly to the drone which checks the mandated intercept definition. If the drone/CPV is contained in the mandated intercept definition, then it proceeds with the intercept process. The CPV may verify the ADC device, ADC user, and ADC agency. Upon successful verification of the ADC device, ADC user, and ADC agency, the drone/CPV prepares a message indicating it is ceding control to the ADC device. This message is sent to the drone user&#39;s display along with the agency information, allowing for a drone/CPV operator to immediately file a complaint if they believe the control takeover was illegitimate. 
     The message is also forwarded to the ADC device indicating that control has been ceded. At this point, the ADC device prepares control input that it can send to operate the drone/CPV. Any messages received from the drone operator controller will be ignored by the intercepted drone/CPV. The drone/CPV cedes control of flight operations and retain control of other functions. This allows for a continued feedback to users of the location and sensor feeds from the drone to avoid inappropriate actions of capturing agencies. Furthermore, all authenticated control input received from the ADC device are forwarded to the user&#39;s display allowing for tracking the ADC agencies control of the drone/CPV. At any point that the ADC device desires to return control to the nominal drone operator controller they can release control and nominal drone operator will be notified via the user&#39;s display or other method. 
     At block  2005  the CPV may identify an intercept request from an ADC device. In certain examples, aspects of the described operations may be performed by CPV  105 ,  305 , and  2410  as described with reference to  FIGS.  1 ,  3   , and  24 . 
     At block  2010  the CPV may verify the ADC device. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  2015  the CPV may verify an ADC user. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  2020  the CPV may verify an ADC agency. In certain examples, aspects of the described operations may be performed by drone authentication component  310  as described with reference to  FIG.  3   . 
     At block  2025  the CPV may cede control to the ADC device. In certain examples, aspects of the described operations may be performed by CPV  105 ,  305 , and  2410  as described with reference to  FIGS.  1 ,  3 , and  24   . 
       FIG.  21    shows a flowchart  2100  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. In some examples, an ADC device may execute a set of codes to control functional elements of the ADC device to perform the described functions. Additionally or alternatively, an ADC device may use special-purpose hardware. 
     An ADC device may provide a geographic boundary for drones/CPVs. The ADC device is programmed with a boundary, hereafter known as the mandatory boundary, that can be defined with fixed coordinates or with a radius around a GPS-equipped ADC device. The boundary can also be defined using various algorithms left to specific implementations. The drone/CPV is also programmed with a “safety factor” (e.g. a defined buffer zone) which defines a second, larger boundary, hereafter known as the warning boundary. 
     If the ADC device detects a drone/CPV between the warning boundary and mandatory boundary it prepares a warning for the drone/CPV. The warning message includes, but is not limited to, a definition of the mandatory boundary. If desired, the drone/CPV can verify the ADC device&#39;s validity. The drone/CPV can use the warning message to navigate safely around the boundary. The drone/CPV can also send a “detour” request to the ADC device. The detour request includes, but is not limited to, the drone&#39;s current position and desired waypoint. The ADC device will reply to detour requests with a new route, using various mapping techniques, for the drone/CPV that safely navigates around the mandatory boundary. When a drone/CPV passes the warning boundary, a message will also be sent to the drone operator&#39;s display making sure the operator is aware of the potential violation. 
     If the ADC device detects a drone/CPV within the mandatory boundary, it may send an intercept request to the drone. The drone/CPV, after verifying the ADC device&#39;s validity, then cedes control to the ADC device. The ADC device can take various automated approaches to mitigate the drone intrusion including, but not limited to, RTL, Reroute, or Send to Capture Point. RTL would send the drone back to the operator where the drone/CPV was launched. Reroute would direct the drone/CPV outside of the mandatory boundary. Send to Capture Point would land the drone at a predefined safe location. Upon ceding control, a message is sent to the drone/CPV operator&#39;s display for a user to track the captured drone/CPV. 
     At block  2105  the ADC device may determine a mandatory boundary. In certain examples, aspects of the described operations may be performed by geofence component  535  as described with reference to  FIG.  5   . 
     At block  2110  the ADC device may determine a warning boundary. In certain examples, aspects of the described operations may be performed by geofence component  535  as described with reference to  FIG.  5   . 
     At block  2115  the ADC device may identify a CPV between the warning boundary and the mandatory boundary. In certain examples, aspects of the described operations may be performed by geofence component  535  as described with reference to  FIG.  5   . 
     At block  2120  the ADC device may transmit a warning message to the CPV including the mandatory boundary. In certain examples, aspects of the described operations may be performed by geofence component  535  as described with reference to  FIG.  5   . 
       FIG.  22    shows a flowchart  2200  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. In some examples, a PDI device may execute a set of codes to control functional elements of the PDI device to perform the described functions. Additionally or alternatively, a PDI device may use special-purpose hardware. 
     A DMA may verify the identity of a PDI device as well as issuing a cryptographic token that can later be used to authenticate its license. The DMA can be a public or private entity with a public key distribution system as well as secure private key(s). A cyber-physical vehicle management system includes verification components similar to the distribution system for digital rights management or digital certificate authorities. A DMA can be implemented to support a public key cryptographic scheme that is extensible to a large number of end-users, a revocation scheme that allows for informing end-users of cryptographic tokens that are no longer trusted, and a generation and issuing of scheme for verifiable CSDTs. 
     The CSDT is a token that is cryptographically signed by the DMA and includes information about the DMA as well as public key(s) from the DMA. The information the CSDT may include, but is not limited to, the cryptographic schemes used and necessary protocols or parameters. In a cyber-physical vehicle management system, the CSDT and all protocols for the DMA public key scheme are pre-installed, pre-distributed, or pinned to the PDI in a secure manner. The CSDT may be stored in software or with trusted hardware Modules. Regardless, the CSDT, and corresponding algorithms, may be installed such that the processor that verifies credentials, can securely access it. Distribution of the CSDT should, ideally, be secure, which can be accomplished in software or hardware using various schemes, not discussed here. 
     A PDI device license may be a license linked to digital PDI device attributes. The PDI device attributes can include, but are not limited to, the PDI device&#39;s name, the PDI device&#39;s home location, and the PDI device&#39;s date of birth. The PDI device license may include, but is not limited to, a class of license, the expiration date of the license, the issue date of the license, and a unique identifier. The PDI device license should be generated by a trusted third-party organization such as a government agency, for example the Federal Aviation Administration, or an independent organization. 
     When a new PDI device license is issued a verification process may be performed (e.g., by a DMA) before secure operation is possible. The PDI device license and PDI device attributes are stored in various locations which could include, but is not limited to, on or external to the PDI device. A pair of cryptographic keys including a public key and private key are then securely generated for the PDI device. This can be done locally or via a third-party service. The details for generating cryptographic keys is dependent on the cryptographic algorithms later used. Ideally, for the PDI device, the key generation occurs on a local device (a PC owned by the PDI device owner, or a secure hardware device). However, this process can occur with the license Authority or the DMA generating keys. At this point, the PDI device has all generated the necessary information to verify its identity to the DMA and receive a cryptographically signed PDI device token. 
     A cryptographically signed PDI device token is a token that is cryptographically signed and allows for third-parties to verify the DMA signature if they have the CSDT. The cryptographically signed PDI device token also stores the public key for the PDI device enabling two functions. First, the PDI device public key can be used to encrypt data that someone with the PDI device private key can decrypt. Second, the PDI device private key can be used to sign data which can be verified by the PDI device public key. The PDI device private key is able to produce signatures that will be correctly verified by the corresponding PDI device public key. 
     To receive a cryptographically signed PDI device token the PDI device license, PDI device attributes, and associated public key are sent via a secure channel, such as an HTTPS Internet channel, to the DMA. The DMA verifies the PDI device license and PDI device attributes either locally, if capable, or through the issuing organization, for example the FAA. If any of the PDI device attributes does not match the PDI device license then the license is not signed and is returned to the license requestor with an error message. Optionally, if a cryptographically signed PDI device token has already been issued for a PDI device license the process aborts. The DMA then uses a cryptographically secure signature algorithm with the DMA private key to produce a cryptographically signed PDI device token. This token includes the PDI device attributes, PDI device license, and the PDI device public key. This token can be verified by any computer with the CSDT but cannot be forged by anyone that does not have the DMA private key(s), which is securely stored and managed by the DMA. Optionally, the DMA stores the cryptographically signed PDI device token into a database, that can later be used to verify messages signed by the PDI device or verify the issued certificates. The DMA returns the cryptographically signed PDI device token via a secure channel, like an HTTPS Internet connection to the requesting party. The PDI device, or other requesting party, uses a signature verification algorithm to prove the validity of the signature or to handle an error message. The cryptographically signed PDI device token and the corresponding PDI device private key is then stored in the PDI device credential. 
     A PDI device may request the license information from an operating drone. The cryptographically signed drone, drone operator, and PDI tokens may have been distributed, and communications between the controller and drone are authenticated and, optionally, encrypted. On power-up, the PDI device verifies the cryptographically signed PDI token. If this verification fails, the PDI device will enter a failure mode. The failure mode could include, but is not limited to, displaying an error to the operator on the drone/CPV operator&#39;s controller. 
     The PDI device makes a clear text request to the drone for an identification which includes a challenge. The challenge could include a random number or various other pieces of digital data. The drone may first verify the PDI device&#39;s license before complying with the request. To accomplish this, the drone sends a challenge request (random number or other digital data) to the PDI device. The PDI prepares a cryptographic response based on the combination of the challenge and the cryptographically signed PDI token and returns it to the drone. The drone verifies the PDI token validity and that the credential has not been revoked. The drone sends a visual to the user display indicating a PDI identification request has been made. This may include, but is not limited to, the user name, contact information, the PDI user ID, and PDI property boundaries. The random number from is forwarded to the drone operator credential. 
     Since PDI requests are not mandatory interrogations, a drone operator may decide whether to comply. Compliance can be manually approved by the user after receiving the request on the user&#39;s display. A user may desire to comply with requests to garner goodwill between the drone hobbyist community and the wider community. In some cases, a drone/CPV may be required to comply with a PDI request. For example, a drone license may be defined as a commercial or delivery class, which may be mandated responders for PDI requests (as determined by the FAA). This would be of particular interest to PDI users who are concerned with maintaining their privacy from commercial news agencies. The random number is combined with the drone operator credential and a cryptographically response is prepared and returned to the drone/CPV. The random number is combined with the cryptographically signed drone token and a cryptographic response is prepared and returned with the drone operator credential response to the PDI device. 
     At block  2205  the PDI device may generate a clear text request for identification of a CPV. In certain examples, aspects of the described operations may be performed by PDI device  705  as described with reference to  FIG.  7   . 
     At block  2210  the PDI device may transmit the clear text request to the CPV. In certain examples, aspects of the described operations may be performed by PDI device  705  as described with reference to  FIG.  7   . 
     At block  2215  the PDI device may receive a challenge from the CPV. In certain examples, aspects of the described operations may be performed by PDI device  705  as described with reference to  FIG.  7   . 
     At block  2220  the PDI device may generate a response to the challenge. In certain examples, aspects of the described operations may be performed by PDI authentication component  710  as described with reference to  FIG.  7   . 
     At block  2225  the PDI device may transmit the challenge to the CPV. In certain examples, aspects of the described operations may be performed by PDI device  705  as described with reference to  FIG.  7   . 
       FIG.  23    shows a flowchart  2300  of a process for authentication, authorization and secure communication in accordance with aspects of the present disclosure. In some examples, a relay Node may execute a set of codes to control functional elements of the relay Node to perform the described functions. Additionally or alternatively, a relay Node may use special-purpose hardware. 
     A DMA may verify the identity of a relay Node and issue a cryptographic token that can later be used to authenticate the relay Node&#39;s license. The DMA can be a public or private entity with a public key distribution system as well as secure private key(s). A cyber-physical vehicle management system includes verification components similar to the distribution system for digital rights management or digital certificate authorities. A DMA can be implemented to support a public key cryptographic scheme that is extensible to a large number of end-users, a revocation scheme that allows for informing end-users of cryptographic tokens that are no longer trusted, and a generation and issuing of scheme for verifiable CSDTs. 
     The CSDT is a token that is cryptographically signed by the DMA and includes information about the DMA as well as public key(s) from the DMA. The information the CSDT may include, but is not limited to, the cryptographic schemes used and necessary protocols or parameters. In a cyber-physical vehicle management system, the CSDT and all protocols for the DMA public key scheme are pre-installed, pre-distributed, or pinned to the relay Node in a secure manner. The CSDT may be stored in software or with trusted hardware Modules. Regardless, the CSDT, and corresponding algorithms, may be installed such that the processor that verifies credentials, can securely access it. Distribution of the CSDT should, ideally, be secure, which can be accomplished in software or hardware using various schemes, not discussed here. 
     A relay Node license may have a license linked to digital relay Node attributes. The relay Node attributes can include, but are not limited to, the relay Node&#39;s current location, mobility, radial range, usage rights (e.g. subscription), ownership (e.g. public or private) and date of installation. The relay Node license may include, but is not limited to, a class of license, the expiration date of the license, the issue date of the license, and a unique identifier. The relay Node license should be generated by a trusted third-party organization such as a government agency, for example the Federal Aviation Administration, or an independent organization. 
     When a new relay Node license is issued a verification process may be performed (e.g., by a DMA) before secure operation is possible. The relay Node license and relay Node attributes are stored in various locations which could include internally or external to the relay Node. A pair of cryptographic keys including a public key and private key are then securely generated for the relay Node. This can be done locally or via a third-party service. The details for generating cryptographic keys is dependent on the cryptographic algorithms later used. Ideally, for the relay Node, the key generation occurs on a local device (the relay Node or a secure hardware device). However, this process can occur with the license Authority or the DMA generating keys. At this point, the relay Node has generated all the necessary information to verify its identity to the DMA and receive a cryptographically signed relay Node token. A cryptographically signed relay Node token is a token that is cryptographically signed and allows for third-parties to verify the DMA signature if they have the CSDT. The cryptographically signed relay Node token also stores the public key for the relay Node enabling two functions. First, the relay Node public key can be used to encrypt data which someone with the relay Node operator private key can decrypt. Second, the relay Node private key can be used to sign data which can be verified by the relay Node public key. The relay Node private key is able to produce signatures that will be correctly verified by the corresponding relay Node public key. 
     To receive a cryptographically signed relay Node token the relay Node license, relay Node attributes, and associated public key are sent via a secure channel, such as an HTTPS Internet channel, to the DMA. The DMA verifies the relay Node license and relay Node attributes either locally, if capable, or through the issuing organization, such as the FAA. If any of the relay Node attributes do not match the relay Node license then the license is not signed and is returned to the license requestor with an error message. Optionally, if a cryptographically signed relay Node token has already been issued for a relay Node license the process aborts. The DMA then uses a cryptographically secure signature algorithm with the DMA private key to produce a cryptographically signed relay Node token. This token includes the relay Node attributes, relay Node license, and the relay Node public key. This token can be verified by any computer with the CSDT but cannot be forged by anyone that does not have the DMA private key(s), which is securely stored and managed by the DMA. Optionally, the DMA stores the cryptographically signed relay Node token into a database, that can later be used to verify messages signed by the relay Node or verify the issued certificates. 
     The DMA returns the cryptographically signed relay Node token via a secure channel, like an HTTPS Internet connection to the requesting party. The relay Node, or other requesting party, uses a signature verification algorithm (such as DSA, ECDSA, and RSA-PSS) to prove the validity of the signature or to handle an error message. The cryptographically signed relay Node token and the corresponding relay Node private key is then stored in the relay Node credential. 
     A fixed or mobile relay Node may request the status of drones in the local area, determined by the radio range or other means. A cyber-physical vehicle management system may provide for non-reputable communications from the responding drones to the relay Node. This protocol depends on the previous distribution of the CSDT to the relay Node and the responding drone(s) to have valid Cryptographically signed drone tokens. 
     The protocol starts when the relay Node generates an interrogation request with a cryptographically random nonce, or challenge. This request is sent via the relay Node&#39;s radio to all responding drones in radio range. When a drone receives a request packet the cryptographic challenge is combined with the current navigation data and part of the responding drone&#39;s cryptographically signed drone token. The exact contents of the response message will be determined by administering authorities but may include, and is not limited to, the following: GPS time, location, heading, airspeed, altitude, and drone ID. The output of the combination is then cryptographically signed using the responding drone/CPV&#39;s private key and sent via the responding drone&#39;s radio to the relay Node. The relay Node verifies multiple aspects of the response packet. The responses are stored in a local database and can be used for regional navigation. 
     The relay Node can also verify the data from drones/CPVs using a database of cryptographically signed drone tokens. First, the relay Node requests the cryptographically signed drone token from the DMA corresponding to the drone&#39;s ID. Second, the relay Node verifies the response packet is legitimately signed signature using the responding drone&#39;s public key. 
     Relay Nodes can be installed or operated by governmental agencies as a part of the nation&#39;s critical infrastructure, known as public relay Nodes. These will be installed in major metropolitan cities and other high traffic or high potential casualty areas. Private relay Nodes can be owned by individuals or private organizations and may exist as open or closed relay Nodes. A closed relay Node is a Node that has restrictive access requirements based on specific drone license attributes. An individual can set up her own closed relay Node to enhance her own flight. The relay Node in this case would provide data to a drone/CPV with the correct ID, namely her ID. An organization can install and operate a closed private relay Node to enable a subscription-based network of relay Nodes. Drone operators would pay a fixed or ongoing service fee to allow their drones to access the sensor or network data on the closed private relay Node(s). Open private relay Nodes can be owned by individuals or private organizations and function similarly to public relay Nodes in that they provide open access to any drone operator with the exception of blacklisted drones that have been identified as undesirable either because they have abused the system, exist for nefarious use, or put a strain on the system due to their bandwidth needs. 
     A relay Node may broadcast beacon messages allowing nearby drones to establish authenticated, and optionally encrypted, communications. Relay Nodes are a broad class of devices that include, but are not limited to, Internet gateways, weather stations, local air traffic control Nodes, and ad hoc network Nodes. In the case of a relay Node operating as an Internet gateway, its primary purpose is to provide Internet connectivity to drones allowing, for example, real time traffic management, weather data, and updated flight plans. Internet connected, authenticated relay Nodes could also provide updated revocation lists mitigating the impact of rogue ADC devices. Relay Nodes can also operate as stand-alone (not connected to the Internet) information brokers. This could include a relay Node with weather sensors reporting changing conditions or a relay Node brokering local airspace and optimizing flight paths of drones/CPVs. For either of these operations, a trust in the relay Node may be desired. 
     A cyber-physical vehicle management system could be extended to allow for an ad hoc network of relay Nodes to provide wide-spread Internet access across relay Nodes. Since drones can operate as relay Nodes, this means that drones could form an ad hoc network for improved Internet connectivity over-ground-station-only options. Whether Internet connected, nodal networked, or isolated, a relay Node can provide local current and forecasted weather data (e.g. wind direction and speed, humidity, and temperature), emergency warnings, no-fly zones, drone activity, congestion, and obstacles. 
     Another optional feature of a relay Node is to provide positioning data to drones. Drones can conceivably operate in two manners. First, the drone could have high-precision position data (i.e. GPS or Iridium). Second, the drone could have relative position data, where the drone relies on external Nodes to correct its position and inertial data for real time correction. For the second class of drones, which we refer to as inertial navigation drones, an essential service of the relay Node is to provide high quality positioning data. There are various techniques that can provide this type of data including various RF distance bounding, triangulation, and trilateration. Since it is likely that relay Nodes will contain GPS data combining this with other localization techniques can provide reasonable position data. Inertial navigation drones will make use of collision avoidance sensors and drone-to-drone and drone-to-plane communication, such as in-flight routing negotiation. Inertial navigation drones can fly safely in areas reserved ahead of time or in areas with limited air traffic. 
     Relay Nodes can also be configured into a passive mode for monitoring. A monitoring mode allows for a relay Node to operate similar to current skyscanner technologies. In the passive mode, the relay Node listens for any beacons from other devices including, but not limited to, drones, PDI devices, ADC devices, or other relay Nodes. This mode allows for monitors to be deployed to monitor and track drone deployment. This allows for civilian and government organizations to monitor drone traffic and provide a necessary level of transparency. 
     To establish authenticated, and optionally secure communications, the relay Node sends out beacon messages at intervals. The intervals can be periodic or adaptive, the specific implementation is left to the realization. The beacon messages are broadcasted via wireless links and received by each receiving device. The potential receiving devices can include, but are not limited to, drones, other relay Nodes, and ADC devices. Since the relay Node is providing a service, responding to beacons is completely optional with responses requested when an authenticated communications link is desired. The beacon message may contain, but is not limited to, a timestamp, the relay Node&#39;s unique ID, a list of available services (e.g. weather, air traffic control, ad hoc mode, Internet connectivity), and a list of supported connection types (e.g. ADC, relay Node, commercial drone, government drone, hobbyist drone, subscriber). 
     A drone/CPV that desires to establish a connection listens for beacons. Upon receiving a beacon, the drone assesses whether the necessary services and connection types are available. If the relay Node is sufficient for the drone&#39;s need requirements, then it will prepare a challenge to verify the relay Node&#39;s identity. The challenge includes a random nonce, which can be generated based on a timestamp, a software based random number generator, a hardware based random generator, or any other cryptographically random source. The challenge can also include, but is not limited to, the drone information, the drone public key, the drone license information, and desired connection type. The challenge is sent wirelessly to the relay Node. 
     Upon receiving the challenge, the relay Node first verifies that it can provide the requested connection type or that it can request the information from another Node. If it cannot, it sends a failure message to the drone. If it can provide the requested connection, the relay Node extracts the random nonce in the drone&#39;s challenge to prepare an authenticated response. A realization of this protocol should use anti-denial-of-service techniques to mitigate flooding, but this is orthogonal. The response includes, but is not limited to, a second random nonce, the cryptographically signed relay Node token, and may include the random nonce from the drone&#39;s challenge. The relay Node signs the response with its private key and returns it to the drone via the wireless link between the relay Node and drone/CPV. 
     Upon receiving the relay Node&#39;s response, the drone uses the DMA public key(s) to verify the validity of the cryptographically signed relay Node token. The relay Nodes public key can then be used to verify the signature on the response packet. If all signatures are correctly verified the drone may authenticate to the relay Node. The drone uses the nonce provided by the relay Node and prepares an authenticated response. The response includes the cryptographically signed drone token and the nonce. A cryptographic response is prepared using the drone&#39;s private key and returned to the relay Node via the wireless link. The cryptographic response is verified and by the relay Node. Authorization can then occur in one of two ways. The first, allows the relay Node to locally decide which connections to authorize. The second, connects to an authentication and authorization server for decision making. 
     For local authorization, the relay Node has a set of rules to determine which drones are allowed to connect. These rules could restrict connection to a particular type of license, a particular amount of use, or a particular class of owners. The specifications are left to an implementation decision. For external authorization, the cryptographically signed drone token is sent to an authorization server over a secure connection. The authorization server maintains a list of authorized users or a set of rules to validate users. The authorization server uses these rules to provide a yes/no authorized decision which is returned to the relay Node. The relay Node provides services based on this yes/no decision, although may be legally required to provide a limited range of services or data nominally or in an emergency situation. 
     Once the drone/CPV has been authenticated and authorized properly the relay Node and drone have shared public/private keys. These public/private key pairs allow for the bi-directional exchange of encrypted and authenticated messages between drone and relay Node. One possible approach would be for the relay Node and drone to exchange encrypted private keys allowing for future symmetric cryptography. Now that cryptographic keys have been securely distributed, bi-directional, authenticated, and optionally encrypted communications can occur. 
     At block  2305  the relay Node may generate an interrogation request. In certain examples, aspects of the described operations may be performed by relay Node authentication component  610  as described with reference to  FIG.  6   . 
     At block  2310  the relay Node may transmit the interrogation request to CPVs within a geographic area. In certain examples, aspects of the described operations may be performed by relay Node  135  and  605  as described with reference to  FIGS.  1  and  6   . 
     At block  2315  the relay Node may receive a response from a CPV. In certain examples, aspects of the described operations may be performed by relay Node  135  and  605  as described with reference to  FIGS.  1  and  6   . 
     At block  2320  the relay Node may verify the response from the CPV. In certain examples, aspects of the described operations may be performed by relay Node authentication component  610  as described with reference to  FIG.  6   . 
       FIG.  24    shows a diagram  2400  of a CPV detection and intervention system that supports identification, detection, capture, seizure, and immobilization of CPV systems in accordance with aspects of the present disclosure. Diagram  2400  may include controlled area  2405 , CPV  2410 , CPV controller  2435 , and CPV detector  2450 . 
     In some cases, a CPV  2410  may encroach on geographically controlled area  2405 , which may interfere with the operations of law enforcement, emergency response, or other authorized operations. The controlled area  2405  may be the site of a natural disaster, a crime scene, a sensitive location such as a nuclear power plant, or any other geographic location where restricting CPV activity is desired. 
     CPV  2410  may be an example of a plurality of vehicles, each vehicle including a computing device having a unique identity and an operator associated with the vehicle; each vehicle configured to forward the challenge to the vehicle operator controller; prepare a cryptographic vehicle response based on the operator response, the challenge and a vehicle token stored on the vehicle; and send, from the vehicle to the authoritative command device, the vehicle response and the operator response. CPV  2410  may incorporate aspects of CPV  105  and  305  as described with reference to  FIGS.  1  and  3   . In some examples, CPV  2410  may include CPV computing device  2455 , CPV protocol  2420 , CPV transmitter/receiver  2425 , and CPV battery  2435 . 
     A CPV  2410  may be a device such as a UAV or an autonomous car. The CPV  2410  may contains computing, sensing, GPS, movement, and communications subsystems. A CPV  2410  may also interact with other CPVs  2410 . A cyber-physical vehicle management system may enable an identity management scheme for authenticated communications between CPVs  2410  and other devices. 
     The CPV  2410  can be any electro-mechanical device intended to move through space under partially or fully automated control. In some cases, the CPV  2410  may be a component of a CPVS. A CPVS may include a CPV  2410  and a CPVN (secondary cyber-physical systems and subsystems that support the functionality and application of the CPV). For example, CPVN might be a weather station one-way communicating to the CPV  2410 , it may be a remote controller operated by a human that is providing one-way communication for control, or it may be a two-way communication such as the case of an aerial CPV  2410  (e.g. drone) coordinating its flight plan with an automated ground station. 
     The CPV  2410  may communicate with radio signals to other systems such as other CPVs  2410  (e.g., in the case of drone swarms). This communication could be to coordinate with each other or simply as one-way communication broadcasting the CPV&#39;s existence (and possibly location and other relevant data). CPVs  2410  may utilize either one-way receive radio signal communication (e.g. control), one-way send radio signal communication (e.g. data), or two-way send and receive radio signal communication. CPVs  2410  may be unmanned in that they lack a human operator within the vehicle (such as drones, remote controlled cars, and bomb disposal robots), but they may have a human controlling them or receiving data from them from afar using radio signals from a CPV  2410  Node (e.g. a control station, controller, computer). 
     CPVs  2410  may have humans internally acting as either an operator (e.g. an autonomous car like) or as a non-operator (e.g. a sky taxi where the human is an occupant). Radio signals either going to or from the CPV  2410  may be detected using the CPV Detector  2450 . The CPV  2450  detector may be utilized to control and manage threats such as wirelessly remote-controlled devices, autonomous devices that have a telemetry and control wireless link, drones and robots. The CPV&#39;s components, such as the battery in this case, may transmit their own telemetry via a transmitter. 
     The CPV computing device  2455  may be configured for executing commands and sending telemetry via its TRX and antenna. The CPV computing device  2455  may encode and decode all communications using the same protocol as its CPV controller  2435 . 
     CPV controller  2435  is the remote controller for the wireless remote-controlled CPV  2410 . The CPV controller  2435  contains a controller processor  2440  that produces device control commands and reads CPV telemetry using the CPV manufacturer protocol for encoding and decoding. The CPV manufacturer specific protocols are available from an internal or external source. This protocol  2420  is the language with which the CPV controller  2435  and the remote controlled CPV  2410  communicate and by which the CPV controller  2435  commands its CPV  2410 . The CPV controller  2435  mandates the particular RF band channel for telemetry and control of the CPV  2410  itself via its TRX transceiver  2420  and antenna. The CPV  2410  receives commands only through the command channel set by its controller  2435 . Many CPVs  2410  have the ability to receive a plan for its behaviors that it will subsequently execute. Some CPVs  2410  still must receive commands one-at-a-time for sequential execution. In some examples, CPV controller  2435  may include controller processor  2440  and controller transmitter/receiver  2445 . 
     CPV detector  2450  may incorporate aspects of CPV detector  2505  as described with reference to  FIG.  25   . In some examples, CPV detector  2450  may include CPV-D computing device  2455 , protocol database  2460 , map database  2465 , CPV-D battery  2470 , radio receiver  2475 , radio transmitter  2480 , and geocoding subsystem  2485 . 
     The CPV-D computing device  2455  in some embodiments includes a processor  2490 , non-transitory memory  2492  coupled to the processor, and a plurality of applications  2494  configured to run on the processor. 
     In some cases, the database subsystems include the vehicle protocol database  2460  and the map database  2465 . In some cases, the CPV  2410  is an unmanned drone. The CPV Detector  2450  may include the radio receiver  2475  comprising hardware specially designed for receiving the specific type of communication or hardware that is designed to be software programmable that allows it to select a specific radio signal (e.g. frequency, channel, sub channel) to tune into. 
     Geocoding subsystem  2485  may determine a distance from a geocoding subsystem  2485  to the CPV  2410 ; determine a current location of the geocoding subsystem  2485 ; determine a bearing from the geocoding subsystem  2485  to the CPV  2410 ; and determine a location of the CPV  2410  based on the distance, the current location, and the bearing. Geocoding subsystem  2485  may incorporate aspects of geocoding subsystem  2535  as described with reference to  FIG.  25   . 
     In some cases, the geocoding subsystem  2485  is coupled to CPV-D computing device  2455  and may include a 3-axis MEMS gyroscope, at least one target spotting device, and a sub-meter GPS receiver. In some cases, the geocoding subsystem  2485  may be a target spotting device and may include at least one of an optical spotting scope and a visual-spectrum laser pointer. In some cases, the geocoding subsystem  2485  is detachable from the CPV detector  2450  system. 
     A geocoding subsystem  2485  may include a laser distancing component, a gyroscope (such as a MEMS gyroscope), a relative location device (such as a GPS receiver), an orientation device (such as a compass), and a distance measuring device (such as a laser rangefinder). Additional components might include a wireless external communication method (such as Bluetooth® or WiFi) and human interface device (such as a touchscreen display or keyboard). The geocoding subsystem  2485  has two primary functions: to determine the coordinates of an object that is within line of sight and to determine a measurement of an object. The following formulas (1-3) may be used to determine the coordinates of an object once the geocoding subsystem location is known (lat 1 , lon 1 ) and the geocoding subsystem orientation is known (tc in radians): 
       lat= a  sin(sin(lat1)*cos( d )+cos(lat1)*sin( d )*cos( tc ))  1)
 
       lon= a  tan 2(sin( tc )*sin( d )*cos(lat1),cos( d )−sin(lat1)*sin(lat))  2)
 
       lon=mod(lon1 −d lon+π,2π)−π  3)
 
       FIG.  25    shows a diagram  2500  of a CPV detector  2505  that supports identification, detection, capture, seizure, and immobilization of CPV systems in accordance with aspects of the present disclosure. 
     CPV detector  2505  may incorporate aspects of CPV detector  2450  as described with reference to  FIG.  24   , but may include additional elements that provide for functions of the CPV detector  2505  for identification, detection, capture, seizure, and immobilization of CPV systems. In some examples, CPV detector  2505  may include CPV-D computing device  2455 , protocol database  2515 , map database  2520 , radio receiver  2525 , radio transmitter  2530 , geocoding subsystem  2535 , detection component  2540 , identification component  2545 , threat assessment component  2550 , capture component  2555 , Seizure component  2560 , kinetic subsystem  2565 , and operator Module  2570 . In some cases, CPV detector  2505  may convert received data into plain text data or map data for display to an operator. 
     In some embodiments, one or more of the detection component  2540 , the identification component  2545 , the threat assessment component  2550 , the capture component  2555 , the seizure component  2560 , the kinetic subsystem  2565  and the operator Module are included in one of the plurality of the applications  2494  configured to run on the CPV-D computing device  2455 . 
     In some cases, the database subsystems include the vehicle protocol database  2515  and the map database  2520 . In some cases, the vehicle is an unmanned drone. The CPV Detector  2505  may include the radio receiver  2525  comprising hardware specially designed for receiving the specific type of communication or hardware that is designed to be software programmable that allows it to select a specific radio signal (e.g. frequency, channel, sub channel) to tune into. If a CPV  2410  is not actively transmitting a radio signal, then there may be nothing for the radio receiver  2525  to detect. In this case, a radio transmitter  2530  may be utilized. Some CPVs  2410  may respond upon being “pinged” (i.e. where information is directly or indirectly requested). 
     A direct request is when the radio transmitter  2530  requests specific data such as the current location of the CPV  2410 . An indirect request is when the CPV  2410  only communicates if other CPVs  2410  are around. The CPV  2410  may determine whether other CPVs are around based on radio transmissions. A radio transmitter  2530  may request data or transmit a radio signal that appear  2410  is to be another CPV  2410  in order to cause the CPV  2410  to transmit so that the radio receiver  2525  may receive the resulting signals. 
     In some cases, the CPV  2410  will be continuously transmitting and therefore only a radio receiver  2525  is used. In other cases, the CPV  2410  itself may or may not be transmitting while a CPV Node is transmitting to the CPV  2410 . In this case the CPV detector  2505  may use its radio receiver  2525  to receive the radio signals from the CPV Node, and to make a determination of what kind of CPV  2410  is nearby. 
     This may inform a CPV mitigator (i.e., such as the kinetic subsystem  2565 ) how to target a CPV  2410 . Use of a radio receiver  2525  alone to receive the radio signals from a CPV  2410  or CPV Node means that the CPV  2410  or CPV Node may have no way of knowing whether the radio signals it is transmitting (or that are meant for it) are being received by something else. Once the CPV detector  2505  detects radio signals from a subsystem of the CPVS, then it may demodulate the radio signals to get an ordered bit sequence. The bit sequence may be encrypted. In some examples, hardware that is specialized to decrypt that particular encryption may be used to decrypt the bit sequence. In other cases, hardware that supports software algorithms to dynamically decrypt the digital signal feed of the bit sequence may be used. 
     After this process of organizing and decrypting (if needed) is complete, then the data is visible in plain text. This plain text view of the packets may then provide real-time view of the data being sent from the subsystem of the CPVS. This data may include the CPV&#39;s manufacturer, model, software version number, unique identifier, current location (longitude, latitude, and altitude), live video feed, battery level, CPV&#39;s operator location, and flight plan. 
     This may then be presented to the operator of the CPV Detector  2505  in a GUI that can show the live data stream including the video feed and the location of the CPV represented on a two-dimensional or three-dimensional map. Depending on the CPV  2410 , this data can be accessed with only a radio receiver  2525  or some may require requesting the data using a radio transmitter  2530 . The CPV detector  2505  may use a radio transmitter  2530  to access the internal cyber components of subsystems of the CPVS such as the CPV  2410 . This can be done by evoking higher level privileges that may or may not be knowingly available to the operator of the CPV  2410 . Once the internal cyber components are accessed, then the radio transmitter  2530  can request data that is stored on the subsystem of the CPVS such as the CPV  2410  for this example. This data might be photographs, video recordings, logs, or software. 
     Once the CPV detector  2505  detects which frequency the radio signal is operating on, then the CPV detector  2505 , using the capture component  2555 , can transmit radio signals on that same frequency and channel with the correct timing to prevent the CPVS from internal communications, such as disrupting communication between a CPV Node (e.g., a ground control station) and a CPV (e.g., a drone). These transmissions may be done in a way to minimize possible interference with other radio signals used for communication by ensuring that only the exact subchannel of that frequency during an exact time has radio signals being transmitted. Once the CPV detector  2505  has disconnected the CPV  2410  from a CPV Node (or the CPV controller  2435 ), then CPV Detector  2505  (again using the capture component  2555 ) can transmit a radio signal that the CPV  2410  would expect to be coming from a CPV Node or controller  2435  and thus cause the CPV  2410  to take data from the CPV Detector  2555  as if it were an authorized CPV Node. 
     This data may be in the form of control commands that direct the CPV  2410  to do a particular action, which may mean transmitting a single command which initializes a pre-programmed action in the CPV  2410  or it may mean transmitting a stream of data that could be commands for the CPV  2410  to follow. This process may be used ensure that a CPV remains in a specified location, by making it stay in its current location, directing it to a location chosen by the operator of the CPV detector  2505  (e.g. selecting from a list or a point on a map), directing it to return to where it came from, or disabling it from continued operation. Once the CPV  2410  is at the specified location, it can be disabled. 
     The CPV detector  2505  can be programmed to have areas on a map (i.e. geofences) designated such that when a CPV  2410  is turned on or enters the designated area, then a preprogrammed action is taken by the CPV detector  2505  (also referred to as the CPV mitigatory). Such actions may be termed CPVS Disconnection or CPV Takeover. The areas designated on the map can be programmed by inputting at least three longitude and latitude coordinates to form a two-dimensional polygonal in space which can be displayed on a visual map. Additionally, at least one altitude can be inputted to create a three-dimensional polygonal. Inputs can be in a variety of forms such as an operator typing in the numbers or selecting points on a map. The CPV detector  2505  performs a threat analysis based on data it collects on each CPVS it detects. 
     The input data for the threat assessment includes, but is not limited to, monitoring of the live drone video feed, coordinates, altitude, distance/azimuth from pilot, vertical and horizontal speed, payload capacity, battery life, proximity to designated areas, signal strength to original pilot, coordinates where CPV was turned on, tracked movement pattern, past sightings of CPVS based on unique identifier. After analyzing the data using the threat assessment component  2550 , the CPV detector  2505  recommends a response to the operator of the CPV detector  2505  or can automatically perform a preprogrammed action. Threat analysis data is then logged by the threat assessment component  2550  and linked to the unique identifier. 
     The various components of the CPV detector  2505  may be included in a single housing, as shown in  FIGS.  24  and  25   , or may optionally may be split up into different housing, for example splitting off the capture/seizure/kinetic components of the CPV detector  2505 . The CPV detector  2505  itself contains several important components, physical and logical subsystems. There is, of course, the computing device  2455  that handles overall control of the CPV detection and intervention system itself, performing calculations, lookups, pattern matching, decoding of RF data streams by use of the right protocol, and even encoding of messages and commands by use of that protocol. There is the database system  2597 , including databases such as the protocol database  2515  and the map database  2520 , to handle important data and information to record or utilize in calculations and pattern matching, such as RF signature identification of a given protocol from a raw data stream. There can be multiple transmit and antenna components  2599  to track or command multiple intruders at the same time. 
     Further, the CPV detector  2505  contains the self-contained geocoding subsystem  2535  with an optical target spotting scope  2575  or visual-spectrum laser pointer (or both) aligned with the distance-finding laser Module. The subsystem  2535  also includes the distance measuring laser  2580 , the sub-meter GPS receiver  2585 , the 3 axis MEMS gyroscope  2590 , and the geocoding computing device  2595 . The “target” is spotted visually through the scope  2575 . The operator triggers the laser  2580 . The laser  2580  provides a distance to the target measurement. At that same instant, the 3-axis MEMS gyroscope  2590  provides a bearing from the CPV detector  2505  to that target. Finally, the sub-meter GPS receiver  2585  provides the position of the CPV detector  2505  itself. 
     With these three quantities, the geocoding subsystem processor  2595  can return the precise position of the target through a software algorithm designed for that purpose, stored on and configured to run on the computing device  2595 . The Geocoding Laser subsystem  2535  may also operate as a detachable, standalone device to visually choose a target and determine its position instantaneously. This subsystem  2535  can be embodied in many additional ways and utilized for many different purposes, only a few are considered in these examples and descriptions. In some cases, the CPV detector  2505  (also referred to as the CPV detection and intervention system) may operate in hazardous conditions that include risk to life or property. In this case, first responders may arrive at the scene and begin attempting to reduce, mitigate or eliminate the risks due to the hazardous situation within some geographic area. 
     Within this geographic area, they may instate an “exclusion zone” as a geofence, where only authorized personnel and authorized airborne devices are permitted to operate. Unauthorized wireless remote-controlled devices that intrude into the exclusion zone may present a threat to the Mission. The CPV detector  2505  may be deployed in the field to control or eliminate the threat of intruding devices. After successful intervention by the CPV detector  2505 , the original CPV controller  2435  has no communications and cannot command its CPV  2410 . 
     That is, the CPV detector  2505  has exclusive communications with and full control of the CPV  2410 . The threat CPV  2410  will be located at coordinates determined by the mission objectives, CPV detection and intervention system  2505  returns to detect mode to locate other threat CPVs  2410 , and CPV detection and intervention system  2505  continues performing parallel processes. 
     Radio receiver  2525  may incorporate aspects of radio receiver  340 ,  635 , and  2475  as described with reference to  FIGS.  3 ,  6 , and  24   . In some cases, the system comprises a radio transmitter  2530 . Radio transmitter  2530  may incorporate aspects of radio transmitter  345 ,  640 , and  2480  as described with reference to  FIGS.  3 ,  6   , and  24 . In some cases, the encoded transmissions to a vehicle (i.e., the CPV  2410 ) include a command to change a control and command channel for the vehicle to a specified channel. Geocoding subsystem  2535  may incorporate aspects of geocoding subsystem  2485  as described with reference to  FIG.  24   . 
     Detection component  2540  may detect a vehicle (i.e. CPV  2410 ) by receiving radio transmissions involving the vehicle and detect the vehicle comprises: using the radio transmitter  2530  to send radio transmissions to the vehicle, whereby the vehicle sends radio transmissions. 
     Identification component  2545  may create a unique identifier for the vehicle using at least a portion of the received data and compare the unique identifier to a plurality of unique identifiers included in a whitelist stored on the database system  2597 . 
     Threat assessment component  2550  may perform a threat assessment for the vehicle using at least a portion of the data. 
     Capture component  2555  (which may be a portion of a separate CPV mitigator) may use the data to decode and identify a protocol used to control the vehicle (CPV)  2410 ; query the vehicle  2410  for at least one of information about the vehicle  2410  and about vehicle activity, wherein the query is based on the vehicle protocol; encode transmissions to the vehicle  2410  using the identified protocol; send the encoded transmissions; take control of the vehicle  2410  based on sending the encoded transmissions; perform at least one of modifying, removing, and corrupting data stored on the vehicle  2410 ; shut down the vehicle  2410 ; and send transmissions to the vehicle  2410  such that communication between the vehicle  2410  and at least one controller  2435  of the vehicle is disrupted. 
     Seizure component  2560  (which may be a portion of a separate CPV mitigator) may determine a low-risk area; move the vehicle  2410  to the low-risk area; determine an obstacle-free path for the vehicle  2410 , wherein moving the vehicle  2410  to the low risk area is based on the obstacle-free path; move the vehicle  2410  to an original launch location of the vehicle  2410 ; and determine a target destination  2410  for the vehicle. 
     Kinetic subsystem  2565  (which may be a portion of a separate CPV mitigator) may target the CPV  2410  (in some embodiments in conjunction with the geocoding subsystem  2535 ) and launch at least one disabling charge  2567  at the vehicle  2410 . In some cases, the at least one disabling charge  2567  produces one of a low temperature fireball, a graphite cloud, a magnetic powder, and an adhesive coating. A CPV detector  2505  (or separate mitigatory) may include a kinetic subsystem  2565  with a common expendable launch vehicle  2566  and a variety of interchangeable charges  2567  to target critical elements common to all CPV  2410  especially those that fly, i.e., CPV visual systems, flight hardware, and propulsion systems. The kinetic subsystem  2565  targets and disables these critical flight systems using three interchangeable cartridges/charges  2567  that disperse specialty powders. 
     Unlike other kinetic systems that require extreme precision in delivery, are, bulky, have a long set-up time, or are limited in application, the kinetic subsystem  2565  delivers a customizable cloud of powder to defeat CPV threats within an effective range (e.g., within 2 or 3 km). 
     The kinetic subsystem  2565  may include a launch mechanism  2566  and payload disbursement system  2567 . The kinetic subsystem  2565  has the capability of providing a situation-dynamic solution to disable simple and advanced CPV threats, such as autonomous and cluster/swarms. Thus, the kinetic subsystem  2565  may utilize or include a CPV tracking system. This can be either a third-party system or a system paired with a CPV detector  2505 . 
     As a defeat mechanism, the kinetic subsystem  2565  may be a lightweight and inexpensive launch system, and interchangeable powder cartridge system to provide a viable solution to detect and defeat these classes of CPV threats by disabling video, flight control, or flight hardware systems. The kinetic subsystem  2565  has the potential capability of providing a situation-dynamic solution to disable autonomous and swarm CPV threats. 
     The cartridges (i.e., ammunition)  2567  of the kinetic subsystem  2565  may correspond to one of three components of a CPV: electronics, flight systems, and mission hardware. Thus, the kinetic subsystem  2565  have three or more interchangeable cartridges/charges  2567  to disrupt CPV missions, each of which target one specific critical component of the CPV  2410 . The charges  2567  exploit these inherent vulnerabilities by distributing a cloud of proprietary powder agents. 
     A first cartridge type may correspond to CPV electrical systems include motors for control surfaces, batteries, controllers, navigation systems, and cameras. Although many of these systems are frequently covered in conformal coatings that prevent direct attack, the kinetic subsystem  2565  can distribute powders that alter electrical and mechanical characteristics surrounding these systems to inhibit proper function. 
     A second cartridge type may correspond to flight systems: propellers, wings, casings, control horns, motors, engines, and other fine mechanical systems all need to be in near perfect condition to allow continued flight. These flight systems allow ample surface area for the kinetic subsystem  2565  to disable components. By heating or disrupting electrical signals to flight critical hardware, the kinetic subsystem  2565  can prevent continued controlled flight. 
     A third cartridge type may correspond to mission-specific payloads such as sensors (e.g. cameras), explosives, or electronic warfare weapons provide additional critical elements that can be inhibited by custom powders agents. 
     Thus, the various charge  2567  types may include generations of a low temperature fireball to deform flight surfaces and prevent flight, use of graphite or other fine particulate cloud to cover video systems and short circuit devices in flight applications, use of magnetic powder to stick inside motors and prevent movement, use of varying particulate size to precisely disable motors with specific rotor/stater gaps, use of particle size mixing to achieve macro-alloy effect, increasing effect of powders on motor movement, use of adhesive coating to further prevent motor movement, use of mixed powders to target multiple drone capabilities at once, use of shaped charges to accurately distribute powder while targeting specific drone systems, use of varying shape of charges to change swarm vs individual drone effect, use of varying shape of charges to affect fixed or rotor wing aircraft, or use of programmable delayed detonation rocket propelled charge for powder cloud delivery. 
     A targeting component of the kinetic subsystem  2565  may include use of RSSI for high speed tracking of CPVs, use of RF triangulation for active vehicle targeting, use of RSSI and RF combination for improved accuracy, and use of off-unit video processing for computer-driven guidance and tracking. Vehicle related aspects of the kinetic subsystem  2565  may include combining ducted fans and rocket engine to produce maneuverable yet fast delivery system, use of electrically driven RAM jet with solid rocket air heating mechanism, use of a spinning launch vehicle for lateral targeting using shaped charges, use of a laser range finder on spinning launch vehicle for mapping CPV locations, and use of field-swappable cartridge in missile-like launch vehicle. 
     Operator Module  2570  may receive commands from a user; display information to a user; display an alert when the vehicle is detected; and display a map including a location of the vehicle. 
       FIG.  26    shows a flowchart  2600  of a process for identification, detection, capture, seizure, and immobilization of CPV systems in accordance with aspects of the present disclosure. It will be understood that any of the CPV embodiments may be used in the CPV detector processes disclosed herein. In the present examples, the CPV detector of  FIG.  24    is generally used, but it will be understood that any suitable CPV detector embodiment may be used. 
     In some examples, the CPV detector  2450  may execute a set of codes to control functional elements of the CPV detector  2450  to perform the described functions. Additionally or alternatively, a CPV detector  2450  may use special-purpose hardware. 
     CPV detector operations may include several phases or modes. The first mode, initialize, is where the CPV detector  2450  becomes operational by turning it on. The second phase, detect, is the CPV detection and intervention system operating to scan the remote control RF spectrum for any signal activity that would indicate a remote control device  2410  within range. When activity is detected, the CPV detector  2450  receives an alert to the potential presence of an intruder. The third phase, identify, operates to gather relevant information about the signal or CPV  2410  in order to enable the CPV detector  2450  to make decisions about the following phases to capture and seize the device when it is deemed necessary. In this phase, the CPV  2410  is identified either as “whitelisted” and requiring no further action, or as a threat that does require further action. The fourth phase, capture, enables the CPV detector  2450  to cut off the threat device&#39;s original CPV controller  2435  and take full control of the threat device exclusively for further commands consistent with mission requirements. The fifth phase is the seize or relocation phase, where the CPV detector  2450  may exercise it full command and control of the threat device in order to lower the risks it presents to the mission. It enables the physical manipulation of the CPV  2410  to perform this task. The sixth phase, deactivate, is where the threat device  2410  has been commanded to a low risk location for shutdown and possible physical examination to determine ownership and seizure by authorities for any further actions deemed necessary. 
     At block  2605  the CPV detector  2450  may perform initialization sequence. In certain examples, aspects of the described operations may be performed by CPV detector  2450  and  2505  as described with reference to  FIGS.  24  and  25   . 
     At block  2610  the CPV detector may detect an unauthorized CPV  2410 . In certain examples, aspects of the described operations may be performed by detection component  2540  as described with reference to  FIG.  25   . 
     At block  2615  the CPV detector  2450  may identify the unauthorized CPV  2410 . In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  2620  the CPV detector  2450  may capture the unauthorized CPV  2410 . In certain examples, aspects of the described operations may be performed by capture component  2555  as described with reference to  FIG.  25   . 
     At block  2625  the CPV detector  2450  may seize and relocate the unauthorized CPV  2410 . In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
     At block  2630  the CPV detector  2450  may deactivate the unauthorized CPV. In certain examples, aspects of the described operations may be performed by capture component  2555  as described with reference to  FIG.  25   . 
       FIG.  27    shows a ladder diagram  2700  of a process for identification, detection, capture, seizure, and immobilization of CPV systems  2410  in accordance with aspects of the present disclosure. In some examples, a CPV detector  2450  may execute a set of codes to control functional elements of the CPV detector to perform the described functions. Additionally or alternatively, a CPV detector  2450  may use special-purpose hardware. 
     The system embodiment of  FIG.  26    include four main components: the CPV detector  2450 , an operator Module  2570 , the CPV  2410 , and the CPV controller  2435 . Although the operator Module  2570  is illustrated in  FIG.  27    as a separate element for process purposes, it will be understood that the operator Module  2570  will typically be included in the CPV  2505  as shown in  FIG.  25   . 
     The main components will receive or send various messages to each other, directed or broadcast. The CPV detector  2450  may, among other things, receive an alert message when a potential intruder is detected. The CPV detector  2450  must also remain informed of critical intruder data via a display coupled to the operator Module  2570 . The process begins by receiving broadcast telemetry from either the CPV  2410 , the CPV controller  2435 , or possibly an active subsystem of the CPV  2410  that is detected on the remote control RF channel. The CPV detector  2450  proceeds to identify enough about the CPV  2410  itself (and possibly the CPV controller  2435 ) to label it a threat (or not) and to determine the appropriate manufacturer protocol to encode and decode telemetry messages to and from the threat device. 
     Eventually, during capture, the CPV detector  2450  captures control of the threat device from the CPV controller  2435  so that the controller  2435  cannot reconnect and the CPV detector  2450  control is exclusive. During the seize phase the threat is commanded by the CPV detector  2450  to physically relocate, in a low risk path, to a low risk location to deactivate in the next deactivate phase. The CPV (intruder, threat)  2410  broadcasts telemetry on one of the remote control channels for the CPV detector  2450  to hear and analyze. The CPV  2410  eventually changes its channel in response to a command by the CPV detector  2450  during the capture phase, cutting off its own controller  2435  from all contact. Then, during seize, the threat is commanded to move by a low risk path to a low risk destination for eventually shutdown, deactivate. The original CPV controller  2435  has an open communication channel to the threat up to the point where the CPV detector  2450  commands the threat to change its command and control channel, when its controller  2435  becomes impotent. 
     The deactivation phase is the final phase. At this phase, the threat device (CPV)  2410  has been detected, identified, captured, and seized. The threat device  2410  has been brought to the target location, and may be still running and operational. The threat device  2410  may now be commanded to shut down entirely so that it is no longer available for commands or movement through radio signals. 
     In some cases, prior to deactivation, the threat device  2410  may be located at a target destination. After successful deactivation of the threat device  2410 , it may be available for legal seizure by law enforcement. 
     At block  2705  the operator Module  2570  may power the CPV detector  2450  ON. In certain examples, aspects of the described operations by the operator Module  2570  may be carried out by other components of the CPV detector  2450 . 
     At block  2710  the operator Module  2570  may display operation options, including an automatic operation option. 
     At block  2715  the operator Module  2570  may select an operation option. 
     At block  2720  the CPV detector  2450  may perform a radio scan. 
     At block  2725  the CPV controller  2435  may transmit command messages. 
     At block  2730  the CPV  2410  in response to the CPV controller  2435  may transmit telemetry information. In certain examples, aspects of the described operations may be performed by CPV  105 ,  305 , and  2410  as described with reference to  FIGS.  1 ,  3 , and  24   . 
     At block  2735  the CPV detector  2450  may detect the CPV  2410  transmissions. 
     At block  2740  the CPV detector  2450  may alert the operator regarding the operator Module  2570 . 
     At block  2745  the CPV detector  2450  may identify the CPV protocol. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  2750  the CPV detector  2450  may perform a CPV interrogation. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  2755  the detector  2450  may receive device identification information. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  2760  the operator Module  2570  may display the identification information. 
     At block  2765  the CPV detector  2450  may change a control channel of the CPV. In certain examples, aspects of the described operations may be performed by capture component  2555  as described with reference to  FIG.  25   . 
     At block  2770  the CPV detector  2450  may communicate with the CPV  2410  using the changed control channel. In certain examples, aspects of the described operations may be performed by capture component  2555  as described with reference to  FIG.  25   . 
     At block  2775  the CPV controller  2435  may lose control of the CPV. In certain examples, aspects of the described operations may be performed by CPV controller  2435  as described with reference to  FIG.  24   . 
     At block  2780  the detector  2450  may determine a target destination. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
     At block  2782  the detector  2450  may select a path. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
     At block  2784  the C detector  2450  may relocate the CPV by transmitting control commands using the changed control channel. In certain examples, aspects of the described operations may be performed by seizure component  2560  as described with reference to  FIG.  25   . 
     At block  2786  the detector  2450  may deactivate the CPV. In certain examples, aspects of the described operations may be performed by capture component  2555  as described with reference to  FIG.  25   . 
       FIG.  28    shows a flowchart  2800  of a process for identification, detection, capture, seizure, and immobilization of CPV systems in accordance with aspects of the present disclosure. In some examples, a CPV detector may execute a set of codes to control functional elements of the CPV detector to perform the described functions. Additionally or alternatively, a CPV detector may use special-purpose hardware. 
     Upon activation, the CPV detection and intervention system may enter an initialization phase. The system may power up and undergo an initialization sequence prior to entering the detect mode. The operator may press an ON switch, determine that all systems are operational: that a battery voltage is in range, that a CPU is operational, that a touch display is operational, that a transceiver is operational, and that other systems are operational. The CPV detection and intervention system may be operated (and sometimes physically held) by an operator who may be legally authorized to use one or more of the available features. 
     Initialization is the first phase or mode of operation of the CPV detector: it is switched to ON and goes through its own checks to indicate it is fully operational. Upon initialization, the operator is given choices of several modes: for example, Detection and Auto (auto detection through deactivation). Any wireless remote control devices within range can be detected and an alert issued to the CPV detection and intervention system. 
     At block  2805  the CPV detector may power up all subsystems. In certain examples, aspects of the described operations may be performed by CPV detector  2450  and  2505  as described with reference to  FIGS.  24  and  25   . 
     At block  2810  the CPV detector may display message indicating operational status. In certain examples, aspects of the described operations may be performed by operator Module  2570  as described with reference to  FIG.  25   . 
     At block  2815  the CPV detector may display operation options, including an automatic operation option. In certain examples, aspects of the described operations may be performed by operator Module  2570  as described with reference to  FIG.  25   . 
     At block  2820  the CPV detector may identify operation option. In certain examples, aspects of the described operations may be performed by operator Module  2570  as described with reference to  FIG.  25   . 
     At block  2825  the CPV detector may initiate detection phase. In certain examples, aspects of the described operations may be performed by CPV detector  2450  and  2505  as described with reference to  FIGS.  24  and  25   . 
       FIG.  29    shows a diagram  2900  of a CPV detection phase in accordance with aspects of the present disclosure. Diagram  2900  may include controlled area  2905 , CPV  2910 , CPV controller  2915 , and CPV detector  2920 . 
     In some cases, CPV  2910  may encroach on geographically controlled area  2905 , which may interfere with the operations of law enforcement, emergency response, or other authorized operations. The controlled area  2905  may be the site of a natural disaster, a crime scene, a sensitive location such as a nuclear power plant, or any other geographic location where restricting CPV activity is desired. 
     CPV  2910  may emit radio signals  2912  (e.g., to transmit telemetry data to CPV controller  2915 ). CPV detector  2920  may receive these signals and determine that CPV  2910  is located within the controlled area  2905 . 
     CPV  2910  may incorporate aspects of CPV  105 ,  305 , and  2410  as described with reference to  FIGS.  1 ,  3 , and  24   . CPV controller  2915  may incorporate aspects of CPV controller  2435  as described with reference to  FIG.  24   . CPV detector  2450  may be operated by law enforcement personnel, a first responder, or another authorized user and may incorporate aspects of CPV detectors  2450  and  2505  as described with reference to  FIGS.  24  and  25   . 
     The CPV detector (authorized operator) includes the self-contained device or has it nearby, initialized and operating in detect mode. The CPV detector receiver scans all remote control device bands and channels for activity that could possibly be a remote-controlled device. The computing device of the CPV detector  2920  performs RF analysis to determine whether the detected activity is related in any way to remote controlled devices. If so, it issues an alert to a CPV detector operator  2925 . The detection is indicated on the display screen of the CPV detector with a list of any others that may also have been detected or are currently being tracked. 
       FIG.  30    shows a flowchart  3000  of a process for identification, detection, capture, seizure, and immobilization of CPV systems in accordance with aspects of the present disclosure. In some examples, a CPV detector may execute a set of codes to control functional elements of the CPV detector to perform the described functions. Additionally or alternatively, a CPV detector may use special-purpose hardware. 
     After the initialization phase, the CPV detector may enter the detect phase or mode in order to detect any incoming threats (i.e., unauthorized CPVs  2910 ). That is, the system may detect remote controlled CPV activity and Alert operator to all active wireless remote control devices in range. In the detect mode, a receiver may scan all remote control device channels in each remote control device band. Such channels and bands may be normally assigned for certain uses and given protocols for use. A receiver radio may be capable of scanning outside these normal channels and bands as necessary. The receiver radio may scan all channels for device accessory communications such as battery, video stream and other subsystems of the CPV  2910  that emit RF independently of their own. A CPV detector computing device may then perform RF analysis to determine the existence of device activity on channel n, band x that can be attributed to device operation or operation of device peripherals/accessories. If device activity is found, the CPV detector immediately indicates to operator an alert to the existence of an active device in range. The alert may include text, lights, sounds and/or vibrations. 
     An operator may manually choose option to proceed to the identify phase, or to merely monitor the activity and go no further. If the CPV detector  2920  is in auto mode, then it may automatically proceed to the identify phase. In some cases, a map is provided on a display for the operator, where all location information and identity information are provided on a topographical map of the area for the operator to keep track of the threats being tracked. 
     After the detect mode, the CPV detector may log a wireless remote control device activity on a give channel (e.g., channel n and band x). An operator may be alerted to the presence of any device, device accessory or device controller in range. Detected CPVs are listed on a display, e.g., on a topographical map of an in-range area. 
     At block  3005  the CPV detector may receive radio transmission from a CPV. In certain examples, aspects of the described operations may be performed by detection component  2540  as described with reference to  FIG.  25   . 
     At block  3010  the CPV detector may feed the radio transmission to the processor. In certain examples, aspects of the described operations may be performed by detection component  2540  as described with reference to  FIG.  25   . 
     At block  3015  the CPV detector may alert a CPV detector operator. In certain examples, aspects of the described operations may be performed by operator Module  2570  as described with reference to  FIG.  25   . The CPV detector operator  2925  may be as shown in  FIG.  29     
     At block  3020  the CPV detector may present detection options to CPV operator. In certain examples, aspects of the described operations may be performed by operator Module  2570  as described with reference to  FIG.  25   . 
     At block  3025  the CPV detector may identify detection option. In certain examples, aspects of the described operations may be performed by operator Module  2570  as described with reference to  FIG.  25   . 
     At block  3030  the CPV detector may initiate identification phase. In certain examples, aspects of the described operations may be performed by CPV detector  2450  and  2505  as described with reference to  FIGS.  24  and  25   . 
       FIG.  31    shows a flowchart  3100  of a process for identification, detection, capture, seizure, and immobilization of CPV systems in accordance with aspects of the present disclosure. In some examples, a CPV detector may execute a set of codes to control functional elements of the CPV detector to perform the described functions. Additionally or alternatively, a CPV detector may use special-purpose hardware. 
     Once an intruder CPV is detected, the CPV CPV detector may enter an identification mode or phase. If the identification mode is chosen (manually or by an auto mode sequence), the RF data stream from that detected Intruder is analyzed for all identifying information to be collected and displayed to the CPV detection and intervention system. Identification information, at the outset, may even be a video stream that is then displayed to the CPV CPV detector in order to determine whether the device poses a threat or has malicious intentions so that the operator will continue to identify and then transition to capture right through deactivation. This is the passive identification mode, i.e., identification by mere passive “listening” to the data stream. The CPV detector computing device continues a thorough RF analysis to see if it can determine a match between the RF pattern it observes and RF patterns known to be derived from given manufacturer&#39;s protocols (e.g., using a protocol database). Once the correct protocol is determined for that Intruder, the CPV detector computing device can decode its telemetry data for any other identifying details such as GPS location, Flight Plan, Point of Launch, and battery condition (operating time remaining). Further, with this protocol, the CPV detector computing device can now encode messages and commands to the intruder that it will process just as it would process messages and commands from its CPV controller. 
     Thus, the CPV detector may perform passive, receiver only RF analysis on a stream of CPV data. The CPV detector derives information by passively analyzing the raw data stream being received. The data stream may be scanned for patterns/signatures in order to match it with typical patterns. The CPV detector then determines whether the data stream is from a CPV, CPV controller, or CPV accessory. If the data is from a CPV or CPV controller, the CPV detector may determine a correct protocol by RF analysis. If a CPV detector identifies a match with data patterns/signatures of known drone manufacturer communication protocols, it may infer that this is the protocol being used by the CPV. Once the protocol is determined, the CPV detector may use the protocol to decode drone packets (chunks of information in the data stream) and perform drone packet content analysis for anything of interest. 
     At block  3105  the CPV detector may identify RF signature for a CPV or a CPV controller. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  3110  the CPV detector may perform RF analysis on the CPV or the CPV controller. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . If the analysis indicates the presence of a CPV, the process may proceed to block  3115 . Otherwise, the process may proceed to block  3150 . 
     At block  3115  the CPV detector may identify a communications protocol for the CPV or the CPV controller. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  3120  the CPV detector may decode CPV communications. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  3125  the CPV detector may identify identification information. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  3130  the CPV detector may display identification information. In certain examples, aspects of the described operations may be performed by operator Module  2570  as described with reference to  FIG.  25   . 
     At block  3135  the CPV detector may determine whether the CPV is a threat. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . If the CPV is a threat, the process may proceed to block  3140 . Otherwise, the process may proceed to block  3145 . 
     At block  3140  the CPV detector may perform active interrogation. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  3145  the CPV detector may return to detection phase. In certain examples, aspects of the described operations may be performed by detection component  2540  as described with reference to  FIG.  25   . 
     At block  3150  the CPV detector may continue to monitor for the CPV. In certain examples, aspects of the described operations may be performed by detection component  2540  as described with reference to  FIG.  25   . 
       FIG.  32    shows a flowchart  3200  of a process for identification, detection, capture, seizure, and immobilization of CPV systems in accordance with aspects of the present disclosure. In some examples, a CPV detector may execute a set of codes to control functional elements of the CPV detector to perform the described functions. Additionally or alternatively, a CPV detector may use special-purpose hardware. 
     Once an intruder CPV is passively detected, the CPV detection and intervention system may enter an active identification mode or phase. The CPV CPV detector issues properly encoded queries and receives requested information to be decoded and displayed to the operator. At this point, the CPV CPV detector has the option to take full command of the device and to completely eliminate any further control or connection with its original controller. If this is desired by the CPV CPV detector or is in auto mode, it requires a transition to capture mode. 
     Thus, the CPV detector may be used to gather and record information from a CPV relevant to identification. The system may use RF analysis of a CPV communications stream to derive correct communications protocol in order to decode details of device broadcast communications (i.e., deep packet inspection). 
     Prior to active identification, the CPV CPV detector may be located in range for receiving CPV communications. The CPV detector computing device may have onboard access to a database of remote controlled device manufacturers and the protocols that they established for their device-to-device or device-to-controller communications and commands. The CPV detector may have detected radio activity on a given radio channel, and accessed a main control communication channel for CPV, CPV controller, or CPV Node. 
     During active identification, the CPV detector may use an identified communication protocol to actively (i.e., using a radio transmitter) communicate with the CPV itself, i.e., query the drone/CPV for any and all information about itself that is available. The scope of the communication may be limited by the manufacturer&#39;s protocol as to the information available for queries. During active identification, the CPV detector may transmit inquiries to the CPV for launch location, destination, other information. The CPV detector may then notify the operator of critical ID information including: a CPV profile, text information, map/location information, and whether the CPV is classified as a threat. 
     The operator may then be given a choice to enter the capture phase or to proceed with detection or identification of other CPVs. For example, the CPV detector may go back to detecting drones in general, and merely track the current CPV (i.e., since it is whitelisted). After active identification, a communication link is established, and the CPV detector may have the same control over the CPV as the CPV controller. However, the CPV remains under the control of the CPV controller. 
     At block  3205  the CPV detector may transmit active query to the CPV for identification information. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  3210  the CPV detector may receive response from the CPV. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  3215  the CPV detector may log response information. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  3220  the CPV detector may display response information. In certain examples, aspects of the described operations may be performed by operator Module  2570  as described with reference to  FIG.  25   . 
     At block  3225  the CPV detector may determine whether the CPV is a threat. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . In some cases, the process may proceed to block  3230 . If the device is in auto mode, it may automatically proceed to block  3235 . If the CPV is not a threat (i.e., it is whitelisted), the process may proceed to block  3240 . 
     At block  3230  the CPV detector may perform operator selection procedure. In certain examples, aspects of the described operations may be performed by identification component  2545  as described with reference to  FIG.  25   . 
     At block  3235  the CPV detector may initiate capture phase. In certain examples, aspects of the described operations may be performed by capture component  2555  as described with reference to  FIG.  25   . 
     At block  3240  the CPV detector may return to detection phase. In certain examples, aspects of the described operations may be performed by detection component  2540  as described with reference to  FIG.  25   . 
       FIG.  33    shows a flowchart  3300  of a process for identification, detection, capture, seizure, and immobilization of CPV systems in accordance with aspects of the present disclosure. In some examples, a CPV detector may execute a set of codes to control functional elements of the CPV detector to perform the described functions. Additionally or alternatively, a CPV detector may use special-purpose hardware. 
     Once a CPV has been fully identified, the CPV detector may enter capture phase or mode. Capture corresponds to the full and exclusive command and control of the intruder. Capture may be accomplished by issuing a command to the CPV to change command and control channel to reduce interference problems on current channel” (a fairly common controller command in channel interference cases.) The original CPV controller does not process this command since it may not have the capability to process commands issued to it. In some case, the command appears to be coming from the original CPV controller. Therefore, the original CPV controller may have no indication that the command and control channel has changed and will remain on its channel with no knowledge of the change. Meanwhile, the CPV has changed its command and control channel to the one commanded exclusively by the CPV CPV detector, so the CPV detector becomes the exclusive controller for the intruder now, fully capable of command and control by use of the protocol. 
     The basic function of the capture mode is to take full control of an intruder CPV by replacing the CPV controller with the CPV detection and intervention system as controller. This may exclude the original CPV controller from any further communication with the CPV. Prior to entering capture mode, a radio receiver may have established reliable communication reception with the CPV, the CPV may be under full control of its CPV controller using a CPV communication protocol. In some cases, the CPV detector operator may be legally authorized to take control of private property. 
     The CPV controller uses CPV communication protocol to actively communicate with the intruder CPV. In some cases, when faced with channel interference, the CPV controller may command the CPV to change its current command channel (i.e., the communication channel or main channel) to another channel chosen by the CPV controller. However, the communication protocols may not reveal the new channel to the listening CPV controller. Thus, the original intruder CPV controller may have no way to find the CPV. Thus, the original intruder CPV may be completely severed from the CPV. Thus the CPV detection and intervention system may be in full, exclusive control of the intruder CPV. In some cases, the CPV detection and intervention system issues a position hold command which tells drone/CPV to stay at current altitude and coordinates while awaiting further directions. 
     At block  3305  the CPV detector may transmit command to CPV to change control channel. In certain examples, aspects of the described operations may be performed by capture component  2555  as described with reference to  FIG.  25   . 
     At block  3310  the CPV detector may transmit control command using the changed control channel. In certain examples, aspects of the described operations may be performed by capture component  2555  as described with reference to  FIG.  25   . 
     At block  3315  the CPV detector may confirm that the CPV responds according to the CPV communications protocol. In certain examples, aspects of the described operations may be performed by capture component  2555  as described with reference to  FIG.  25   . 
     At block  3320  the original CPV controller may transmit command to the CPV using the original control channel. However, these commands may not be received by the CPV (as the CPV has changed to another channel). In certain examples, aspects of the described operations may be performed by CPV controller  2435  as described with reference to  FIG.  24   . 
     At block  3325  the original CPV controller may lose control of the CPV. In certain examples, aspects of the described operations may be performed by CPV controller  2435  as described with reference to  FIG.  24   . 
       FIG.  34    shows a diagram  3400  of a CPV seizure phase in accordance with aspects of the present disclosure. Diagram  3400  may include controlled area  3405 , CPV  3410 , CPV controller  3415 , and CPV detector  3420 . 
     A CPV  3410  may encroach on geographically controlled area  3405 , which may interfere with the operations of law enforcement, emergency response, or other authorized operations. The controlled area  3405  may be the site of a natural disaster, a crime scene, a sensitive location such as a nuclear power plant, or any other geographic location where restricting CPV activity is desired. 
     After the CPV  3410  is detected, identified, and captured, CPV controller  3415  may no longer have any communication or control with CPV  3410 . Rather, the operator of CPV detector  3420  may have complete control of CPV  3410 . In some cases, CPV detector  3420  may control CPV  3410  independently without direct intervention from an operator. 
     CPV detector  3420  may then seize CPV  3410  and either direct it to a new location, command it to land, command it to retain its position, or immobilize/deactivate it. In some cases, CPV detector  3420  may relocate CPV  3410  using a geocoding subsystem to identify its location and select a new target location. In some cases, CPV  3410  may leave the controlled area  3405  according to direction from CPV detector  3420  and may then be deactivated. 
     CPV  3410  may incorporate aspects of CPV  105  and  305  and  2410  as described with reference to  FIGS.  1 ,  3 , and  24   . CPV controller  2915  may incorporate aspects of CPV controller  2435  as described with reference to  FIG.  24   . CPV detector  2450  may be operated by law enforcement personnel, a first responder, or another authorized user and may incorporate aspects of CPV detectors  2450  and  2505  as described with reference to  FIGS.  24  and  25   . 
       FIG.  35    shows a flowchart  3500  of a process for identification, detection, capture, seizure, and immobilization of CPV systems in accordance with aspects of the present disclosure. In some examples, a CPV detector may execute a set of codes to control functional elements of the CPV detector to perform the described functions. Additionally or alternatively, a CPV detector may use special-purpose hardware. 
     After capture of a CPV, the CPV detector may enter the seize phase of mode. Seizure is the active exercise of physical and logical control over the CPV after the capture mode has completed by determination of the protocol and issuance of the commands necessary to assign full command and control to the CPV detection and intervention system over the CPV to the exclusion of its original controller. Seizure may lower or eliminate the risk that a CPV presents. 
     The first two available options during seizure are: command the intruder to return to its launch point (its origin) or to command the intruder to immediately stop where it is, land if needed, then deactivate itself. The latter is an emergency maneuver in cases where there is little or no time to reroute the intruder, the operator determines that it must be out of the way immediately regardless of any secondary risks. 
     The next options available to the CPV detector involve the eventual goal of re-routing the intruder to a safe location where it will deactivate itself and become available for physical custody of authorities who may need to enforce rules or regulations on the owner or operator of the seized device, and to impound it as evidence or for retrieval. 
     The CPV detector may determine a relatively safe target location as a destination for the intruder, a place to deactivate it. In some cases, there may be at least three options including: utilize a predetermined target destination; choose a target destination based on a touchscreen map and a finger indication on that map; or choose a target destination by visual spotting through the optical scope of the geocoding subsystem. 
     The geocoding subsystem, typically attached and integrated into the CPV detector, can be used for visual choice of target destination by, sighting down the scope at the desired target and triggering the distance measuring laser. The geocoding subsystem computing device utilizes unique software and algorithms to produce accurate geo coordinates for the visually located target. The calculation may be based on the input from the distance measuring laser: distance from CPV detector to target; input from the sub-meter GPS that gives the exact position of the CPV detection and intervention system itself; and, the input from a 3-axis MEMS gyroscope that gives the bearing on the target from the CPV detector. With these three qualities, the precise position for the target destination can be calculated by the geocoding subsystem software running on the geocoding computing device. Once calculated, this target position can be used to define the final destination for the intruder. 
     At block  3505  the CPV detector may obtain control of an unauthorized CPV. In certain examples, aspects of the described operations may be performed by capture component  2555  as described with reference to  FIG.  25   . 
     At block  3510  the CPV detector may determine target coordinates to relocate the CPV from a predetermined set or using a map display. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
     At block  3515  the CPV detector may identify target location using a laser scope of a geocoding subsystem. In certain examples, aspects of the described operations may be performed by geocoding subsystem  2482  and  2535  as described with reference to  FIGS.  24  and  25   . 
     At block  3520  the CPV detector may trigger geocoding laser. In certain examples, aspects of the described operations may be performed by geocoding subsystem  2482  and  2535  as described with reference to  FIGS.  24  and  25   . 
     At block  3525  the CPV detector may determine bearing to target. In certain examples, aspects of the described operations may be performed by geocoding subsystem  2482  and  2535  as described with reference to  FIGS.  24  and  25   . 
     At block  3530  the CPV detector may determine target coordinates. In certain examples, aspects of the described operations may be performed by geocoding subsystem  2482  and  2535  as described with reference to  FIGS.  24  and  25   . 
     At block  3535  the CPV detector may command the CPV to move to the target coordinates. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
     At block  3540  the CPV detector may command the CPV to land immediately. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
     At block  3545  the CPV detector may command the CPV to return to a point of origination. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
       FIG.  36    shows a flowchart  3600  of a process for identification, detection, capture, seizure, and immobilization of CPV systems in accordance with aspects of the present disclosure. In some examples, a CPV detector may execute a set of codes to control functional elements of the CPV detector to perform the described functions. Additionally or alternatively, a CPV detector may use special-purpose hardware. 
     In some cases, the CPV detector may detect an obstacle during relocation of a CPV and may utilize an obstacle avoidance mode or function. Thus, to minimize risk the CPV CPV detector may consider whether there are any obstacles in a linear path where natural features or structures (or other vehicles) would interfere with relocation. Collisions between drones and obstructions can be very dangerous (some batteries are highly unstable and can explode or burst into flames.) 
     The purpose of the collision avoidance mode is to determine an obstacle-free path from the intruder at its current coordinates over to the target destination coordinates at altitude. When this path is determined, the intruder may simply follow the path to safely arrive directly above the target destination, where it can be commanded to land vertically and deactivate itself right there as desired. Inputs to this mode include: current intruder altitude (if flying device), coordinates of the CPV, and coordinates of the target destination. If no obstacles are observed in the linear path from the intruder&#39;s coordinates to the target destination geo coordinates, then the intruder may simply be commanded to move to the target geo coordinates and land if necessary. 
     However, if any obstacles, or potential obstacles are observed, either visually or by map representation, the CPV&#39;s path to the target destination must be adjusted to avoid those obstacles. First consider adjustments in altitude (vertical). The simplest approach supported by the CPV detector is to set the intruder altitude so that it clears the tallest obstacle along the path. In that way, the CPV can move by the linear path to the target destination without collision. The required adjustments may be made to the altitude automatically by features in the CPV detection and intervention system, and there are provisions for manual, incremental altitude adjustments by the CPV detection and intervention system. This may be referred to as vertical collision avoidance. 
     There is another option for clearing obstacles in a path, the horizontal dimension. The path may be adjusted to avoid obstacles horizontally by the CPV detector changing the path on the CPV detector map display. The CPV detector may use the CPV detector touchscreen display to adjust the displayed path with one or more incremental horizontal movements around obstacles drawn on that display by the CPV detector. Essentially, the operator sets a waypoint or waypoints for very simple, incremental subpaths around each obstacle, culminating with an obstacle free path with the required waypoint(s) now included. 
     The auto mode for collision avoidance can automatically set vertical and horizontal waypoints given an accurate, up-to-date set of topographical maps and structural features. Similarly, a CPV detector may be given the option to utilize either vertical, horizontal, or both methods to adjust the path to avoid collisions. 
     At block  3605  the CPV detector may identify a linear path from a CPV location to a target location. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
     At block  3610  the CPV detector may identify an obstacle in the liner path. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . Based on an operator selection, the process may proceed to either block  3615  or  3620 . 
     At block  3615  the CPV detector may adjust path based on stored topographical database. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
     At block  3620  the CPV detector may adjust path based on a visual estimate, a geocoding subsystem estimate, or a display map. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
     At block  3625  the CPV detector may transmit command to the CPV to move via the adjusted path to the target location. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
     At block  3630  the CPV detector may transmit command to the CPV to land at the target location. In certain examples, aspects of the described operations may be performed by Seizure component  2560  as described with reference to  FIG.  25   . 
       FIG.  37    shows a diagram  3700  of collision avoidance in accordance with aspects of the present disclosure. Specifically, diagram  3700  illustrates examples of path adjustment for a seized CPV  3705  to avoid vertical obstacles  3710  and horizontal obstacles  3715  by selecting an obstacle free path  3720 . CPV  3705  may incorporate aspects of CPV  105  and  305  and  2410  as described with reference to  FIGS.  1 ,  3 , and  24   . 
     The CPV detector may provide for collision avoidance. Prior to executing collision avoidance, the intruder device controller may have lost its communications link to the intruder device and be unable to reestablish communications. The non-intruder CPV controller may establish a new an exclusive communications channel to the intruder device, input commands with a communications protocol for full control of the intruder device. In one example of collision avoidance, upon establishing the new communications channel, the CPV controller may command the device to immediately land. After landing, the device may be either on the ground, in unknown condition, or in the custody of authorities. In another example of collision avoidance, the CPV controller may command the device to hold position at altitude, at which point the operator may make one of several decisions. In this example, the operator may command the device to return to the custody of its owner. 
     Another option may include commanding the CPV to move to given coordinates, and to subsequently land to allow for seizure by authorities. Other options may include: sending the CPV to a target location selected from predetermined target coordinates; sending the CPV to a predetermined save target; sending the CPV to the operator&#39;s location; sending the CPV to a target location selected by touching a map display; selecting select a target location by use of an optical spotting scope; selecting a target location by use of an optical scope with a geocoding laser; and using the geocoding laser integrated subsystem to measure the distance from the chosen landing location, derive the operator position by onboard GPS, derive the bearing on the visually spotted target coordinates, utilize software algorithm that may produce precise target coordinates for the visually located target, and sending the CPV to the target coordinates. 
     Collision avoidance may involve determining an obstacle free path  3720  for the CPV to move to the target coordinates. An obstacle free path  3720  may be a straight line between the CPV and the target location. The obstacles for a safe path to the target location may be determined at the current altitude and vertically avoided in one or more of the following ways: visually avoided by the operator, in which the operator may use the geocoding laser to determine the height of the visually determined highest obstacle, and subsequently adjust the CPV&#39;s altitude a set number of feet above the calculated height, and sent to the target location; the operator may map the obstacles automatically or through the process described previously to calculate the height of each obstacle, and subsequently add the obstacle to a map, and direct the CPV on a course in which the CPV adjusts its altitude dynamically to a set number of feet above each obstacle. The obstacles may also be avoided horizontally in one or more of the following ways: the operator may offset portions of the straight line path on the display map to avoid marked obstacles by an automatic process or by manually dragging a finger to manipulate the path; the CPV detector computing device may compile waypoints to construct an obstacle free updated flight path to the target location, and the CPV may use the new path along with a final landing waypoint in order to reach a target location. 
     Integrated Secure Device Manager System 
     The Integrated Secure Device Manager System (ISDM system or ISDMS) provides a comprehensive system and methods for securely identifying drones using proprietary cryptographically secure communication protocols. Operationally, the ISDM system identifies 1) authorized drones correctly participating in the system, 2) unauthorized drones correctly participating in the system (e.g. those with an expired or revoked authorization), and 3) unauthorized drones maliciously participating in the system (e.g. those forging identity). The richness of identification data may range from simple identify friend or foe (IFF) capabilities, to a robust drone traffic management system, which provides, for example, telemetry data, owner and operator identification and location, cargo/payload manifest, all authentic and unforgeable. As a comprehensive system, ISDMS further enables traffic avoidance, supports dynamic, updatable, and cryptographically-enforced flight plans, and lawful rerouting. 
     While this application uses airborne drones as motivating examples and use cases, the ISDM system need not be restricted to these devices. Any conveyance or vehicle in which the operator is physically separated from the device—or indeed, systems that have autonomous operation—will benefit from the proposed system. For example, marine vessels of all sizes, cars, truck fleets, spacecraft, etc. Further, the ISDM system need not be restricted to vehicles: the ISDM system may act as a next generation system for identifying friendly and unfriendly combatants in, for example, a zone of conflict, as well as a mechanism for dynamically reclassifying combatants in real time, all in a privacy-preserving way. 
     A key feature of the ISDM system, and the protocols that define it, is in its flexibility in deployment and ease of use. By flexibility of deployment we mean that the system may be quickly deployed without requiring existing infrastructure. This is uniquely beneficial in, for example, cases of emergency or natural disaster, where balancing the need for drone usage (for example, used for media coverage or search and rescue) with the safety requirements of an emergency zone (for example, quickly clearing the airspace for landing emergency aircraft). The ISDM system is also designed to be easily adopted by drone operators, requiring low to no cognitive, cost, or performance (e.g. battery) overhead. 
     The ISDM system is comprised of three logical entities: Modules, Nodes, and Authorities. Modules primarily act as a beacon of identity, which at least includes some identifier (though they may also transmit additional information, as well as be able to receive transmissions). One embodiment of a Module is shown in the CPV/Module  305  previously described in  FIG.  3   . Authorities are mutually trusted entities providing a variety of verification and authorization services. One embodiment of an Authority is shown the DMA  405  previously described in  FIG.  4   . Nodes primarily receive transmissions from Modules, verify those transmission&#39;s authenticity and contents, though Nodes may also transmit messages to Modules, and transmit to/receive from Authorities. Exemplary embodiments of Nodes are shown in  FIG.  5    (ADC device  505 ) and  FIG.  6    (Relay Node  605 ). In another embodiment the functionalities of the ADC device and the Relay Node are consolidated into a single Node device. All communications between entities provide cryptographically strong authenticity and freshness. This means transmissions cannot be tampered with, forged, replayed, or otherwise altered or fabricated. 
     Depending on the entire system&#39;s configuration and feature set desired, there may be one or more of each of the previously named entities. For example, there may be multiple Modules, multiple Nodes, but a single Authority. There could also be multiple Modules, a single Node, and multiple Authorities. All system configurations are possible and supported by the proposed protocol. 
     Each logical entity may have a physical implementation or may be integrated into the same physical system. For example, a Node and Authority may be two separate devices connected by a network, two separate devices not connected by a network, or a single device implementing both Node and Authority functionality (with or without network connectivity). 
     In one embodiment, the Module may be fully incorporated into a CPV, as shown in  FIG.  3   . In another embodiment, the Module may be a separate device that is physically attached to a CPV but operates completely independently of the drone&#39;s software and hardware. The Module may have its own sensors for location (e.g. GPS) and telemetry data (e.g. gyroscope, air speed sensor, altimeter, etc.). In one embodiment, the Module comprises all elements shown in  FIG.  3    but as a separate device (i.e. including its own processor, memory etc., separate from the CPV). The Module may also be an extension of the drone, for example, as a dongle which attaches to a port on the drone, or as separate device that connects to the software and hardware of the drone in some way (e.g. via a wired or wireless connection). In one example, a dongle may include a separate transponder, processor, memory, etc., but use the drone as a source of power or additional information (e.g. GPS position, telemetry data, speed, signal strength, battery level, roll/pitch/yaw, heading, etc.). The Module may also be integrated directly into the hardware and software of a drone, requiring no additional, external hardware (as in  FIG.  3   ). In cases where the Module maintains an interface to the drone, the Module may provide supervisory control over the drone&#39;s control systems (e.g. rotors or other propulsion systems), which may be used to restrict or control flight. For example, to prevent take off without an approved flight plan, prevent flight into restricted area, prevent deviations from an approved flight plan, or provide a conduit for lawful takeover and control. 
     One embodiment of a Module-CPV system is shown below in  FIG.  38   . As previously shown in  FIG.  3   , the CPV management/authentication component  310  (i.e. the Module) is integrated into the CPV. In other embodiments, such as is shown in  FIG.  38   , the Module is a separate apparatus from the CPV. 
     The CPV in the embodiment of  FIG.  38    includes a radio receiver, a radio transmitter, a processor, a PGS/telemetry Module, and a battery. In other embodiments, the CPV may not include at least one of the radio receiver, radio transmitter, and the GPS/Telemetry Module and instead rely on those components of the Module. 
     The Module is configured to be mechanically coupled to and in communication with the CPV. The Module may be fully removable and replaceable, for example via an external USB port of the CPV easily accessible to the operator. This would allow for the Module to be separately portable from the CPV and allow for authorization of the Module without requiring access to the CPV. The Module would be coupled to the CPV before utilizing the CPV. In other embodiments the Module may be coupled to the CPV using an internal port, or may be integrated into the CPV electronics. 
     The ready-to-deploy Module in the exemplary embodiment of  FIG.  38    includes the CPV Authentication Component, a GPS/telemetry Module, a radio receiver, a radio transmitter, sensors, a battery, and a processor. The CPV Authentication component includes CPV Attributes, a CPV license, a CPV public key, a CPV private key, and a CPV Authority token (CPV DMA token). It should be noted that the CPV license, CPV public key, CPV private key and CPV Authority token must be obtained and stored on the Module prior to use of the Module. For example, the Module would be purchased by the operator without those items. The operator would then license the CPV and obtain the public key, private key, and Authority token. In some embodiments, the CPV public key and CPV private key are generated by the CPV. In some embodiments, the CPV also generates a unique ID. 
     What follows are three exemplary versions of the ISDM system and method, each providing a different feature set (from binary identification of friend or foe to full air traffic management—under a varying deployment requirements—from leveraging existing network and communication infrastructure to a completely independent deployment) on a comprehensive variety of drones. 
     Part of the value of ISDM is generating and detecting distinguished identifiers for all entities (i.e. Modules, Nodes, and Authorities), in a way that cannot be forged or impersonated. In all variants of our system, we refer to IDs as being “unique.” To clarify this, we mean a “unique” ID can be universally unique (e.g. using a universally unique identifier (UUID) standard) or “unique” only within a specific deployment or domain (e.g. “Amusement Park Drone  10 ”). 
       FIG.  38    shows an example of a system for CPV  3800  management according to aspects of the present disclosure. The example shown includes CPV  3810  and Module  3845 . CPV  3810  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  64  and  65   . 
     CPV  3810  may include Radio Receiver  3815 , Radio Transmitter  3820 , Processor  3835 , Global Positions System (GPS)/Telemetry Module  3835 , and Battery  3840 . 
     Radio Transmitter  3820  may broadcast a message including at least a CPV token signed with a private key of the CPV  3800 , a current time, and current telemetry. 
     Module  3845  may include CPV Authentication Component  3850 , GPS/Telemetry Module  3880 , Radio Receiver  3885 , Radio Transmitter  3890 , Sensors  3895 , Battery  3896 , Processor  3898 , and Storage  3897 . Module  3845  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  50 ,  58 ,  64 , and  65   . 
     Radio Receiver  3885  may receive messages including broadcasts, from a trusted Authority of the ISDM system, where the Authority is configured to manage licensing and approval of CPVs  3800 , an Authority token. 
     Radio Transmitter  3890  may send, to an Authority of the ISDM system, where the Authority has an Authority token and is configured to manage licensing and approval of CPVs  3800 , a token request including the public/private key pair and unique ID. 
     Radio Transmitter  3890  may broadcast a Module message including a current time and a Module token associated with the Module  3845  and including a public Module key and a Module ID, where the Module message is signed under a Module private key. 
     Radio Transmitter  3890  may send, to an Authority of the ISDM system, where the Authority is configured to manage licensing and approval of CPVs  3800 , a registration request including the public key and unique ID. 
     Radio Transmitter  3890  may broadcast a Module message, the Module message including a current time, and a Module token associated with the Module  3845  and including a public Module key and a Module ID, where the Module message is signed under a Module private key. 
     Storage  3897  may store software programs, algorithms, etc. necessary for operating the Module  3845 . The storage  3897  may also be used to receive and store flight data during operation of the CPV  3810 . For example, all ISDM messages that are broadcast can also be stored on the storage  3897 . Additionally, the Module  3845  can store the data in a way that is secure, such that the data cannot be tampered with or removed without detection. This storage is useful in case some messages and missed by the Gateways. The storage of flight data is also useful to allow the Module  3845  to act like a flight data recorder for post-facto review of the flight. 
     GPS/Telemetry Module  3820  may receive of at least one GPS signal by a GPS receiver of the ISDM Module  3845 . GPS/Telemetry Module  3820  may also perform Real-Time Kinematic (RTK) positioning calculations based on the at least one GPS signal received by the ISDM Module  3845  and the received RTK correctional data, whereby the position of the CPV  3800  is determined in real-time. 
     In some examples, the ISDM device is a different ISDM Module, which may establish a two-way, trusted communication channel between the ISDM Module  3845  and the different ISDM Module. 
     Module  3845  may be mechanically coupled to and in communication with an associated CPV  3800 , and may be configured to broadcast a beacon of identity. 
     Module  3845  may include a GPS receiver configured to receive RTK correctional data and perform RTK positioning calculations based on the received RTK correctional data, whereby the position of the CPV  3800  is determined in real-time. In some examples, the Module  3845  is further configured to search for and identify base stations within range of transmission of RTK data. 
     Module  3845  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  50 ,  58 ,  64 , and  65   . 
     CPV Authentication Component  3850  may generate a public/private key pair and a unique ID. CPV Authentication Component  3850  may also store the Authority token and the Module token. In some examples, the Module token further includes at least one of a unique ID of the Authority and a public key of the Authority. CPV Authentication Component  3850  may store the Authority token as trusted. 
     CPV Authentication Component  3850  may verify of the message signature upon receiving the message. CPV Authentication Component  3850  may reject the message upon determining that the signature is invalid. 
     CPV Authentication Component  3850  may extract the Node token, verifying that the Node token was signed by a trusted Authority of the ISDM system, where the Authority is configured to manage licensing and approval of CPVs  3800 , and verifying that the Node has Authority for signing Module tokens upon determining that the signature is valid. 
     CPV Authentication Component  3850  may reject the message upon determining that the Node token was not signed by a trusted Authority or that the Node does not have Authority for signing tokens. CPV Authentication Component  3850  may also determine whether the Node public key corresponds to the Node private key upon determining that the Node token was signed by a trusted Authority and that the Node has Authority for signing tokens. 
     CPV Authentication Component  3850  may also reject of the message upon determining that the Node public key does not correspond to the Node private key. CPV Authentication Component  3850  may also store the Node public key as trusted and extracting the new Module token upon determining that the Node public key corresponds to the Node private key. CPV Authentication Component  3850  may also verify by the Module whether the new Module token was signed by the trusted Authority. 
     CPV Authentication Component  3850  may also reject the new Module token upon determining that the new Module token was not signed by one trusted Authority. CPV Authentication Component  3850  may also store by the Module of the new Module token such that the new Module token is sent in future broadcasts upon determining that the new Module token was signed by the trusted Authority. 
     CPV Authentication Component  3850  may store the CPV token. In some examples, the registration is requested using a software application running on a computing device. 
     CPV Authentication Component  3850  may verify the identity of the CPV  3800  upon determining that the message is fresh, valid, and trusted. 
     CPV Authentication Component  3850  may include CPV Attributes  3855 , CPV License  3860 , CPV Public Key  3865 , CPV Private Key  3870 , and CPV Authority Token  3875 . 
     Referring next to  FIGS.  39 - 44   , exemplary methods and system are shown for an implementation providing binary Identity Friend or Foe (IFF) capabilities. Binary in this instance means that the protocol allows an interrogating Node to positively identify a ISDM Module as being compliant (friend, authorized) or non-compliant (foe, unauthorized) with the ISDM protocol in absence of any network connectivity. That is, once configured and deployed, Nodes may independently identify Modules as friend or foe with no additional networking connection. This is particularly meaningful configuration for when network connectivity is unavailable (e.g. after a natural disaster) or is completely controlled by an adversary (e.g. in a conflict zone). 
     The embodiment of  FIGS.  39 - 44    only provides IFF between Node-to-Module and Module-to-Module, but the Nodes and Modules can operate disconnected from the Authority devices. The Authority is required to extract or derive the Node public keys and store tokens prior to deployment of the system, and Module store Authority token prior to flight. Compromise of a Module&#39;s private key require a new Module to be deployed, and Nodes updated to identify revoked Module IDs. Synchronized clocks are required in order to ensure Module message freshness. 
     To initialize a deployment, the Authority generates a public/private key pair (i.e. a public key and a private key) and a unique ID ( FIGS.  39 ,  43 , and  44   , A.1) (e.g. a truncated, cryptographic hash of the public key), and then creates a self-signed token comprising at least the Authority&#39;s ID, the Authority&#39;s public key, and range of time for which the token is valid, all signed under the Authority&#39;s private key ( FIGS.  39 ,  43 , and  44   , A.2). The Authority token is then stored on authorized Nodes ( FIGS.  39 ,  43 , and  44   , A.3). This process need only be done once per deployment, and after so doing, the ISDM system is now ready to deploy. 
     To initialize a Module, the Module generates a public/private key pair and an ID ( FIGS.  40 ,  43 , and  44   , B.1); this need only be done once. After so doing, the Module makes a token request to the Authority comprising at least the Module&#39;s ID and public key, signed under the Module&#39;s private key ( FIGS.  40 ,  43 , and  44   , B.2). If the token request is approved, the Authority creates a Module token, comprising at least the same Module ID and public key from the token request, the Authority&#39;s ID and/or public key, plus some range of time for which the token will be valid, all signed under the Authority&#39;s private key. (Note: The Authority ID and/or public key need not be signed, but should be included every time a Module communicates the Module token.) Both the Authority&#39;s token and the Module token are stored on the Module ( FIGS.  40 ,  43 , and  44   , B.3). In an alternative configuration, Module initialization can entirely be done on the Authority (i.e. key generate and token generation), and the resulting tokens and private key be stored on the Module, and the Authority&#39;s token is marked as trusted. This latter configuration is beneficial when the Authority wishes to issue Modules to individuals, whereas the former process may benefit when drone operators bring their own Modules or the Module is integrated to the drone itself. After initialization, the Module is attached to a drone (if it is physically separate), and Module and drone are ready for authorized flight. This process needs to be done at least as often as the time validity of the token expires. 
     During flight the Module will broadcast a message including at least the current time and the Module token, all signed under the Module&#39;s private key. The message may optionally contain other information useful for drone or operator identity, such as the drone&#39;s current location (in 3D space), drone speed, signal strength, battery level, roll/pitch/yaw, heading, operator&#39;s name, take-off location, telephone number, operator license number, etc. The Module&#39;s public key may also optionally be transmitted, as a convenience. 
     When a Module broadcast is received at a Node ( FIGS.  41 ,  43 , and  44   , C.1) it performs the following steps: 1) the Node verifies the correctness of the signature on the message either using the Module&#39;s public key, broadcast in addition to the signed message or extracted from the Module token within the signed message. If the signature is invalid, the drone is identified as a foe; 2) If the signature is valid, the Node then extracts the Module token and verifies the token is signed by a trusted Authority, for example by seeing the Authority public key contained within the Module token matches the one in the Authority token stored on the Node. If the Module token is signed by a trusted Authority the correctness of the Authority&#39;s signature on the token using the Authority&#39;s public key, and the validity of the time is checked. If either the Module token was signed by an untrusted Authority or the signature is invalid or the current time is either before or after the valid time duration, the drone is identified as a foe; 3) If the token was signed by a trusted Authority and the signature on the token is valid and the time is valid, the Node verifies the public key stored within the Module token matches the one used to sign the broadcast message and that key has not been revoked. In so doing, the Node can verify that the Module has been authorized to fly by a trusted Authority, is in possession and control of the intended operator, and the Module is authentic (i.e. no other Module could have forged this broadcast), so therefore may be identified as friend, i.e. identified as authorized. 
     The same process for identifying a Module as friend or foe (i.e. authorized or unauthorized) may also be accomplished on a second Module. When the second Module receives the first Module&#39;s broadcast ( FIGS.  42 ,  43 , and  44   , D.1), it may perform the same validations steps as the Node does, resulting in the same output of friend or foe. 
     When a Module&#39;s private key becomes compromised or the Module has been reported stolen, authorization must be revoked as there is now a threat of impersonation (though still not forgery.) This can be done in a number of ways, including notifying Nodes (and authorizing Modules) of the breached key and/or key ID. 
       FIG.  39    shows an example of a process for deployment initialization according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  3900 , the Authority generates a key pair and a unique ID. 
     At operation  3905 , the Authority self-signs the public key, ID, and time validity with a private key. 
     At operation  3910 , the Authority stores as trusted on Nodes. 
       FIG.  40    shows an example of a process for new Module initialization according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  4000 , the Module generates a key pair and a unique ID. 
     At operation  4005 , the Module makes a token request to Authority. 
     At operation  4010 , the Module determines if the request is approved. If the request is not approved, the system will provide an error feedback. 
     At operation  4015 , the Module stores an approved token, and an Authority token as trusted. 
       FIG.  41    shows an example of a process for friend of foe Node identification according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  4100 , the Module broadcasts a current time, telemetry, and token, signed with a private key. 
     At operation  4105 , the Node receives the broadcast by one or more Nodes. 
     At operation  4110 , the Node determines if the Module broadcast signature is valid. If the system determines that the Module broadcast signature is not valid, the sender will be identified as a foe. If the system determines that the Module broadcast signature is valid, the system may move on to operation  4115 . 
     At operation  4115 , the Node extracts the Module&#39;s token by the Node. 
     At operation  4120 , the Node determines if the token signed by the trusted Authority is valid. If the system determines that the token signed by a trusted Authority is not valid, the sender will be identified as a foe. If the system determines that the token signed by a trusted Authority is valid, the system may move on to operation  4125 . 
     At operation  4125 , the Node determines if the signing key matches the key in the token from the broadcast. If the system determines that the signing key does not match the key in the token from the broadcast, the sender will be identified as a foe. If the system determines that the signing key does match the key in the token from the broadcast, the system may move on to operation  4130 . 
     At operation  4130 , the Node determines if a key or key ID has been revoked. If the system determines that a key or key ID has been revoked, the sender will be identified as a foe. If the system determines that a key or key ID has not been revoked, the sender will be identified as a friend. 
       FIG.  42    shows an example of a process for friend of foe Module identification according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  4200 , the Module broadcasts a current time, telemetry, and token, signed with its private key. 
     At operation  4205 , the second Module receives the broadcast by the second Module. 
     At operation  4210 , the second Module determines if Module broadcast signature is valid. If the system determines that the Module broadcast system is not valid, then the sender will be identified as a foe. If the system determines that the Module broadcast system is valid, the system may move on to operation  4215 . 
     At operation  4215 , the second Module extracts the first Module&#39;s token by the second Module. 
     At operation  4220 , the second Module determines if the token signed by the trusted Authority is valid. If the system determines that the token signed by the trusted Authority is not valid, then the sender will be identified das a foe. If the system determines that the token signed by the trusted Authority is valid, the system may move on to operation  4225 . 
     At operation  4225 , the second Module identifies if the broadcaster matches the token. If the system identifies that the broadcaster does not match the token, then the sender will be identified das a foe. If the system determines that identifies that the broadcaster does match the token, the system may move on to operation  4230 . 
     At operation  4230 , the second Module determines if the key or key ID has been revoked. If the system determines the key or key ID has been revoked, then the sender will be identified das a foe. If the system determines the key or key ID has not been revoked, the sender will be identified as a friend. 
       FIG.  43    shows an example of a system for CPV management according to aspects of the present disclosure. The example shown includes First Module  4300 , Second Module  4305 , one or more Nodes  4310 , and Authority  4315 . 
     First Module  4300  and Second Module  4305  may include aspects of the Module described with reference to  FIG.  38   . 
     Node  4310  may store an Authority  4315  token and mark, the Authority  4315  token as trusted. Node  4310  may determine whether the signature of the Module message is valid. Node  4310  may also identify a Module as unauthorized upon determining that the signature is invalid. 
     Node  4310  may also perform at least one authorization test, whereby the Module is identified as authorized if each of the at least one authorization test is passed upon extracting of the Module token. In some examples, the at least one authorization test includes determining whether the Module token includes a signature from a trusted ISDM Authority  4315  and the signature is for a valid time duration, where the Authority  4315  belongs to the ISDM system and is configured to manage CPV licensing and approval of CPVs, whereby the test is passed when the Module token is signed by the trusted Authority  4315  and the signature is for a valid time duration. 
     In some examples, the at least one authorization test includes determining by the ISDM device whether the Module public key corresponds to the Module private key by means of signature verification, and whether the Module private key has been revoked, whereby the test is passed when the Module public key matches the Module private key and the Module private key has not been revoked. In some examples, the at least one authorization test includes verifying that a position of the CPV and telemetry of the CPV are compliant with flight data previously authorized by the Authority  4315 . 
     In some examples, the ISDM device is a Node device of the ISDM system, which may be configured to verify Module authenticity. The ISDM device may also be a different ISDM Module. 
     Node  4310  may generate a Node public/private key pair and a unique Node ID. Node  4310  may also send to the Authority  4315  a token request including at least the Node public key and the Node private key, where the token request is signed under the Node private key. Node  4310  may also store the Node token and Authority  4315  token to the Node  4310 . Node  4310  may also mark the Authority  4315  token stored on the Node  4310  as trusted. 
     Node  4310  may receive the Module broadcast and may be configured to verify Module authenticity and having a Node private key, a Node public key, and a Node token signed by an Authority  4315  of the ISDM system, where the Authority  4315  is configured to manage licensing and approval of CPVs. Node  4310  may also determine whether the signature of the Module message is valid by using the Module public key. Node  4310  may identify the Module as unauthorized upon determining that the signature is invalid. 
     Node  4310  may also extract the Module ID from the Module message upon determining that the signature is valid. Node  4310  may also create an Authority query message signed using the Node private key and including the Module ID and the Node token. Node  4310  may also send, over a network, the Authority query message to the Authority  4315 . 
     Node  4310  may also verify the validity the signature of the reply and verifying that the signing Authority  4315  is trusted upon receiving the reply. Node  4310  may also identify the Module as authorized upon determining that the signature is valid and the signing Authority  4315  is trusted. 
     Node  4310  may also identify the Module as unauthorized upon determining that the signature is invalid or the Authority  4315  is not trusted. Node  4310  may also resend, over the network, the Authority  4315  query message to the Authority  4315  upon reporting by the Authority  4315  that the query is unauthorized. 
     Node  4310  may also generate a new Module token including at least a portion of the current Module token, the new token signed by a private key of the Node  4310  device. Node  4310  may also send a message to the Module, the message including the new Module token and the Node token, where the message is signed under the Node private key. 
     Nodes  4310  may comprise a set of ISDM Stations where each ISDM station is configured to support at least one of the group of CPV authentication, CPV authorization, and secure communication between ISDM Modules and other ISDM Stations. In some examples, the set of ISDM stations includes at least one Node  4310  device configured to verify Module authenticity. 
     In some examples, each ISDM station is one of an ISDM Node  4310 , an ISDM Authority  4315 , or an ISDM Gateway, where each ISDM station has a known location, includes a Global Positions System (GPS) receiver configured to determine Real-Time Kinematic (RTK) correctional data from received GPS signals, is configured to support authentication, authorization, and secure communication between ISDM Modules and other ISDM Stations, configured to send RTK correctional data to the ISDM Module, and configured to receive RTK correctional data from one of an Evolved Packet Core (EPC) Network and an Internet Gateway. 
     Node  4310  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  50  and  58   . 
     Authority  4315  may generate a public/private key pair and a unique ID for the Authority  4315  and may be configured to manage licensing and approval of CPVs. Authority  4315  may also create a self-signed Authority token signed by the private key. Authority  4315  may also send the Authority  4315  token to a set of ISDM Node  4310  device configured to verify Module device authenticity and in communication with the Authority  4315 . In some examples, the Authority token includes the unique ID, the public key, and a range of time for which the token is valid. 
     Authority  4315  may determine if the token request is approved. Authority  4315  may also create a Module token, the Module token including the Module ID and public key and a range of time for which the Module token is valid upon determining that the token request is approved. Authority  4315  may also send the Module token and the Authority  4315  token to the Module. 
     Authority  4315  may generate a public/private key pair and a unique ID for the Authority  4315 . Authority  4315  may also create a self-signed Authority token signed by the private key. Authority  4315  may also send the Authority token to a set of ISDM Node devices configured to verify Module device authenticity and in communication with the Authority  4315 . Authority  4315  may also determine whether the token request is approved. Authority  4315  may also create a Node token for the approved Node  4310 , the Node token includes the Node ID, the Node public key, the Authority public key, the Authority ID, and a range of time for which the token is valid, where the Node token is signed under the Authority private key upon approval of the token request. Authority  4315  may also send the Node token and Authority  4315  token to the Node  4310 . 
     Authority  4315  may determine if the registration request is approved. Authority  4315  may also register the Module public key and the unique ID with the ISDM system upon determining that the registration request is approved. Authority  4315  may also register the Module public key and unique ID includes inserting the Module public key and unique ID into a database maintained by the Authority  4315 . 
     Authority  4315  may store the information. Authority  4315  may also associate the information with the Module. In some examples, the associating includes associating the information with a public key of the Module, where the public key is previously stored by the Authority  4315 . 
     Authority  4315  may determine whether the signature is valid and whether the Node token was signed by a trusted Authority. Authority  4315  may also report that the query is unauthorized upon determining that the signature is invalid or the Node token is not signed by the trusted Authority  4315 . 
     Authority  4315  may also send to the Node  4310  a reply including at least the Module ID and the Module public key, where the reply is signed under an Authority  4315  private key of the sending Authority  4315  upon determining that the signature is valid and the Node token is signed by the trusted Authority  4315 . 
     Authority  4315  may determine whether the query is authorized. Authority  4315  may also identify the Module CPV Authentication Component. 
     Authority  4315  may register the Module public key and unique ID includes inserting the Module public key and unique ID into a database maintained by the Authority  4315 . 
     Authority  4315  may determine, based on the information, if flight is authorized. Authority  4315  may also send a Module token to the operator upon authorization of flight. 
     Authority  4315  may generate a public/private key pair and a unique ID for the Authority  4315 . Authority  4315  may also create a self-signed Authority token by self-signing the public key, the unique ID, and a valid range of time, where the Authority token is signed by the private key. Authority  4315  may also send the Authority token to a set of ISDM receivers configured to verify ISDM Module authenticity. Authority  4315  may also store the Authority  4315  token. Authority  4315  may also publish the Authority  4315  token by each receiver. 
     Authority  4315  may determine if the registration is approved. Authority  4315  may also return an error message to the operator upon determining that the registration is not approved. Authority  4315  may also register the CPV and the Module with the ISDM system upon determining that the registration is approved. Authority  4315  may also return to the Module a CPV token upon registering. 
     In some examples, the set of ISDM stations includes at least one Authority  4315  device configured to manage licensing and approval of CPVs. 
     Authority  4315  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  50 ,  58 ,  64 , and  65   . 
       FIG.  44    shows an example of a process for CPV management according to aspects of the present disclosure. Specifically,  FIG.  44    may show an overview showing the relationship between the processes described with reference to  FIGS.  39 - 42   . 
     Referring next to  FIGS.  45 - 51   , an exemplary method and system are shown for an implementation providing Network-connected IFF. In exchange for requiring Nodes to have a communication link with the Authority, the information used in determining whether a drone is authorized can be enriched. Specifically, this enables Modules to authentically broadcast additional information, for example, detailed operator information, cargo manifests, etc. This configuration is particularly useful when the Node and the Authority are the same entity, though separate entities communicating over existing infrastructure or infrastructure proprietary to the ISDM system are also considered. 
     The embodiment of  FIGS.  45 - 51    provides IFF and telemetry/plan verification, but requires Nodes to have online access to the Authority/Authority device(s). Module keys can be easily rotated. Both this embodiment and the embodiment of  FIG.  39 - 44    require the Authority to extract or derive the Node and Module public keys and store tokens prior to deployment. Compromise of a Module Private key or a Node private key requires a new device (Module or Node, respectively) to be deployed. 
     Registration of flight plans must occur prior to flight, but eases operator overhead by only requiring the operator to know the Module ID (which, for example, could be printed on the Module exterior). Synchronized clocks are required to ensure Module freshness. 
     To initialize this deployment configuration, the Authority generates a public/private key pair and an ID ( FIGS.  45 ,  50 , and  51   , A.1) (e.g. a truncated, cryptographic hash of the public key), and then creates a self-signed token comprising at least the Authority&#39;s ID, the Authority&#39;s public key, and range of time for which the token is valid, all signed under the Authority&#39;s private key ( FIGS.  45 ,  50 , and  51   , A.2). Nodes also generate public/private key pairs and unique IDs ( FIGS.  45 ,  50 , and  51   , A.3), after which Nodes make a token request to the Authority comprising of, at least, the Node&#39;s public key and the Node&#39;s ID, signed under the Node&#39;s private key ( FIGS.  45 ,  50 , and  51   , A.4). If the token request is approved, the Authority creates a Node token, comprising at least the same Node ID and public key from the token request, the Authority&#39;s ID and/or public key, plus some range of time for which the token will be valid, all signed under the Authority&#39;s private key. Both the Authority&#39;s token and the Node token are stored on the Node, and the Authority&#39;s token is marked as trusted ( FIGS.  45 ,  50 , and  51   , A.5). In an alternative configuration, Module initialization can entirely be done on the Authority (i.e. key generate and token generation), and the resulting tokens and private key be stored on the Node. The ISDM system is now ready to deploy. 
     To initialize a new Module, the Module generates a public key and unique ID ( FIGS.  46 ,  50 , and  51   , B.1), and then registers the public key and ID with the Authority ( FIGS.  46 ,  50 , and  51   , B.2). Registration comprises, for example, inserting the Module&#39;s public key and ID into a database maintained by the Authority. This need be done only once, and the Module is now ready for preflight authorization. 
     Before a flight, a drone operator will register with the Authority, for example, her drone make and model, her operator ID, and her Module ID, and other data useful for identification or other drone flight purposes ( FIGS.  47 ,  50 , and  51   , C.1) (e.g. flight duration, a flight plan, etc.). If the registration is approved by the Authority, the Authority stores this information and associates it with the previously stored public key of the Module ( FIGS.  47 ,  50 , and  51   , C.2). The Module is now ready for authorized flight and is attached to a drone (if it is physically separate). This process needs to be as often as required by the Authority (e.g. from per-flight to only once). 
     During flight, the Module broadcasts a message including at least the current time and the Module ID, all signed under the Module&#39;s private key. The message may optionally contain other information useful for drone or operator identity, such as the drone&#39;s current location (in 3D space), drone speed, signal strength, battery level, roll/pitch/yah, heading, operator&#39;s name, take-off location, telephone number, operator license number, etc. The Module&#39;s public key may also optionally be transmitted, as a convenience. 
     When a Module broadcast is received at a Node ( FIGS.  48 ,  50 , and  51   , D.1) it performs the following steps: 1) the Node verifies the correctness of the signature on the message either using the Module&#39;s public key (if broadcast in addition to the signed message) or in absence of the public key, postpones the message verification. If the public key is present and the signature is invalid, the Module is identified as foe. 2) If the signature is valid or verification has been postponed, the Node extracts the Module ID from the message and creates an Authority query message including at least the Module ID and the Node token signed under the Node&#39;s private key ( FIGS.  48 ,  50 , and  51   , D.2). This Authority query is sent over a network to an Authority if the Node is a separate entity. 3) When the Authority receives the query it verifies the signature on the message is valid, and that the Node token is signed by a trusted Authority. If not, the query is report as unauthorized. If the query has been authorized, the Authority generates a reply including at least the Module ID, the Module&#39;s public key, and optionally any other data stored and associated with the Module ID. This message is signed under the Authority&#39;s private key. If there is no public key (or other required drone/operator information as determined by the system&#39;s configuration) the Authority generates an error message (e.g. no such key) signed under the Authority&#39;s private key and return it to the Node ( FIGS.  48 ,  50 , and  51   , D.3). 4) When the Node receives a reply it verifies the validity of the signature on the message as well as verifies it was signed by a trusted Authority. If not, the Node reports an error (e.g. unauthorized or invalid reply) and may choose to query the Authority again. If the reply is valid and trusted, the Module&#39;s public key is extracted from the message, and if postponed, the signature on the Module broadcast message is verified. If the signature is invalid or the reply contains a no key error (or similar), the Module is identified as foe. If valid, any additional information returned in the Authority reply may optionally be used to determine if the Module (as attached to the drone) is in compliance. By following this process the Node has high assurance that the Module has been authorized to fly by a trusted Authority, is in possession and control of the intended operator, and the Module is authentic (i.e. no other Module could have forged this broadcast), so therefore may be identified as friend. 
     In exchange for some freshness guarantees on registered data, Nodes may cache response from an Authority, allowing to more quickly identify previously seen Modules as well as continue to operate should the network connection between Node and Authority become lost. Similarly, Nodes could be pre-populated with registered data (e.g. based on some correspondence between a Node&#39;s physical location and the flight plans registered by operators), here again enabling faster detection and tolerance to network partition. 
     A similar process for identifying a Module may also be accomplished by a public observer. When the observer receives the Module&#39;s broadcast ( FIGS.  49 ,  50 , and  51   , E.1), it may performs similar identification steps (1-4 above) as the Node does ( FIGS.  49 ,  50 , and  51   , E.2), but may receive less or different information, as determined by the system&#39;s configuration, from the Authority ( FIGS.  49 ,  50 , and  51   , E.3). As we consider public observers to be a non-critical entity in the ISDM system, neither the observer&#39;s queries nor the Authority&#39;s replies need be signed or verified. 
     When a Module&#39;s private key becomes compromised or the Module has been reported stolen, authorization must be revoked as there is now a threat of impersonation (though still not forgery.) This can be done in a number of ways, for example, notifying Nodes immediately of the breached key and/or key ID, have Node&#39;s occasionally query an Authority for a list of revoked keys, or indicate the key has been revoked should its identity ever be queried by the Node. 
       FIG.  45    shows an example of a process for Nodes to store a token and Authority token to be stored as trusted according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  4500 , the Authority generates a key pair and unique ID by an Authority. 
     At operation  4505 , the Authority self-signs a public key, ID, and time validity with a private key. 
     At operation  4510 , the Node generates key pairs and a unique ID by the Node. 
     At operation  4515 , the Node makes token request to the Authority. 
     At operation  4520 , the Node determines if the token request is approved. If the request is not approved, the system will provide an error feedback. 
     At operation  4525 , the Node stores a token and an Authority token is stored by the Node, as trusted. 
       FIG.  46    shows an example of a process for registering Module ID and public key with the Authority according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  4600 , the Module generates a key pair and a unique ID. 
     At operation  4605 , the Module registers an ID and a public key with the Authority. 
       FIG.  47    shows an example of a process for flight readiness according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  4700 , the system registers an operator ID, UAV, ID, Module ID, and other data with the Authority. 
     At operation  4705 , the system determines if the data registered with the Authority is approved. If system determines that the data registered with the Authority is not approved, the system will provide an error feedback 
     At operation  4710 , the system stores an operator ID, UAV, ID, Module ID, and other data at the Authority. 
       FIG.  48    shows an example of a process to determine if the Module broadcast confirms to the Authority reply according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  4800 , the Module broadcasts current time, telemetry, and ID, signed with the private key. 
     At operation  4805 , the Node receives the broadcast at the Nodes. 
     At operation  4810 , the Node determines if the Module broadcast signal is valid. If the system determines that the Module broadcast signal is not valid, the sender will be identified as foe. If the system determines that the Module broadcast signal is valid, the system may move on to operation  4815 . 
     At operation  4815 , the Node extracts the Module ID and queries Authority that is signed with the Node&#39;s private key. 
     At operation  4820 , the Node determines if the query from an authorized Node is valid. If the system determines that the query from an authorized Node is not valid, the unauthorized query will be reported. If the system determines that the query from an authorized Node is valid, the system may move on to operation  4825 . 
     At operation  4825 , the Node replies with the Module&#39;s public key, operator ID, UAV ID, and other data that is signed with a private key. 
     At operation  4830 , the Node determines if the reply is valid and from a trusted source. If the system determines if the reply is not valid and not from a trusted source, the unauthorized query will be reported. The system will then proceed to operation  4835 , where the system determines if the system should reattempt authorization. If the system determines if the reply is valid and from a trusted source, the system may move on to operation  4840 . 
     At operation  4840 , the Node determines if the Module broadcast conforms to the Authority reply. If the system determines that the Module broadcast does not conform to the Authority reply, the sender will be identified as a foe. If the system determines that the Module broadcast does conform to the Authority reply, the sender will be identified as a friend. 
       FIG.  49    shows an example of a process to identify a UAV according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  4900 , the Module broadcasts current time, telemetry, and ID that is signed with its private key. 
     At operation  4905 , the Observer receives the broadcast by a public observer. 
     At operation  4910 , the Observer extracts the Module ID and queries Authority. 
     At operation  4915 , the Observer determines if the query is authorized. If the system determines that the query is not authorized, the unauthorized query will be reported. If the system determines that the query is authorized, the system may move on to operation  4920 . 
     At operation  4920 , the Authority replies with the approved data. 
       FIG.  50    shows an example of a system for CPV management according to aspects of the present disclosure. The example shown includes Module  5000 , Node  5005 , Observer  5010 , Authority  5015 , and Operator  5020 . 
     In some examples, ISDM devices may include different ISDM Modules, which may establish a two-way, trusted communication channel between the ISDM Modules  5000 , Nodes  5005 , and different ISDM Modules  5000 . 
     Module  5000  may be mechanically coupled to and in communication with an associated CPV, the ISDM Module  5000  configured to broadcast a beacon of identity. 
     Module  5000  may be mechanically coupled to and in communication with a CPV, and the ISDM Module  5000  may be configured to provide a beacon of identity and including a GPS receiver configured to receive RTK correctional data and perform RTK positioning calculations based on the received RTK correctional data, whereby the position of the CPV is determined in real-time. In some examples, the Module  5000  is further configured to search for and identify base stations within range of transmission of RTK data. 
     Module  5000  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  58 ,  64 , and  65   . 
     Node  5005  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  43  and  58   . 
     Observer  5010  may extract the Module  5000  ID. Observer  5010  may also create an Authority  5015  query message including the Module  5000  ID. Observer  5010  may also send the query message to an Authority  5015 , where the Authority  5015  is configured to manage licensing and approval of CPVs. Observer  5010  may determine if the message is fresh, valid and trusted. 
     Authority  5015  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  43 ,  58 ,  64 , and  65   . 
     Operator  5020  may register information with an Authority  5015  of the ISDM system, where the Authority  5015  is configured to manage licensing and approval of CPVs, where the information required is determined by the Authority  5015 . In some examples, the information includes an operator ID and a Module ID. In some examples, the information includes flight information. Operator  5020  may also mechanically couple the Module  5000  to the associated CPV. 
     Operator  5020  may generate a token request including CPV and operator  5020  identification information. Operator  5020  may purchase a CPV and Module  5000 . Operator  5020  may also request registration of the CPV and the Module  5000  with an Authority  5015  of the ISDM system, the Authority  5015  configured to manage licensing and approval of CPVs. 
     Operator  5020  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIG.  58   . 
       FIGS.  51 A and  51 B  show an example of a process for CPV management with a public observer according to aspects of the present disclosure. Specifically,  FIG.  51    shows an overview describing the relationship between the systems and methods of  FIGS.  46 - 49   . 
     Referring next to  FIGS.  52 - 59   , an exemplary ISDM system and method is shown that is supportive of a comprehensive, robust, drone traffic management system. 
     The robust Unmanned Traffic Management (UTM) system of  FIGS.  52 - 59    provides Identify Friend-or-Foe capabilities as well as disconnected verification of GPS, plan, and operator. Sent message sizes are larger, and the Module token is dynamic and must be generated and signed prior to operation (flight). Nodes can both validate Module broadcasts and tokens and independently update Module tokens without an online connection to and Authority. Clocks must be synchronized in order to prevent replay and/or ensure freshness. 
     To initialize a deployment, the Authority generates a public key pair and a unique ID (e.g. a cryptographic hash of the public key, truncated to a suitable length) ( FIGS.  52 ,  58 ,  59   , A.1), and then creates a self-signed token comprising at least the Authority&#39;s ID, the Authority&#39;s public key, and range of time for which the token is valid, all signed under the Authority&#39;s private key ( FIGS.  52 ,  58 ,  59   , A.2). Nodes also generate public key pairs and unique IDs ( FIGS.  52 ,  58 ,  59   , A.3), after which Node&#39;s make a token request to the Authority comprising of, at least, the Node&#39;s public key and the Node&#39;s ID, signed under the Node&#39;s private key ( FIGS.  52 ,  58 ,  59   , A.4). If the token request is approved, the Authority creates a Node token, comprising at least the same Node ID and public key from the token request, the Authority&#39;s ID and/or public key, plus some range of time for which the token will be valid, all signed under the Authority&#39;s private key. Both the Authority&#39;s token and the Node token are stored on the Node, and the Authority&#39;s token is marked as trusted ( FIGS.  52 ,  58 ,  59   , A.5). 
     To initialize a Module, the Module generates a public/private key pair and an ID ( FIGS.  53 ,  58 ,  59   , B.1) and stores the token of a trusted Authority ( FIGS.  53 ,  58 ,  59   , B.2); this need only be done once, and the Module is now ready for preflight authorization. 
     Before a flight a drone operator will make a token request including information pertinent to drone and operator identification. For example, an operator may generate token request which includes her drone make and model, her operator ID, and her Module ID, and other data useful for identification (e.g. operator contact information, take-off location, etc.), authorization (e.g. drone operator license, flight operator credentials, etc.) or other drone flight purposes (e.g. flight duration, a flight plan, etc.) ( FIGS.  54 ,  58 ,  59   , C.1). If the registration is approved by the Authority, it returns a Module token including at least the same information contained in the request, plus the ID and/or public key of the Authority, all signed under the Authority&#39;s private key ( FIGS.  54 ,  58 ,  59   , C.2). The operator may now upload the signed Module token to the Module ( FIGS.  54 ,  58 ,  59   , C.3). The Module is now ready for authorized flight and will be attached to a drone (if it is physically separate). This process needs to be as often as required by the Authority (e.g. from per-flight to only once). 
     During flight the Module will broadcast a message including at least the current time and the Module token, all signed under the Module&#39;s private key. The message may optionally contain other transitory information useful for drone identity and compliance authorization, such as the drone&#39;s current location (in 3D space), drone speed, signal strength, battery level, roll/pitch/yaw, heading, cargo weight, etc. The Module&#39;s public key may also optionally be transmitted, as a convenience. 
     When a Module broadcast is received at a Node ( FIGS.  55 ,  58 ,  59   , D.1) it performs the following steps: 1) the Node verifies the correctness of the signature on the message either using the Module&#39;s public key (broadcast in addition to the signed message) or extracted from the Module token within the signed message. If the signature is invalid, the drone is identified as a foe. 2) If the signature is valid, the Node then extracts the Module token and verifies the token was signed by a trusted Authority, for example by seeing the Authority public key contained within the Module token matches the one in the Authority token stored on the Node. If the Module token is signed by a trusted Authority the correctness of the Authority&#39;s signature on the token using the Authority&#39;s public key, and the validity of the time is checked. If either the Module token was signed by an untrusted Authority or the signature is invalid or the current time is either before or after the valid time duration, the drone is identified as a foe. 3) 
     If the token was signed by a trusted Authority and the signature on the token is valid and the time is valid, the Node verifies the public key stored within the Module token matches the one used to sign the broadcast message and that key has not been revoked. Finally, the Node may verify that the drone&#39;s position and telemetry is compliant with the flight data authorized by the Authority. In so doing, the Node can verify that: the Module has been authorized to fly by a trusted Authority, the Module is in possession and control of the intended operator, and the Module is authentic (i.e. no other Module could have forged this broadcast), so therefore may be identified as friend. 
     The same process for identifying an authorized Module may also be accomplished on a second Module. When the second Module receives the first Module&#39;s broadcast ( FIGS.  56 ,  58 ,  59   , E.1), it may perform the same validations steps (1-3 above) as the Node does, resulting in the same output of friend or foe. Additionally, the second Module may respond, creating a two-way, trusted channel for communication between drones. This is extremely valuable in coordinating flight paths and other cooperative operations. Further, trusted Modules may create a mesh-like network for communicating information across Modules that may be separated by long distances, and out of range for a direct broadcast. In this configuration, messages may be relayed from source Module to destination Module by leveraging intermediate Modules, all without risk of tampering or forgery. 
     One unique feature of this configuration is the system&#39;s ability to update the Module&#39;s token during flight. This may be useful in cases were existing flight plans need to be altered (e.g. due to emergency), when authorization need to be amended or revoked, or in other circumstance where modifying the Module&#39;s token during flight would be beneficial the safety and security of the airspace. Additionally, a Node (or other similarly trusted entity) may update a Module&#39;s token to reflect current weather conditions or other may environmental conditions. In this way, Nodes act as trusted, external sensors that are useful in determining a safe path of flight for a drone. 
     To generate a new Module token, a Node will generate a new Module token containing some or all of the information from a Module&#39;s original token, amended with whatever modifications are deemed appropriate by the Node, and signed by the Node&#39;s private key. This new Module token along with the Node&#39;s token are then signed under the Node&#39;s private key and transmitted to the Module ( FIGS.  57 ,  58 ,  59   , F.1). Upon receipt the Module takes the following steps: 1) It verifies the signature on the Node&#39;s message, and rejects the message if it is invalid. 2) The Module then extracts the Node token and verifies that it was signed correctly by a trusted Authority and that the Node was delegated token signing Authority. The Module then verifies if the Node public key in the Node token corresponds to the same public key used to sign the Node broadcast. If any of these verifications fail, the Node broadcast is rejected. If all verifications are valid, the Node&#39;s public key is stored as trusted. 3) The Module then extracts the new Module token and verifies that it was signed by a trusted Authority and if not the token is rejected. If all verifications are met, the Module stores the new Module token to be sent in future Module broadcasts. In this example, the new Module token is generated at the Node, though this is not a requirement. Any entity that is an Authority (e.g. the Authority) or delegated Authority (e.g. Nodes) may generate a new, unforgeable Module token that will be accepted by the Module. Further, when the Module is integrated with the flight control systems, this configuration empower an Authority to generate a new flight plan that may ground the drone or have it return to “home,” for example, in cases of emergency. Combined with Authority delegation, this system provides for the lawful rerouting of drones by law enforcement officials. 
     In all the above variances time is included in many of the messages. This is to be robust against replay attack; that is, time provides “freshness” to messages, making old or “stale” messages detectable. Entities in the ISDM system may acquire their time from well-known, and widely-used time synchronization protocols, such as NTP, or from those network infrastructures that provide synchronized time as a service, such as LTE. As GPS uses time as means for determining location, it is also a reasonable source in our system. 
     Time via synchronized clocks, however, is not the only way to provide freshness in the ISDM protocol. ISDM entities may engage in a challenge-response style protocol, in which an entity (e.g. a Node) may challenge a Module with a randomly generated nonce. A compliant Module will include the nonce in its signed response—an impersonating Module will be unable to correctly sign the nonce. 
     Alternatively, Nodes and Authorities may be the trusted source of time, broadcasting time signed under their respective private keys, and received and updated at a Module. This is beneficial in environments when stateful protocols, such as the challenge-response described above, are infeasible. 
     In configurations where all two-way communication is undesirable, a looser guarantee of freshness may be achieved through the use of a counter. In this configuration a Module may randomly select an integer as a starting point and then incrementing and include the integer for each message. For additional guarantees of freshness, in configurations that include Authority-signed tokens, the starting integer may be chosen by the Authority and included in the Module token. This allows a Node to increase its assurance in the freshness of a Module&#39;s broadcasts. We also consider the benefits of the including the source of a Module&#39;s time or nonce as part of its broadcast. Here again, receivers may use this information to increase their confidence of a Module&#39;s broadcast&#39;s authenticity. 
     Modules may also choose to use no mechanism for providing freshness within protocol messages, and instead rely upon other extrinsic factors for freshness and authenticity. For example, a Node may use a mechanism to triangulate the source of a Module message and verify whether the data communicated within a message matches the physical characteristics of the drone: drone type, telemetry, vector, etc. 
     In the embodiments considered above, it is natural to think of the Authority as a single, centralized entity. Here again, this is an artificial restriction of the ISDM system. The popularity of blockchain technologies, e.g. those used in Bitcoin accounting, could be used an alternative to centralized Authority. Specifically, operators may include as a self-signed transaction in the blockchain, all the same information they would have stored in an Authority&#39;s database (e.g. operator name, license, flight plan, cargo manifest, etc.). This provides for an open and transparent record of Module operation that is immutable and publicly verifiable. 
     An additional technology that we see as synergistic to the strong identity and message authenticity provided by the ISDM system, is in a secure flight data recorder, such as those used by some manned aircraft. Useful as part of a forensic examination, a flight data recorder is an essential and often required piece of equipment on commercial aircraft (and, indeed, a growing number of other types of vehicles). Due to the cryptographic capabilities provided by a Module, we have the capability to produce an authentic, immutable, and order-preserving record of a variety of valuable in-flight data sources. 
     Similar to the blockchain, an immutable record of flight data may be achieved by signing “transactions” that could include, for example, time, position, vector, operator information, etc., along with a hash of previous transaction, using a private key designed for this purpose. To provide tamper resistance, cryptographic operations may be provided via a hardware-based cryptographic coprocessor, such as a trusted platform Module (TPM) or similar. In such a system, the signing key exists within a tamper-resistant chip, making extracting the key (e.g. to forge a flight record) very difficult. 
     Sources of data may be drawn directly from a drone&#39;s sensors, or as one alternative, from sensors located within the data recording Module itself (should it be a physically distinct device from the drone). 
     While strong identity is a key tenet of the ISDM system, we acknowledge there will be a desire to balance operator privacy with the public safety and security needs of binding an identity to a drone. Broadcasting a static identifier (e.g. Module ID) may allow an observer to track the location or “habits” of same Module/drone over time. This is not a new problem. The license plate system used in most states dissociates plate numbers from an operator or owner, but linkability can be achieved with the appropriate credentials and access rights (e.g. a law enforcement office with access to a state&#39;s motor vehicle database). However, because license plates are static, behaviors, patterns, and other de-anonymizing information may be garnered by unauthorized subjects by observing and tracking a vehicles static identifier (e.g. license plate). 
     Because ISDM identifiers are digital (and not permanently embossed in sheet metal), we have an opportunity to innovate through the use of pseudo-anonymity. In all ISDM systems we may replace a static identifier with one that is computed dynamically upon each broadcast and is indistinguishable from random, but, which has the property and that any one pseudo-anonymous identifier may, with the appropriate credentials, admit the true identity of an operator. That is, any broadcast identifier (e.g. Module ID) will provide no link to an operator, unless the integrator is in possession of the secret that allows her to bind any single (pseudo-random) identifier to an original identity. Even if an unauthorized observer were to collect a drone&#39;s location and identifier, she will be unable to know if this is Module she&#39;s seen before. 
     Group signatures is one cryptographic technique that satisfies these privacy requirements. In group signature schemes, signatures provide a means for an entity to prove membership within a group, while not revealing their identity to a normal verifier. This implies that a normal verifier cannot distinguish the identities of any members within a group, only that a valid signature must have come from that group. Additionally, group signatures provide a means for a special “group manager,” given a message and signature, to reveal the identity of an individual member within a group. This feature implies that it is infeasible for a group member to forge the signature of another group member. As applied to the proposed ISDM system, Modules would be members of a group, and the receivers could verify that Modules were authorized, but not necessarily their identities. Unless, the receiver were authorized to “open” their identities via the group manager (e.g. an Authority). The operational flows form ISDM illustrated in  FIGS.  39 ,  41  and  43    could all be modified to include a group signature scheme with no fundamental change to their core operation. That is, only the way the signatures are computed and verified would be changed to support the pseudo-anonymous properties provided by group signatures. 
       FIG.  52    shows an example of a process for Nodes to store a token and Authority token to be stored as trusted according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  5200 , the Authority generates a key pair and a unique ID by an Authority. 
     At operation  5205 , the Authority self-signs a public key, ID, and time validity with a private key. 
     At operation  5210 , the Node generates key pairs and a unique ID by a Node. 
     At operation  5215 , the Node makes token requests to the Authority. 
     At operation  5220 , the Node determines if the request is approved. If the request is not approved, the system will provide an error feedback. 
     At operation  5225 , the Node stores tokens and Authority token by the Node as trusted. 
       FIG.  53    shows an example of a process a Module ready for use according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  5300 , the Module generates a key pair and a unique ID. 
     At operation  5305 , the Authority stores the Authority token as trusted on the Module. 
       FIG.  54    shows an example of a process for token to be issued and stored to an operator according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  5400 , the Operator requests a token consisting of an operator ID, UAV ID, Module ID, flight plan, public key, and other drone and operator data. 
     At operation  5405 , the Authority determines if the request is approved. If the request is not approved, the system will provide an error feedback. 
     At operation  5410 , the Authority issues the token. 
     At operation  5415 , the Module stores the token on the Module. 
       FIG.  55    shows an example of a process to determine if token data is valid and drone is compliant according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  5500 , the Module broadcasts current time, telemetry, and ID that is signed with a private key. 
     At operation  5505 , the Node receives the broadcast by the Nodes. 
     At operation  5510 , the Node determines if the Module broadcast signature is valid. If the system determines that the Module broadcast signature is not valid, then the sender will be identified as a foe. If the system determines that the Module broadcast signature is valid, the system may move on to operation  5515 . 
     At operation  5515 , the Node extracts the Module&#39;s token by the Node. 
     At operation  5520 , the Node determines if the token signed by a trusted Authority is valid. If the system determines that the token signed by a trusted Authority is not valid, then the sender will be identified as a foe. If the system determines that the token signed by a trusted Authority is valid, the system may move on to operation  5525 . 
     At operation  5525 , the Node determines if the broadcaster matches the ID in the token. If the system determines that the broadcaster does not match the ID in the token, then the sender will be identified as a foe. If the system determines that the broadcaster does match the ID in the token, the system may move on to operation  5530 . 
     At operation  5530 , the Node determines if the other token data is valid and if the drone is compliant. If the system determines that the other token data is not valid and that the drone is not compliant, then the sender will be identified as a foe. If the system determines that the other token data is valid and that the drone is compliant, the sender will be identified as a friend. 
       FIG.  56    shows an example of a process to determine if token data is valid and drone is compliant according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  5600 , the Module broadcasts a current time, telemetry, and ID that is signed with a private key. 
     At operation  5605 , the Second Module receives the broadcast by the Nodes. 
     At operation  5610 , the Second Module determines if the first Module broadcast signature is valid. If the system determines that the first Module broadcast signature is not valid, then the sender will be identified as a foe. If the system determines that the first Module broadcast signature is valid, the system may move on to operation  5615 . 
     At operation  5615 , the Second Module extracts the first Module&#39;s token by the second Module. 
     At operation  5620 , the Second Module determines if the token signed by a trusted Authority is valid. If the system determines that the token signed by a trusted Authority is not valid, then the sender will be identified as a foe. If the system determines that the token signed by a trusted Authority is valid, the system may move on to operation  5625 . 
     At operation  5625 , the Second Module determines if the broadcaster matches the ID in the token. If the system determines that the broadcaster does not match the ID in the token, then the sender will be identified as a foe. If the system determines that the broadcaster does match the ID in the token, the system may move on to operation  5630 . 
     At operation  5630 , the Second Module determines if the other token data is valid and if the drone is compliant. If the system determines that the other token data is not valid and that the drone is not compliant, then the sender will be identified as a foe. If the system determines that the other token data is valid and that the drone is compliant, the sender will be identified as a friend. 
       FIG.  57    shows an example of a process to update a Module token according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  5700 , the Node generates a new Module token, and broadcast the Module token and the Node token, which are signed with a private key. 
     At operation  5705 , the Module determines if the Node broadcast signature is valid. If the system determines that the Node broadcast signature is not valid, then the sender will be rejected. If the system determines that the Node broadcast signature is valid, the system may move on to operation  5710 . 
     At operation  5710 , the Module extracts the Node&#39;s token. 
     At operation  5715 , the Module determines if the Node token that is signed by a trusted Authority is valid. If the system determines that the Node token that is signed by a trusted Authority is not valid, then the sender will be rejected. If the system determines that the Node token that is signed by a trusted Authority is valid, the system may move on to operation  5720 . 
     At operation  5720 , the Module determines if the ID of the Node matches the ID in the token. If the system determines that the ID of the Node does not match the ID in the token, then the sender will be rejected. If the system determines that the ID of the Node does match the ID in the token, the system may move on to operation  5725 . 
     At operation  5725 , the Module extracts the Node&#39;s token and stores the token as trusted. 
     At operation  5730 , the Module determines if the new token is valid and if the new token is signed by a trusted Authority. If the system determines that the new token is not valid and that the new token is not signed by a trusted Authority, then the sender will be rejected. If the system determines that the new token is valid and that the new token is signed by a trusted Authority, the system will update the Module token. 
       FIG.  58    shows an example of a system for CPV management according to aspects of the present disclosure. The example shown includes Module  5800 , Nodes  5805 , Operator  5810 , and Authority  5815 . 
     Module  5800  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  50 ,  64 , and  65   . Node  5805  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  43  and  50   . Operator  5810  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIG.  50   . Authority  5815  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  43 ,  50 ,  64 , and  65   . 
       FIGS.  59 A and  59 B  shows an example of a process for CPV management with an updated Module token according to aspects of the present disclosure. Specifically,  FIGS.  59 A and  59 B  show an overview of the relationship between the systems and methods described with respect to  FIGS.  52 - 57   . 
     Referring next to  FIGS.  60 - 63   , exemplary high-level operational processes for a deployment of the ISDM system are shown. The processes of  FIGS.  60 - 63    demonstrate the relative simplicity of a deployment, balancing the security, privacy, and usability needs of drone manufacturers, drone operators, and drone service suppliers (which may be tasked with implementing remote identification services). 
     Referring next to  FIG.  60   , an exemplary process for remote ID system deployment is shown. 
       FIG.  60    shows an example of a process for deployment readiness according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  6000 , the Authority generates a cryptographic key and a unique ID. 
     At operation  6005 , the Authority creates an Authority token by self-signing a public key, ID, and time validity with a private key. 
     At operation  6010 , the Authority publishes and stores the Authority token by all receivers. 
     Referring next to  FIG.  61   , an exemplary process for CPV or Module manufacture is shown. 
     At operation  6100 , the system provides or receives a new drone. At operation  6105 , the system provides or receives a new Module. At operation  6110 , a key pair and a unique ID are generated per the drone and Module. 
     Referring next to  FIG.  62   , an exemplary process for customer purchase/registration is shown. The Customer Purchase/Registration process exemplifies the low operator effort required to both register their identity and bind it with a drone (in a single step), as well as the ease with which that identity may be securely verified by a variety of constituents, including authorities (e.g. law enforcement), the general public, and other vehicles (e.g. other drones or aircraft). 
     At operation  6200 , the system registers an operator and drone or Module with the Authority via an app. At operation  6205 , the system determines if the registration is approved. If the registration is not approved, the system will provide an error feedback. At operation  6210 , the system stores a drone token on the drone or Module via an app. 
     Referring next to  FIG.  63   , a process for authenticating flight data and identity is shown. 
       FIG.  63    shows an example of a process for verifying a beacon according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     While the drone is in flight, at operation  6300 , the system transmits current time, telemetry, and drone token, signed with a private key. Additionally, while the drone is in flight, the system, at operation  6305 , may also detect a drone with no remote ID. If a drone with no remote ID is detected, the drone will system will feedback an unverified identity of the drone. 
     A drone providing, at least, current time, telemetry, and drone token, will move on to operation  6310 , where the system receives a beacon at an authorized receiver. The drone may also move on to operation  6315 , where the system receives a beacon in a public space. Lastly, a drone may also move on to operation  6320 , where the system receivers a beacon at another drone or aircraft. 
     At operation  6325 , the system determines if a beacon is fresh, valid, and trusted. If the system determines that the beacon is not fresh, valid, and trusted, the system will feedback an unverified identity of the drone. If the system determines that a beacon is fresh, valid, and trusted, the system will feedback a verified identity of the drone. 
     Referring next to  FIG.  64   , an ISDM Operational System is shown in one embodiment of the present invention. 
     It will be understood that the exemplary system shown illustrates available avenues of communication and data, and not all of these avenues are necessarily available at any given time or location. The diagram is not meant to be limiting of any future additions to either system elements or avenues of communication and/or transmission. 
     The location-specific (i.e. having a known location) elements of the ISDM Operational System are the ISDM Gateways (also referred to as Relay Nodes) the ISDM Nodes, and Cellular Towers. The ISDM Relay Nodes are local or gateway communications devices, as previously described. 
     A Gateway in one embodiment is configured to communicate with at least one Node, Authority, or other Gateway within range for sending data transmissions. In some embodiments the Gateway is configured to search for and communicate with all other Gateways and/or Nodes within range. Gateways are typically connected to a Node or Authority via an Internet connection, such as Ethernet. 
     A Gateway is part of and is controlled by the cyber-physical management system. It is related to the Node, but while the Node provides active processing and analysis of activity, among the other services previously described, the Gateway is essentially a transceiver dedicated to the ISDM System. The ISDM Gateway in one embodiment includes a transceiver, an antenna, hardware and software suitable for determining what action to take with incoming data and then taking that action. Each Gateway is associated with a known location. Each Gateway is configured to communicate with at least one Node or Gateway within range for sending data transmissions. In some embodiments each Gateway is configured to search for and communicate with all other Gateways and/or Nodes within range. 
     In operation, a Gateway receives a transmission from a source. The Gateway processes the source and, using information included in the transmission and/or one or more internal algorithms, determines one or more actions to take regarding the transmission. One action would be to forward the transmission to another Node or Gateway. Another action would be to forward the transmission to an ISDM Module within range. 
     A Gateway in one embodiment is configured to communicate with an ISDM Cloud Computing System. In some embodiments the communication is via Ethernet, LTE/4G/5G, and/or WiFi. 
     In another embodiment, as previously described, a Gateway is configured to communicate with an ISDM Module of a CPV when the ISDM Module is within range of the Gateway. 
     In another embodiment, a Gateway is configured to receive GPS transmissions and/or ADS-B (Automatic Dependent Surveillance-Broadcast) transmissions. 
     A Gateway may be configured to receive a single type of transmission, or may be configured to receive multiple types of transmissions. Types of received transmissions include, but are not limited to, radio, GPS, ADS-B, Ethernet, WiFi, LTE/4G/5G, and Long Range Internet Of Things (IoT) Protocol. 
     A Gateway may be configured to transmit a single type of transmission, or may be configured to transmit multiple types of transmissions. Types of sent transmissions include, but are not limited to, radio, Ethernet, WiFi, and Long Range (LoRa) Internet Of Things (IoT) Protocol. 
     A Cloud Computing System may be in communication with Nodes/Authorities, Wireless (Cellular) Infrastructure, Gateways, UTM Service Suppliers, and Client Users (via a Web Portal or other computing application in communication with the Cloud Computing System). The Cloud Computing System includes at least a Master Database and a Client-Dedicated Database. The Master database contains all information about the ISDM system for that deployment, which could a single database storing all global information. This would include: all data associated with Modules (identifiers, public keys, etc.), with Operators/Operators (Names, addresses, pilot numbers), Flights (paths, authorizations), Vehicles (type, size, weight, capabilities), Node (locations, owners, public keys), Gateways (locations, configurations, performance metrics), as well as all received Modules broadcasts (including all data and metadata associated with each broadcast). A client-dedicated database contains a subset of the Master database that may be appropriate for only that client. For example, only access to that customers Module/Operator/Node data and metadata. Client databases may be physically or logically separate, with the latter enforced by access controls. 
     The Cloud Computing System is connected to the Internet. The Cloud Computing system may be configured for various types of wireless/internet connectivity, for example LTE/4G/5G, WiFi and Ethernet. The Cloud Computing System comprises a plurality of computing devices configured to provide the storage, user interfaces, application interfaces, reliability, consistency, partition tolerant, and general networking capabilities, services, and guarantees necessary to make the ISDM a robust, reliable, secure, and usable system. 
     The Cloud Computing System may be in communication with one or more Client Users, in one embodiment via the Client-directed database. In other embodiments, the Cloud Computing System is in communication with one or more Client Users via an access-controlled API, such as an ISDM Web Portal accessed through a dedicated application or a third part web browser application (ISDM Web Portal). 
     In one embodiment the Cloud Computing System may be in communication with one or more unmanned aerial system traffic management (UTM) Service Suppliers via an access-controlled API. The UTM Service Suppliers provide a variety of services for managing drones and the airspace. Examples of services could include collecting resolving, and visualization flight plans, and providing weather or other air space conditions. 
     A Node or Authority element communicates with the Cloud computing system. The Node or Authority element downloads updates and pre-initializes Modules assigned to the Node from the Cloud Computing System. The Node or Authority element uploads Module registration and logs to the Cloud Computing System. The Cloud computing System may be in communication with the Node or Authority element via Ethernet, WiFi, LTE/4G/5G, or other suitable type of data communication. 
     As previously described, each Node or Authority is configured to provide a database, processing, and a user interface (visualization). Each Node or Authority is configured to display information and/or receive input from a Client User. In one embodiment, the Node or Authority displays local data only if it does not have connection to the internet. The Node or Authority displays all user-assigned Nodes and downloads/uploads real-time data. 
     Existing Wireless Infrastructure such as cellular towers may be used to relay communications between the ISDM Module and Cloud Computing System. Communication between a Wireless Infrastructure and the ISDM Module may be via LTE/4G/5G and use secure telemetry. 
     A CPV with an associated ISDM Module is in communication with the Node/Authority elements and the Cloud Computing System, as previously described. The ISDM Module is also configured to receive GPS data. The ISDM Module is also configured to communicate with other CPVs (having an ISDM Module or not) via Detect And Avoid (DAA), which includes the hardware and software necessary for two CPVs to sense and avoid collision. The ISDM Module is also configured to communicate with a Public User via WiFi or other suitable wireless connection. 
     The contents of every message sent by the Module, regardless of the means of transmission, can be cryptographically signed. This provides authenticity, integrity, and non-repudiation on the message—meaning an adversary cannot forge, alter, or impersonate an ISDM Module or any messages transmitted by the Module. This security guarantee can be verified by anyone in possession of the Module&#39;s public cryptographic key. This includes, but is not limited to, ISDM gateways, ISDM Nodes, public telecommunication infrastructure (e.g. LTE networks), UAS (Unmanned Aerial System) Service Supplier, and individuals. This technique provides end-to-end authentication of the Module message, meaning that the data is authentic from the Module until its final consumer or storage end point. Authenticity can be determined in real-time as the Module message is received, or after the fact when the data is, for example, stored in a database. The latter enables Module data to be collected, even without possession of the verifying key (e.g. when the receiver does not possess the key and is disconnected from any entity that does), but later verified once the key is acquired. 
     Receivers, either ground-based or on other Modules or drones, may be configured to 1) process, store, or visualize data locally, or 2) forward data to a separate processing, storage, or visualization device, or 3) forward data to a separate, dedicated UAS Traffic Management (UTM)/UAS Service Supplier (USS), or 4) forward data to a distributed “cloud” service providing similar storage, processing, and visualization capabilities, or 5) any combination of the preceding configurations. Indeed, two-way communication between data providers is considered, and will be essential to achieving a comprehensive air space management solution. Access to data can be controlled with access control policies applied at any of the receivers or at the Module. 
     When data is authentic and trusted, complex decisions (e.g. dynamic flight plans, real time traffic deconfliction, etc.) can be made more reliably. For example, to implement real time air space traffic deconfliction, two Modules may direct communicate with each other, verifying the data and adjust their trajectories accordingly. 
     Nodes may also independently and authentically communicate with Modules or other Nodes for the purpose of updating flight plans, providing weather advisories, Temporary Flight Restriction (TFR) data, received ADS-B data, etc. All information may be cryptographically signed before transmission, allowing all entities to verify the authenticity of the data. Modules may then forward this information on to other Modules, or to other Nodes, which may in turn, forward to a centralized server. In essence, Modules and Nodes can create a mesh-like network of authentic data and would allow a single, comprehensive view of a larger geographic area than could be detected by a single Node. 
     As previously described, the ISDM Module may be comprised of an independent processor, storage, a means for wired and wireless communication, and sensors useful in securely identifying, tracking, and managing the airspace for a cyber-physical vehicle, such as a car, person, aircraft, or drone. We use a drone as the example application. 
     The Module is a rich source of data useful in identifying and tracking a CPV that is collected independent of the CPV&#39;s own sensor package. Independent sensors considered include, but are not limited to, GPS, gyroscope, accelerometer, barometer, altimeter, temperature, and air speed. 
     Independent sensors can provide a variety of useful data by themselves, but also when combined. For example, in areas where GPS is intermittent, limited or blocked, sensors such as the accelerometer and barometer can be used to estimate the current location. Simple filtering techniques performed on the Module can substantially improve location accuracy in these conditions. For example, given a post known location a speed and a heading, an estimate of the current location may be made. More advanced techniques, such as those that use Kalman filters can provide even more accurate estimates for location, heading, speed, and other useful data for airspace management. The Module also supports RTK (Real Time Kinematic) &amp; PPK (Post Processed Kinematic) means for more precise geolocation and positioning. Further, using ground stations (Nodes) with good, known position, a secure and unforgeable messages can be exchanged with the Module to also provide more accurate positioning data. 
     Encasing sensors, along with the computation and radio components, in a physically secure, tamper—resistant and/or -evident enclosure help increase the validity and trust of transmitted data. In this way, the Module acts like a secure flight data recorder for the drone. 
     The message format for the Modules may contain a cryptographic hash of the data in the previously transmitted message. By relying upon the collision resistant properties of the hash function (i.e. that it is computationally infeasible to find two different messages that produce the same hash), the hash acts like a fingerprint for the previous message, creating an unforgeable chain in the order of those messages. This technique creates a tamper-proof, total ordering of all the messages that is cryptographically verifiable, and provides for an authentic, auditable history of Module data. This data can be securely stored on the Module itself, for example, using the Module&#39;s cryptographic coprocessor and encrypted storage, for retrieval after the flight. This data can also be stored and verified at any receiver, including the Node and Authority. 
     To further secure the device and prevent tampering, all code running on the Module can be encrypted and cryptographically signed to ensure no modifications are made or secrets stored on the device revealed. This can be done by burning cryptographic keys into a write-once area of memory that is only accessible to the processor for certain operations. For example, the firmware can be cryptographically signed prior to being burned into the Module&#39;s memory (e.g. at the factory), and the verifying key placed into a secure area of memory that can be written once but read many times. The processor can be configured so that only software that is cryptographically verified with the secure stored key will be loaded and executed on the processor, and unverifiable software will not be run. To further protect data and code stored on the Module, it may be encrypted prior to being written to the Module using a cryptographic key. The decryption key may be stored in a special area of memory on the Module that can only be written once and only accessible to processor for the purpose of decryption. Alternatively or in addition to the main processor, a separate cryptographic coprocessor and storage device to provide a trusted execution environment, which provide hardware-based guarantees on the confidentiality and integrity of both code executed and data stored within the Module. 
     Given the hardware capabilities, the Module is able to act as a secure “platform” for custom applications, algorithms, data elements, and protocols that independent developers may create for their own purposes. For example, custom algorithms and sensors for enabling autonomous flight, detect and avoid algorithms, computer vision applications, etc., can enjoy a trusted execution environment as well as a secure means for data communication and storage. These custom algorithms can be securely implemented regardless of whether the Module is a separate physical device or integrated directly into a drone. Custom algorithms may be primarily stored and executed on the CPV, but leverage the secure capabilities of the Module when necessary. For example, a geofencing feature (one which restricts the flight area of a CPV) could be primarily implemented on the drone, but use the integrity features provided by the Module to guarantee the geofencing data is authentic (e.g. has not been modified by an operator). A CPV&#39;s authorization to fly could also be enforced by the Module: e.g. a CPV will only take off if a cryptographically-signed flight plan, or operator license, or other authorization data is present and verified by the Module. 
     Modules also support a variety of communication mediums and protocols. These include, but are not limited to, long range protocols that leverage existing, public or private telecommunication infrastructure (e.g. ADS-B, TDMA, CDMA, LTE, or 5G networks), long range protocols that use custom infrastructure (e.g. LoRa, or LoRaWAN), and short range protocols (e.g. WiFi, Bluetooth, or Zigbee). Any or all of the communication methods may be used at the same time to communicate the same or different data. For example, a short-range message may contain less (or more) information than what might be transmitted via a long-range transmission means. This flexibility enables different levels of privacy as well as could affect transmission time, bandwidth, or frequency. For example, short-range messages may be transmitted very frequently, containing less information, so that ground-based stations or other drones may make detect and avoid decisions more quickly. 
     In addition to being able to broadcast ADS-B messages, Modules can also be configured to support receiving ADS-B messages from other Modules and other aircraft. Like above, with support from ADS-B data, Modules may also deconflict with existing air traffic. This particularly valuable in situations where existing air traffic does not support the Module&#39;s protocol. 
       FIG.  64    shows an example of a CPV  6410  system according to aspects of the present disclosure. The example shown includes general public  6400 , Module  6405 , CPV  6410 , GNSS  6415 , aircraft  6420 , Gateway  6425 , Base Station  6430 , Cloud Computing System  6435 , USS  6450 , web portal  6455 , client  6460 , and Authority  6465 . 
     Module  6405  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  50 ,  58 , and  65   . CPV  6410  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  38  and  65   . 
     In some examples, the set of ISDM stations includes at least one Gateway  6425  device configured to relay ISDM communications between two devices from the group of CPVs  6410  and ISDM stations. 
     Gateway  6425  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIG.  65   . 
     In some examples, at least one base station  6430  includes a GPS receiver configured to determine RTK correctional data from received GPS signals and configured to send RTK correctional data to at least one of the ISDM Module  6405 , at least one ISDM station, the EPC Network, and the Internet Gateway  6425 . In some examples, the at least one base station  6430  includes a wireless infrastructure tower. In some examples, the wireless infrastructure tower is configured to send RTK data directly to the ISDM Module  6405  using wireless broadband communication. In some examples, the wireless infrastructure tower is configured to send RTK data indirectly to the ISDM Module  6405  through one of the EPC Network and an Internet Gateway  6425  to one ISDM Station, whereby the ISDM station transmits the RTK data to the ISDM Module  6405 . In some examples, the data received by the ISDM Gateway  6425  from the ISDM Module  6405  is secure telemetry. In some examples, the data received by the Cellular Infrastructure  6430  from the ISDM Module  6405  is secure telemetry. In this way the data received from the Module  6405  is authentic and from a known identity. The secure telemetry may in some embodiments be used to provide authentic (secure) corrective location information to a Module from a Ground Station. This will enhance the precise location of the Module in a trustworthy way. 
     Base Station  6430  may receive at least one GPS signal by a base station  6430  including a GPS receiver. Base Station  6430  may also determine, from the GPS signal, RTK correctional data by the base station  6430 . Base Station  6430  may also send the RTK correctional data to an ISDM base station  6430  via one of an EPC Network and an Internet Gateway  6425 , where the ISDM base station  6430  is within wireless communication range of the CPV  6410 . Base Station  6430  may also authenticate an identity of the CPV  6410 . Base Station  6430  may also send, in response to authenticating the identity of the CPV  6410 , the RTK correctional data to an ISDM Module  6405  mechanically coupled to and in communication with the CPV  6410 . 
     Base Station  6430  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIG.  65   . 
     Cloud Computing System  6435  may be communication with the set of ISDM stations and including at least one processor, at least one database, and data stored on the at least one database including Module  6405  registration and authorization data, whereby the ISDM system is configured to securely receive, send, store, and relay CPV  6410  registration and authorization information. Cloud Computing System  6435  may include master database  6440  and client-dedicated database  6445 . 
     Authority  6465  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  43 ,  50 ,  58 , and  65   . 
     Referring next to  FIG.  65   , a system for real-time kinematic position of CPVs is shown. 
     Global Navigation Satellite Systems (GNSS), such as GPS, have a real-time accuracy of around 1-3 meters. Real-Time Kinetic Positioning (RTK), as known in the art, is a technique used to obtain greater real-time accuracy, in some embodiments at the centimeter level. RTK uses measurements of the phase of the GPS signal&#39;s carrier wave in additional to the information content of the GPS signal and uses a base station with a known location to provide real-time location corrections to a CPV or other roving vehicle. This system maintains the security and authenticity of the ISDM system while also improving accuracy. As CPVs become more common, and are operated in dense areas, increased accuracy is necessary for navigation and collision avoidance. 
     In one embodiment of the invention, a wireless (cellular) infrastructure tower with a known location includes a GPS receiver, and acts as an RTK base station. The GPS receiver is configured for RTK calculations. The wireless infrastructure tower transmits the RTK correction data to the Module on the CPV. The RTK correction data includes phase data, time data, and location data. In some embodiments the data is sent using a logical channel. The Module includes the necessary hardware and software components in order to support RTK. The Module is configured to receive the RTK correction data. The Module can then combine the RTK correction data with the GPS data received on the CPV GPS receiver to update the known position of the CPV based on the RTK correction data. The Module can use the updated positioning for any Module function that requires positioning data, and/or can pass the updated position to the CPV. 
     In some embodiments the Module may contact the wireless infrastructure tower and the wireless infrastructure tower can transmit the RTK correction data to the Module in response. 
     In some embodiments the RTK correction data is transmitted directly to the Module from the wireless infrastructure tower using a wireless broadband communication. In one embodiment the wireless broadband communication is LTE/4G, 5G, or any other suitable wireless broadband standard. 
     In other embodiments the RTK correction data is transmitted from the wireless infrastructure tower indirectly through an EPC Network or Internet Gateway to a Node, Gateway (Relay Node), or Authority. The Node, Gateway, or Authority then transmits the RTK correction data to the Module. 
     In other embodiments a Node or Gateway with a known location includes a GPS receiver configured to provide real-time RTK corrections. The Node or Gateway then communicates with the Module over any suitable method that both Node/Gateway and Module are configured for, for example wireless broadband (e.g. LTE/4G/5G), LoRa (Long Range), or other suitable radio protocol. 
     In other embodiments the Node/Gateway/Authority (also referred to as an ISDM Station), or a wireless infrastructure tower receives the GPS signals, determines the RTK correction data, and sends the correction data to a second wireless infrastructure tower (where the second cellular tower is in direct communication with the Module) via the EPC Network or Internet Gateway. The Node/Gateway/Authority may send the RTK correction data to the EPC Network or Internet Gateway via Internet, wireless broadband, or other suitable communication method. The second wireless infrastructure tower then transmits the RTK correction data to the Module. 
     In other embodiments the Module is in communication with a dedicated RTK base station, where the Module receives the RTK correction data via a wireless broadband connection or through a dedicated radio channel. 
     As RTK correction data generally requires the distance between the Module and the base station to be approximately 3 miles or less, the Module is additionally configured to search for and identify nearby suitable local base stations (wireless infrastructure towers, Nodes, and Gateways) that are within the required distance. The Module then selects a base station to receive RTK correction data from. The selection can be made based on various criteria, such as proximity, signal strength, frequency band, owner/operator identity, whether the base station is disconnected or connected to the internet or other ISDM services, whether the base station can prove its identity to the Module, etc. The Module may continually determine the most suitable nearby base station and change base stations for RTK correction data if a more suitable base station is found. 
       FIG.  65    shows an example of a CPV  6505  system according to aspects of the present disclosure. The example shown includes satellite  6500 , CPV  6505 , Module  6510 , Base Station  6515 , Authority  6520 , and Gateway  6525 . 
     CPV  6505  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  38  and  64   . Module  6510  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  50 ,  58 , and  64   . 
     Base Station  6515  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIG.  64   . Authority  6520  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIGS.  43 ,  50 ,  58 , and  64   . Gateway  6525  may be an example of, or include aspects of, the corresponding element or elements described with reference to  FIG.  64   . 
     Referring next to  FIG.  66   , a method for determining positioning of a CPV is shown. 
     In the first step  600 , a base station including a GPS receiver receives at least on GPS signal. 
     In the second step  6605 , the base station determines RTK correctional data from the GPS signal. 
     In the third step  6610  the base station sends the RTK correctional data to an ISDM base station within wireless communication range of the CPV. In some embodiments the RTK correctional data is sent via EPC Network or Internet Gateway. 
     In the fourth step  6615  the ISDM base station authenticates the identity of the CPV. 
     In the fifth step  6620 , in response to authenticating the identity of the CPV the SIDM base station send the RTK correctional data to an ISDM Module mechanically coupled to and in communication with the CPV. 
     In the sixth step  6625 , the GPS receiver of the ISDM Module receives at least one GPS signal. 
     In the seventh and last step  6630 , the ISDM Module performs Real-Time Kinematic (RTK) positioning calculations based on the at least one GPS signal received by the ISDM Module and the received RTK correctional data, whereby the position of the CPV is determined in real-time. 
     Some of the functional units described in this specification have been labeled as Modules, or components, to more particularly emphasize their implementation independence. For example, a Module may be implemented as a hardware circuit comprising custom very large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A Module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like. 
     Modules may also be implemented in software for execution by various types of processors. An identified Module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified Module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the Module and achieve the stated purpose for the Module. 
     Indeed, a Module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within Modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. 
       FIG.  66    shows an example of a process for performing RTK positioning according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  6600 , the system receives at least one GPS signal by a base station including a GPS receiver. At operation  6605 , the system determines the RTK correctional data by the base station. At operation  6610 , the system sends the RTK correctional data to an ISDM base station via one of an EPC network and an internet gateway, where the ISDM base station is within wireless communication range of the CPV. At operation  6615 , the system authenticates an identity of the CPV. 
     At operation  6620 , the system sends the RTK correctional data to an ISDM Module that is mechanically coupled to and in communication with the CPV. At operation  6625 , the system receives at least one GPS signal by a GPS receiver of the ISDM Module. At operation  6630 , the system performs RTK positioning calculations based on the at least one GPS signal received by the ISDM Module and the received RTK correctional data, whereby the position of the CPV is determined in real-time. 
       FIG.  67    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  6700 , the Authority generates, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  6705 , the Authority creates a self-signed Authority token signed by the private key. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  6710 , the Authority sends the Authority token to a set of ISDM Node device configured to verify Module device authenticity and in communication with the Authority. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  6715 , the Node stores the Authority token. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  6720 , the Node marks the Authority token as trusted. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
       FIG.  68    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  6800 , the CPV Authentication Component generates, by a Module, a public/private key pair and a unique ID. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  6805 , the Radio Transmitter sends, to an Authority the ISDM system, where the Authority has an Authority token and is configured to manage licensing and approval of CPVs, a token request including the public/private key pair and unique ID. In some cases, the operations of this step may refer to, or be performed by, a Radio Transmitter as described with reference to  FIG.  38   . 
     At operation  6810 , the Authority determines, by the Authority, if the token request is approved. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  6815 , the Authority creates by the Authority of a Module token, the Module token including the Module ID and public key and a range of time for which the Module token is valid upon determining that the token request is approved. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  6820 , the system sends, by the Authority of the Module token and the Authority token, to the Module. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  6825 , the CPV Authentication Component stores, by the Module, the Authority token and the Module token. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
       FIG.  69    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  6900 , the Radio Transmitter broadcasts, by a Module, a Module message including a current time and a Module token associated with the Module and including a public Module key and a Module ID, where the Module message is signed under a Module private key. In some cases, the operations of this step may refer to, or be performed by, a Radio Transmitter as described with reference to  FIG.  38   . 
     At operation  6905 , the Radio Receiver receives the Module broadcast by an ISDM device of the ISDM system. In some cases, the operations of this step may refer to, or be performed by, a Radio Receiver as described with reference to  FIG.  38   . 
     At operation  6910 , the Node determines, by the ISDM device, whether the signature of the Module message is valid. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  6915 , the Node identifies the Module as unauthorized upon determining that the signature is invalid. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  6920 , the Node extracts by the observing device of the Module token from the Module message upon determining that the signature is valid. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  6925 , the Node performs by the ISDM device of at least one authorization test, whereby the Module is identified as authorized if each of the at least one authorization test is passed upon extracting the Module token. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
       FIG.  70    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  7000 , the Authority generates, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7005 , the Authority creates a self-signed Authority token signed by the private key. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7010 , the Authority sends the Authority token to a set of ISDM Node devices configured to verify Module device authenticity and in communication with the Authority. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7015 , the Node generates a Node public/private key pair and a unique Node ID. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7020 , the Node sends to the Authority a token request including at least the Node public key and the Node private key, where the token request is signed under the Node private key. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7025 , the Authority determines whether the token request is approved. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7030 , the Authority creates a Node token for the approved Node, the Node token includes the Node ID, the Node public key, the Authority public key, the Authority ID, and a range of time for which the token is valid, where the Node token is signed under the Authority private key upon approval of the token request. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7035 , the Authority sends the Node token and Authority token to the Node. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7040 , the Node stores the Node token and Authority token to the Node. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7045 , the Node marks the Authority token stored on the Node as trusted. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
       FIG.  71    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  7100 , the CPV Authentication Component generates, by the Module, a public/private key pair and a unique ID. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7105 , the Radio Transmitter sends, to an Authority of the ISDM system, where the Authority is configured to manage licensing and approval of CPVs, a registration request including the public key and unique ID. In some cases, the operations of this step may refer to, or be performed by, a Radio Transmitter as described with reference to  FIG.  38   . 
     At operation  7110 , the Authority determines if the registration request is approved. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7115 , the Authority registers the Module public key and the unique ID with the ISDM system upon determining that the registration request is approved. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
       FIG.  72    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  7200 , the Operator of the CPV registers information with an Authority of the ISDM system, where the Authority is configured to manage licensing and approval of CPVs, where the information required is determined by the Authority. In some cases, the operations of this step may refer to, or be performed by, an Operator as described with reference to  FIGS.  50  and  58   . 
     At operation  7205 , the Authority stores by the Authority of the information. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7210 , the Authority associates by the Authority of the information with the Module. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
       FIG.  73    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  7300 , the Radio Transmitter broadcasts of a Module message by the Module, the Module message including a current time, and a Module token associated with the Module and including a public Module key and a Module ID, where the Module message is signed under a Module private key. In some cases, the operations of this step may refer to, or be performed by, a Radio Transmitter as described with reference to  FIG.  38   . 
     At operation  7305 , the Node receives the Module broadcast by a Node device of the ISDM system, the Node device configured to verify Module authenticity and having a Node private key, a Node public key, and a Node token signed by an Authority of the ISDM system, where the Authority is configured to manage licensing and approval of CPVs. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7310 , the Node determines whether the signature of the Module message is valid by using the Module public key. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7315 , the Node identifies the Module as unauthorized upon determining that the signature is invalid. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7320 , the Node extracts the Module ID from the Module message upon determining that the signature is valid. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7325 , the Node creates an Authority query message signed using the Node private key and including the Module ID and the Node token. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7330 , the Node sends, over a network, the Authority query message to the Authority. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7335 , the Authority determines whether the signature is valid and whether the Node token was signed by a trusted Authority. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7340 , the Authority reports that the query is unauthorized upon determining that the signature is invalid, or the Node token is not signed by the trusted Authority. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7345 , the Authority sends to the Node a reply including at least the Module ID and the Module public key, where the reply is signed under an Authority private key of the sending Authority upon determining that the signature is valid and the Node token is signed by the trusted Authority. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7350 , the Node verifies the validity of the signature of the reply and verifying that the signing Authority is trusted upon receiving the reply. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7355 , the Node identifies the Module as authorized upon determining that the signature is valid and the signing Authority is trusted. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7360 , the Node identifies the Module as unauthorized upon determining that the signature is invalid, or the Authority is not trusted. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50   , and 
       FIG.  74    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  7400 , the Radio Transmitter broadcasts of a Module message by the Module, the Module message including a current time, and a Module token associated with the Module and including a public Module key and a Module ID, where the Module message is signed under a Module private key. In some cases, the operations of this step may refer to, or be performed by, a Radio Transmitter as described with reference to  FIG.  38   . 
     At operation  7405 , the Node receives of the message by an observing device. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7410 , the Observer extracts the Module ID. In some cases, the operations of this step may refer to, or be performed by, an Observer as described with reference to  FIG.  50   . 
     At operation  7415 , the Observer creates an Authority query message including the Module ID. In some cases, the operations of this step may refer to, or be performed by, an Observer as described with reference to  FIG.  50   . 
     At operation  7420 , the Observer sends the query message to an Authority, where the Authority is configured to manage licensing and approval of CPVs. In some cases, the operations of this step may refer to, or be performed by, an Observer as described with reference to  FIG.  50   . 
     At operation  7425 , the Authority determines whether the query is authorized. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7430 , the Authority identifies the Module CPV Authentication Component. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
       FIG.  75    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  7500 , the CPV Authentication Component generates a public/private key pair and a unique ID. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7505 , the Radio Receiver receives, from a trusted Authority of the ISDM system, where the Authority is configured to manage licensing and approval of CPVs, an Authority token. In some cases, the operations of this step may refer to, or be performed by, a Radio Receiver as described with reference to  FIG.  38   . 
     At operation  7510 , the CPV Authentication Component stores the Authority token as trusted. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
       FIG.  76    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  7600 , the Operator of the CPV generates a token request including CPV and operator identification information. In some cases, the operations of this step may refer to, or be performed by, an Operator as described with reference to  FIGS.  50  and  58   . 
     At operation  7605 , the Radio Transmitter sends the token request to an Authority of the ISDM system, where the Authority is configured to manage licensing and approval of CPVs. In some cases, the operations of this step may refer to, or be performed by, a Radio Transmitter as described with reference to  FIG.  38   . 
     At operation  7610 , the Authority determines, based on the information, by the Authority if flight is authorized. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7615 , the Authority sends by the Authority of a Module token to the operator upon authorization of flight. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7620 , the CPV Authentication Component stores of the Module token on the Module. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
       FIG.  77    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  7700 , the Radio Transmitter broadcasts of a Module message by the Module, the Module message including a current time, and a current Module token associated with the Module and including a public Module key and a Module ID, where the Module message is signed under a Module private key. In some cases, the operations of this step may refer to, or be performed by, a Radio Transmitter as described with reference to  FIG.  38   . 
     At operation  7705 , the Node receives of the message by an ISDM Node device configured to verify Module authenticity and having a private key and a Node token including a Node public key. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7710 , the Node generates the new Module token including at least a portion of the current Module token, the new token signed by a private key of the Node device. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7715 , the Node sends a message to the Module, the message including the new Module token and the Node token, where the message is signed under the Node private key. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  7720 , the CPV Authentication Component verifies by the Module of the message signature upon receiving the message. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7725 , the CPV Authentication Component rejects of the message by the Module upon determining that the signature is invalid. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7730 , the CPV Authentication Component extracts by the Module of the Node token, verifying that the Node token was signed by a trusted Authority of the ISDM system, where the Authority is configured to manage licensing and approval of CPVs, and verifying that the Node has Authority for signing Module tokens upon determining that the signature is valid. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7735 , the CPV Authentication Component rejects the message upon determining that the Node token was not signed by a trusted Authority or that the Node does not have Authority for signing tokens. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7740 , the CPV Authentication Component determines by the Module whether the Node public key corresponds to the Node private key upon determining that the Node token was signed by a trusted Authority and that the Node has Authority for signing tokens. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7745 , the CPV Authentication Component rejects of the message by the Module upon determining that the Node public key does not correspond to the Node private key. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7750 , the CPV Authentication Component stores the Node public key as trusted and extracting the new Module token upon determining that the Node public key corresponds to the Node private key. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7755 , the CPV Authentication Component verifies by the Module whether the new Module token was signed by the trusted Authority. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7760 , the CPV Authentication Component rejects the new Module token upon determining that the new Module token was not signed by one trusted Authority. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
     At operation  7765 , the CPV Authentication Component stores by the Module of the new Module token such that the new Module token is sent in future broadcasts upon determining that the new Module token was signed by the trusted Authority. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
       FIG.  78    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  7800 , the Authority generates, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7805 , the Authority creates a self-signed Authority token by self-signing the public key, the unique ID, and a valid range of time, where the Authority token is signed by the private key. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7810 , the Authority sends the Authority token to a set of ISDM receivers configured to verify ISDM Module authenticity. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7815 , the Authority stores, by each receiver, the Authority token. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  7820 , the Authority publishes the Authority token by each receiver. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
       FIG.  79    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  7900 , the system provides a CPV. 
     At operation  7905 , the system provides a Module device associated with the CPV and configured to be mechanically coupled to and in communication with the CPV. 
     At operation  7910 , the system generates a public key, a private key, and a unique ID. 
     At operation  7915 , the system associates the public key, the private key, and the unique ID with the CPV and the Module device. 
       FIG.  80    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  8000 , the Operator purchases a CPV and Module by an operator. In some cases, the operations of this step may refer to, or be performed by, an Operator as described with reference to  FIGS.  50  and  58   . 
     At operation  8005 , the Operator requests registration of the CPV and the Module with an Authority of the ISDM system, the Authority configured to manage licensing and approval of CPVs. In some cases, the operations of this step may refer to, or be performed by, an Operator as described with reference to  FIGS.  50  and  58   . 
     At operation  8010 , the Authority determines if the registration is approved. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  8015 , the Authority returns an error message to the operator upon determining that the registration is not approved. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  8020 , the Authority registers the CPV and the Module with the ISDM system upon determining that the registration is approved. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  8025 , the Authority returns to the Module by the Authority a CPV token upon registering. In some cases, the operations of this step may refer to, or be performed by, an Authority as described with reference to  FIGS.  43 ,  50 ,  58 ,  64 , and  65   . 
     At operation  8030 , the CPV Authentication Component stores, by the Module, the CPV token. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
       FIG.  81    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  8100 , the Radio Transmitter broadcasts, by the CPV, a message by the CPV, the message including at least a CPV token signed with a private key of the CPV, a current time, and current telemetry. In some cases, the operations of this step may refer to, or be performed by, a Radio Transmitter as described with reference to  FIG.  38   . 
     At operation  8105 , the Observer receives the message. In some cases, the operations of this step may refer to, or be performed by, a Radio Receiver as described with reference to  FIG.  38   . 
     At operation  8110 , the Observer determines if the message is fresh, valid and trusted. In some cases, the operations of this step may refer to, or be performed by, an Observer as described with reference to  FIG.  50   . 
     At operation  8115 , the CPV Authentication Component verifies the identity of the CPV upon determining that the message is fresh, valid, and trusted. In some cases, the operations of this step may refer to, or be performed by, a CPV Authentication Component as described with reference to  FIG.  38   . 
       FIG.  82    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. 
     At operation  8200 , the system provides an ISDM Module mechanically coupled to and in communication with an associated CPV, the ISDM Module configured to broadcast a beacon of identity. In some cases, the operations of this step may refer to, or be performed by, a Module as described with reference to  FIGS.  50 ,  58 ,  64 , and  65   . 
     At operation  8205 , the system provides a set of ISDM Stations where each ISDM station is configured to support at least one of the groups of CPV authentication, CPV authorization, and secure communication between ISDM Modules and other ISDM Stations. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  8210 , the system provides a cloud computing system in communication with the set of ISDM stations and including at least one processor, at least one database, and data stored on the at least one database including Module registration and authorization data, whereby the ISDM system is configured to securely receive, send, store, and relay CPV registration and authorization information. In some cases, the operations of this step may refer to, or be performed by, a Cloud Computing System as described with reference to  FIG.  64   . 
       FIG.  83    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. 
     At operation  8300 , the system provides an ISDM Module mechanically coupled to and in communication with the CPV, the ISDM Module configured to provide a beacon of identity and including a GPS receiver configured to receive RTK correctional data and perform RTK positioning calculations based on the received RTK correctional data, whereby the position of the CPV is determined in real-time. In some cases, the operations of this step may refer to, or be performed by, a Module as described with reference to  FIGS.  50 ,  58 ,  64 , and  65   . 
     At operation  8305 , the system provides at least one ISDM Station, where each ISDM station is one of an ISDM Node, an ISDM Authority, and an ISDM Gateway, where each ISDM station has a known location, includes a GPS receiver configured to determine RTK correctional data from received GPS signals, is configured to support authentication, authorization, and secure communication between ISDM Modules and other ISDM Stations, configured to send RTK correctional data to the ISDM Module, and configured to receive RTK correctional data from one of an EPC Network and an Internet Gateway. In some cases, the operations of this step may refer to, or be performed by, a Node as described with reference to  FIGS.  43 ,  50 , and  58   . 
     At operation  8310 , the system provides at least one base station including a GPS receiver configured to determine RTK correctional data from received GPS signals and configured to send RTK correctional data to at least one of the ISDM Module, at least one ISDM station, the EPC Network, and the Internet Gateway. In some cases, the operations of this step may refer to, or be performed by, a Base Station as described with reference to  FIGS.  64  and  65   . 
       FIG.  84    shows an example of a process for cyber-physical vehicle management according to aspects of the present disclosure. In some examples, these operations may be performed by a system including a processor executing a set of codes to control functional elements of an apparatus. Additionally or alternatively, the processes may be performed using special-purpose hardware. Generally, these operations may be performed according to the methods and processes described in accordance with aspects of the present disclosure. For example, the operations may be composed of various substeps, or may be performed in conjunction with other operations described herein. 
     At operation  8400 , the Base Station receives at least one GPS signal by a base station including a GPS receiver. In some cases, the operations of this step may refer to, or be performed by, a Base Station as described with reference to  FIGS.  64  and  65   . 
     At operation  8405 , the Base Station determines, from the GPS signal, RTK correctional data by the base station. In some cases, the operations of this step may refer to, or be performed by, a Base Station as described with reference to  FIGS.  64  and  65   . 
     At operation  8410 , the Base Station sends, by the base station, the RTK correctional data to an ISDM base station via one of an EPC Network and an Internet Gateway, where the ISDM base station is within wireless communication range of the CPV. In some cases, the operations of this step may refer to, or be performed by, a Base Station as described with reference to  FIGS.  64  and  65   . 
     At operation  8415 , the Base Station authenticates, by the ISDM base station, an identity of the CPV. In some cases, the operations of this step may refer to, or be performed by, a Base Station as described with reference to  FIGS.  64  and  65   . 
     At operation  8420 , the Base Station sends, by the ISDM base station in response to authenticating the identity of the CPV, the RTK correctional data to an ISDM Module mechanically coupled to and in communication with the CPV. In some cases, the operations of this step may refer to, or be performed by, a Base Station as described with reference to  FIGS.  64  and  65   . 
     At operation  8425 , the GPS/Telemetry Module receives at least one GPS signal by a GPS receiver of the ISDM Module. In some cases, the operations of this step may refer to, or be performed by, a GPS/Telemetry Module as described with reference to  FIG.  38   . 
     At operation  8430 , the GPS/Telemetry Module performs, by the ISDM Module, RTK positioning calculations based on the at least one GPS signal received by the ISDM Module and the received RTK correctional data, whereby the position of the CPV is determined in real-time. In some cases, the operations of this step may refer to, or be performed by, a GPS/Telemetry Module as described with reference to  FIG.  38   . 
     Accordingly, the present disclosure includes the following embodiments. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may generating, by an Integrated Secure Device Manager (ISDM) Authority configured to manage licensing and approval of Cyber-Physical Vehicle (CPV)s, a public/private key pair and a unique ID for the Authority, creating a self-signed Authority token signed by the private key, sending the Authority token to a plurality of ISDM Node device configured to verify Module device authenticity and in communication with the Authority, storing, by each Node, the Authority token, and marking, by each Node, the Authority token as trusted. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to generate, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority, create a self-signed Authority token signed by the private key, send the Authority token to a plurality of ISDM Node device configured to verify Module device authenticity and in communication with the Authority, store, by each Node, the Authority token, and mark, by each Node, the Authority token as trusted. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: generate, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority, create a self-signed Authority token signed by the private key, send the Authority token to a plurality of ISDM Node device configured to verify Module device authenticity and in communication with the Authority, store, by each Node, the Authority token, and mark, by each Node, the Authority token as trusted. 
     In some examples, the Authority token comprises the unique ID, the public key, and a range of time for which the token is valid. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may generating, by a Module, a public/private key pair and a unique ID, sending, to an Authority of the ISDM system, wherein the Authority has an Authority token and is configured to manage licensing and approval of CPVs, a token request including the public/private key pair and unique ID, determining, by the Authority, if the token request is approved, creating by the Authority of a Module token, the Module token including the Module ID and public key and a range of time for which the Module token is valid upon determining that the token request is approved, sending, by the Authority of the Module token and the Authority token to the Module, and storing, by the Module, the Authority token and the Module token. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to generate, by a Module, a public/private key pair and a unique ID, send, to an Authority of the ISDM system, wherein the Authority has an Authority token and is configured to manage licensing and approval of CPVs, a token request including the public/private key pair and unique ID, determine, by the Authority, if the token request is approved, create by the Authority of a Module token, the Module token including the Module ID and public key and a range of time for which the Module token is valid upon determining that the token request is approved, send, by the Authority of the Module token and the Authority token to the Module, and store, by the Module, the Authority token and the Module token. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: generate, by a Module, a public/private key pair and a unique ID, send, to an Authority of the ISDM system, wherein the Authority has an Authority token and is configured to manage licensing and approval of CPVs, a token request including the public/private key pair and unique ID, determine, by the Authority, if the token request is approved, create by the Authority of a Module token, the Module token including the Module ID and public key and a range of time for which the Module token is valid upon determining that the token request is approved, send, by the Authority of the Module token and the Authority token to the Module, and store, by the Module, the Authority token and the Module token. 
     In some examples, the Module token further comprises at least one of a unique ID of the Authority and a public key of the Authority. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may broadcasting, by a Module, a Module message including a current time and a Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receiving of the Module broadcast by an ISDM device of the ISDM system, determining, by the ISDM device, whether the signature of the Module message is valid, identifying the Module as unauthorized upon determining that the signature is invalid, extracting by the observing device of the Module token from the Module message upon determining that the signature is valid, and performing by the ISDM device of at least one authorization test, whereby the Module is identified as authorized if each of the at least one authorization test is passed upon extracting of the Module token. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to broadcast, by a Module, a Module message including a current time and a Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receive of the Module broadcast by an ISDM device of the ISDM system, determine, by the ISDM device, whether the signature of the Module message is valid, identify the Module as unauthorized upon determining that the signature is invalid, extract by the observing device of the Module token from the Module message upon determining that the signature is valid, and perform by the ISDM device of at least one authorization test, whereby the Module is identified as authorized if each of the at least one authorization test is passed upon extracting of the Module token. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: broadcast, by a Module, a Module message including a current time and a Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receive of the Module broadcast by an ISDM device of the ISDM system, determine, by the ISDM device, whether the signature of the Module message is valid, identify the Module as unauthorized upon determining that the signature is invalid, extract by the observing device of the Module token from the Module message upon determining that the signature is valid, and perform by the ISDM device of at least one authorization test, whereby the Module is identified as authorized if each of the at least one authorization test is passed upon extracting of the Module token. 
     In some examples, the at least one authorization test includes determining whether the Module token includes a signature from a trusted ISDM Authority and the signature is for a valid time duration, wherein the Authority belongs to the ISDM system and is configured to manage CPV licensing and approval of CPVs, whereby the test is passed when the Module token is signed by the trusted Authority and the signature is for a valid time duration. 
     In some examples, the at least one authorization test includes determining by the ISDM device whether the Module public key corresponds to the Module private key by means of signature verification, and whether the Module private key has been revoked, whereby the test is passed when the Module public key matches the Module private key and the Module private key has not been revoked. 
     In some examples, the at least one authorization test includes verifying that a position of the CPV and telemetry of the CPV are compliant with flight data previously authorized by the Authority. In some examples, the ISDM device is one a Node device of the ISDM system and configured to verify Module authenticity, and a different ISDM Module. In some examples, the ISDM device is a different ISDM Module, and further comprises the step of establishing a two-way, trusted communication channel between the ISDM Module and the different ISDM Module. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may generating, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority, creating a self-signed Authority token signed by the private key, sending the Authority token to a plurality of ISDM Node devices configured to verify Module device authenticity and in communication with the Authority, generating, by each Node, a Node public/private key pair and a unique Node ID, sending to the Authority, by each Node, a token request including at least the Node public key and the Node private key, wherein the token request is signed under the Node private key, determining, by the Authority, whether the token request is approved, creating by the Authority a Node token for the approved Node, the Node token comprises the Node ID, the Node public key, the Authority public key, the Authority ID, and a range of time for which the token is valid, wherein the Node token is signed under the Authority private key upon approval of the token request, sending the Node token and Authority token to the Node, storing the Node token and Authority token to the Node, and marking the Authority token stored on the Node as trusted. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to generate, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority, create a self-signed Authority token signed by the private key, send the Authority token to a plurality of ISDM Node devices configured to verify Module device authenticity and in communication with the Authority, generate, by each Node, a Node public/private key pair and a unique Node ID, send to the Authority, by each Node, a token request including at least the Node public key and the Node private key, wherein the token request is signed under the Node private key, determine, by the Authority, whether the token request is approved, create by the Authority a Node token for the approved Node, the Node token comprises the Node ID, the Node public key, the Authority public key, the Authority ID, and a range of time for which the token is valid, wherein the Node token is signed under the Authority private key upon approval of the token request, send the Node token and Authority token to the Node, store the Node token and Authority token to the Node, and mark the Authority token stored on the Node as trusted. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: generate, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority, create a self-signed Authority token signed by the private key, send the Authority token to a plurality of ISDM Node devices configured to verify Module device authenticity and in communication with the Authority, generate, by each Node, a Node public/private key pair and a unique Node ID, send to the Authority, by each Node, a token request including at least the Node public key and the Node private key, wherein the token request is signed under the Node private key, determine, by the Authority, whether the token request is approved, create by the Authority a Node token for the approved Node, the Node token comprises the Node ID, the Node public key, the Authority public key, the Authority ID, and a range of time for which the token is valid, wherein the Node token is signed under the Authority private key upon approval of the token request, send the Node token and Authority token to the Node, store the Node token and Authority token to the Node, and mark the Authority token stored on the Node as trusted. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may generating, by the Module, a public/private key pair and a unique ID, sending, to an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, a registration request including the public key and unique ID, determining, by the Authority, if the registration request is approved, and registering the Module public key and the unique ID with the ISDM system upon determining that the registration request is approved. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to generate, by the Module, a public/private key pair and a unique ID, send, to an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, a registration request including the public key and unique ID, determine, by the Authority, if the registration request is approved, and registers the Module public key and the unique ID with the ISDM system upon determining that the registration request is approved. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: generate, by the Module, a public/private key pair and a unique ID, send, to an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, a registration request including the public key and unique ID, determine, by the Authority, if the registration request is approved, and registers the Module public key and the unique ID with the ISDM system upon determining that the registration request is approved. 
     Some examples of the method, apparatus, and non-transitory computer readable medium described above may further include registering the Module public key and unique ID comprises inserting the Module public key and unique ID into a database maintained by the Authority. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may registering, by an operator of the CPV, information with an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, wherein the information required is determined by the Authority, storing by the Authority of the information, and associating by the Authority of the information with the Module. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to register, by an operator of the CPV, the information with an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, wherein the information required is determined by the Authority, store by the Authority of the information, and associate by the Authority of the information with the Module. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: register, by an operator of the CPV, information with an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, wherein the information required is determined by the Authority, store by the Authority of the information, and associate by the Authority of the information with the Module. 
     In some examples, the information comprises an operator ID and a Module ID. In some examples, the information comprises flight information. In some examples, the associating comprises associating the information with a public key of the Module, wherein the public key is previously stored by the Authority. 
     Some examples of the method, apparatus, and non-transitory computer readable medium described above may further include mechanically coupling the Module to the associated CPV. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may broadcasting of a Module message by the Module, the Module message including a current time, and a Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receiving of the Module broadcast by a Node device of the ISDM system, the Node device configured to verify Module authenticity and having a Node private key, a Node public key, and a Node token signed by an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, determining, by the Node, whether the signature of the Module message is valid by using the Module public key, identifying the Module as unauthorized upon determining that the signature is invalid, extracting, by the Node, the Module ID from the Module message upon determining that the signature is valid, creating, by the Node, an Authority query message signed using the Node private key and including the Module ID and the Node token, sending, over a network, the Authority query message to the Authority, determining, by the Authority, whether the signature is valid and whether the Node token was signed by a trusted Authority, reporting by the Authority that the query is unauthorized upon determining that the signature is invalid or the Node token is not signed by the trusted Authority, sending to the Node by the Authority a reply including at least the Module ID and the Module public key, wherein the reply is signed under an Authority private key of the sending Authority upon determining that the signature is valid and the Node token is signed by the trusted Authority, verifying by the Node of the validity of the signature of the reply and verifying that the signing Authority is trusted upon receiving the reply, identifying the Module as authorized upon determining that the signature is valid and the signing Authority is trusted, and identifying the Module as unauthorized upon determining that the signature is invalid or the Authority is not trusted. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to broadcast of a Module message by the Module, the Module message including a current time, and a Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receive of the Module broadcast by a Node device of the ISDM system, the Node device configured to verify Module authenticity and having a Node private key, a Node public key, and a Node token signed by an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, determine, by the Node, whether the signature of the Module message is valid by using the Module public key, identify the Module as unauthorized upon determining that the signature is invalid, extract, by the Node, the Module ID from the Module message upon determining that the signature is valid, create, by the Node, an Authority query message signed using the Node private key and including the Module ID and the Node token, send, over a network, the Authority query message to the Authority, determine, by the Authority, whether the signature is valid and whether the Node token was signed by a trusted Authority, report by the Authority that the query is unauthorized upon determining that the signature is invalid or the Node token is not signed by the trusted Authority, send to the Node by the Authority a reply including at least the Module ID and the Module public key, wherein the reply is signed under an Authority private key of the sending Authority upon determining that the signature is valid and the Node token is signed by the trusted Authority, verify by the Node of the validity of the signature of the reply and verifying that the signing Authority is trusted upon receiving the reply, identify the Module as authorized upon determining that the signature is valid and the signing Authority is trusted, and identify the Module as unauthorized upon determining that the signature is invalid or the Authority is not trusted. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: broadcast of a Module message by the Module, the Module message including a current time, and a Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receive of the Module broadcast by a Node device of the ISDM system, the Node device configured to verify Module authenticity and having a Node private key, a Node public key, and a Node token signed by an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, determine, by the Node, whether the signature of the Module message is valid by using the Module public key, identify the Module as unauthorized upon determining that the signature is invalid, extract, by the Node, the Module ID from the Module message upon determining that the signature is valid, create, by the Node, an Authority query message signed using the Node private key and including the Module ID and the Node token, send, over a network, the Authority query message to the Authority, determine, by the Authority, whether the signature is valid and whether the Node token was signed by a trusted Authority, report by the Authority that the query is unauthorized upon determining that the signature is invalid or the Node token is not signed by the trusted Authority, send to the Node by the Authority a reply including at least the Module ID and the Module public key, wherein the reply is signed under an Authority private key of the sending Authority upon determining that the signature is valid and the Node token is signed by the trusted Authority, verify by the Node of the validity of the signature of the reply and verifying that the signing Authority is trusted upon receiving the reply, identify the Module as authorized upon determining that the signature is valid and the signing Authority is trusted, and identify the Module as unauthorized upon determining that the signature is invalid or the Authority is not trusted. 
     Some examples of the method, apparatus, and non-transitory computer readable medium described above may further include resending, over the network, the Authority query message to the Authority upon reporting by the Authority that the query is unauthorized. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may broadcasting of a Module message by the Module, the Module message including a current time, and a Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receiving of the message by an observing device, extracting, by the observing device, the Module ID, creating, by the observing device of an Authority query message including the Module ID, sending by the observing device of the query message to an Authority, wherein the Authority is configured to manage licensing and approval of CPVs, determining, by the Authority, whether the query is authorized, and identifying by the Authority of the Module CPV Authentication Component. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to broadcast of a Module message by the Module, the Module message including a current time, and a Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receive of the message by an observing device, extract, by the observing device, the Module ID, create, by the observing device of an Authority query message including the Module ID, send by the observing device of the query message to an Authority, wherein the Authority is configured to manage licensing and approval of CPVs, determine, by the Authority, whether the query is authorized, and identify by the Authority of the Module CPV Authentication Component. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: broadcast of a Module message by the Module, the Module message including a current time, and a Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receive the message by an observing device, extract, by the observing device, the Module ID, create, by the observing device of an Authority query message including the Module ID, send by the observing device of the query message to an Authority, wherein the Authority is configured to manage licensing and approval of CPVs, determine, by the Authority, whether the query is authorized, and identify by the Authority of the Module CPV Authentication Component. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may generating, by the Module, a public/private key pair and a unique ID, receiving, from a trusted Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, an Authority token, and storing, by the Module, the Authority token as trusted. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to generate, by the Module, a public/private key pair and a unique ID, receive, from a trusted Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, an Authority token, and store, by the Module, the Authority token as trusted. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: generate, by the Module, a public/private key pair and a unique ID, receive, from a trusted Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, an Authority token, and store, by the Module, the Authority token as trusted. 
     Some examples of the method, apparatus, and non-transitory computer readable medium described above may further include registering the Module public key and unique ID comprises inserting the Module public key and unique ID into a database maintained by the Authority. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may generating, by an operator of the CPV, a token request including CPV and operator identification information, sending the token request to an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, determining, based at least in part on the information, by the Authority if flight is authorized, sending by the Authority of a Module token to the operator upon authorization of flight, and storing of the Module token on the Module. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to generate, by an operator of the CPV, a token request including CPV and operator identification information, send the token request to an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, determine, based at least in part on the information, by the Authority if flight is authorized, send by the Authority of a Module token to the operator upon authorization of flight, and store of the Module token on the Module. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: generate, by an operator of the CPV, a token request including CPV and operator identification information, send the token request to an Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, determine, based at least in part on the information, by the Authority if flight is authorized, send by the Authority of a Module token to the operator upon authorization of flight, and store of the Module token on the Module. 
     In some examples, the information comprises an operator ID and a Module ID. In some examples, the information comprises flight information. In some examples, the associating comprises associating the information with a public key of the Module, wherein the public key is previously stored by the Authority. 
     Some examples of the method, apparatus, and non-transitory computer readable medium described above may further include mechanically coupling the Module to the associated CPV. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may broadcasting of a Module message by the Module, the Module message including a current time, and a current Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receiving of the message by an ISDM Node device configured to verify Module authenticity and having a private key and a Node token including a Node public key, generating, by the Node device, the new Module token including at least a portion of the current Module token, the new token signed by a private key of the Node device, sending, by the Node, a message to the Module, the message including the new Module token and the Node token, wherein the message is signed under the Node private key, verifying by the Module of the message signature upon receiving the message, rejecting of the message by the Module upon determining that the signature is invalid, extracting by the Module of the Node token, verifying that the Node token was signed by a trusted Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, and verifying that the Node has Authority for signing Module tokens upon determining that the signature is valid, rejecting the message upon determining that the Node token was not signed by a trusted Authority or that the Node does not have Authority for signing tokens, determining by the Module whether the Node public key corresponds to the Node private key upon determining that the Node token was signed by a trusted Authority and that the Node has Authority for signing tokens, rejecting of the message by the Module upon determining that the Node public key does not correspond to the Node private key, storing the Node public key as trusted and extracting the new Module token upon determining that the Node public key corresponds to the Node private key, verifying by the Module whether the new Module token was signed by the trusted Authority, rejecting the new Module token upon determining that the new Module token was not signed by one trusted Authority, and storing by the Module of the new Module token such that the new Module token is sent in future broadcasts upon determining that the new Module token was signed by the trusted Authority. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to broadcast of a Module message by the Module, the Module message including a current time, and a current Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receive of the message by an ISDM Node device configured to verify Module authenticity and having a private key and a Node token including a Node public key, generate, by the Node device, the new Module token including at least a portion of the current Module token, the new token signed by a private key of the Node device, send, by the Node, a message to the Module, the message including the new Module token and the Node token, wherein the message is signed under the Node private key, verify by the Module of the message signature upon receiving the message, reject of the message by the Module upon determining that the signature is invalid, extract by the Module of the Node token, verifying that the Node token was signed by a trusted Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, and verifying that the Node has Authority for signing Module tokens upon determining that the signature is valid, reject the message upon determining that the Node token was not signed by a trusted Authority or that the Node does not have Authority for signing tokens, determine by the Module whether the Node public key corresponds to the Node private key upon determining that the Node token was signed by a trusted Authority and that the Node has Authority for signing tokens, reject of the message by the Module upon determining that the Node public key does not correspond to the Node private key, store the Node public key as trusted and extracting the new Module token upon determining that the Node public key corresponds to the Node private key, verify by the Module whether the new Module token was signed by the trusted Authority, reject the new Module token upon determining that the new Module token was not signed by one trusted Authority, and store by the Module of the new Module token such that the new Module token is sent in future broadcasts upon determining that the new Module token was signed by the trusted Authority. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: broadcast of a Module message by the Module, the Module message including a current time, and a current Module token associated with the Module and including a public Module key and a Module ID, wherein the Module message is signed under a Module private key, receive of the message by an ISDM Node device configured to verify Module authenticity and having a private key and a Node token including a Node public key, generate, by the Node device, the new Module token including at least a portion of the current Module token, the new token signed by a private key of the Node device, send, by the Node, a message to the Module, the message including the new Module token and the Node token, wherein the message is signed under the Node private key, verify by the Module of the message signature upon receiving the message, reject of the message by the Module upon determining that the signature is invalid, extract by the Module of the Node token, verifying that the Node token was signed by a trusted Authority of the ISDM system, wherein the Authority is configured to manage licensing and approval of CPVs, and verifying that the Node has Authority for signing Module tokens upon determining that the signature is valid, reject the message upon determining that the Node token was not signed by a trusted Authority or that the Node does not have Authority for signing tokens, determine by the Module whether the Node public key corresponds to the Node private key upon determining that the Node token was signed by a trusted Authority and that the Node has Authority for signing tokens, reject of the message by the Module upon determining that the Node public key does not correspond to the Node private key, store the Node public key as trusted and extracting the new Module token upon determining that the Node public key corresponds to the Node private key, verify by the Module whether the new Module token was signed by the trusted Authority, reject the new Module token upon determining that the new Module token was not signed by one trusted Authority, and store by the Module of the new Module token such that the new Module token is sent in future broadcasts upon determining that the new Module token was signed by the trusted Authority. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may generating, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority, creating a self-signed Authority token by self-signing the public key, the unique ID, and a valid range of time, wherein the Authority token is signed by the private key, sending the Authority token to a plurality of ISDM receivers configured to verify ISDM Module authenticity, storing, by each receiver, the Authority token, and publishing of the Authority token by each receiver. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to generate, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority, create a self-signed Authority token by self-signing the public key, the unique ID, and a valid range of time, wherein the Authority token is signed by the private key, send the Authority token to a plurality of ISDM receivers configured to verify ISDM Module authenticity, store, by each receiver, the Authority token, and publish of the Authority token by each receiver. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: generate, by an ISDM Authority configured to manage licensing and approval of CPVs, a public/private key pair and a unique ID for the Authority, create a self-signed Authority token by self-signing the public key, the unique ID, and a valid range of time, wherein the Authority token is signed by the private key, send the Authority token to a plurality of ISDM receivers configured to verify ISDM Module authenticity, store, by each receiver, the Authority token, and publish of the Authority token by each receiver. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may providing a CPV, providing a Module device associated with the CPV and configured to be mechanically coupled to and in communication with the CPV, generating a public key, a private key, and a unique ID, and associating the public key, the private key, and the unique ID with the CPV and the Module device. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to provide a CPV, provide a Module device associated with the CPV and configured to be mechanically coupled to and in communication with the CPV, generate a public key, a private key, and a unique ID, and associate the public key, the private key, and the unique ID with the CPV and the Module device. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: provide a CPV, provide a Module device associated with the CPV and configured to be mechanically coupled to and in communication with the CPV, generate a public key, a private key, and a unique ID, and associate the public key, the private key, and the unique ID with the CPV and the Module device. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may purchasing of a CPV and Module by an operator, requesting registration of the CPV and the Module with an Authority of the ISDM system, the Authority configured to manage licensing and approval of CPVs, determining, by the Authority, if the registration is approved, returning an error message to the operator upon determining that the registration is not approved, registering of the CPV and the Module with the ISDM system upon determining that the registration is approved, returning to the Module by the Authority a CPV token upon registering, and storing, by the Module, the CPV token. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to purchase of a CPV and Module by an operator, request registration of the CPV and the Module with an Authority of the ISDM system, the Authority configured to manage licensing and approval of CPVs, determine, by the Authority, if the registration is approved, return an error message to the operator upon determining that the registration is not approved, register the CPV and the Module with the ISDM system upon determining that the registration is approved, return to the Module by the Authority a CPV token upon registering, and store, by the Module, the CPV token. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: purchase of a CPV and Module by an operator, request registration of the CPV and the Module with an Authority of the ISDM system, the Authority configured to manage licensing and approval of CPVs, determine, by the Authority, if the registration is approved, return an error message to the operator upon determining that the registration is not approved, register the CPV and the Module with the ISDM system upon determining that the registration is approved, return to the Module by the Authority a CPV token upon registering, and store, by the Module, the CPV token. 
     In some examples, the registration is requested using a software application running on a computing device. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may broadcasting, by the CPV, a message by the CPV, the message including at least a CPV token signed with a private key of the CPV, a current time, and current telemetry, receiving, by an observing device, the message, determining, by the observing device, if the message is fresh, valid and trusted, and verifying the identity of the CPV upon determining that the message is fresh, valid, and trusted. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to broadcast, by the CPV, a message by the CPV, the message including at least a CPV token signed with a private key of the CPV, a current time, and current telemetry, receive, by an observing device, the message, determine, by the observing device, if the message is fresh, valid and trusted, and verify the identity of the CPV upon determining that the message is fresh, valid, and trusted. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: broadcast, by the CPV, a message by the CPV, the message including at least a CPV token signed with a private key of the CPV, a current time, and current telemetry, receive, by an observing device, the message, determine, by the observing device, if the message is fresh, valid and trusted, and verify the identity of the CPV upon determining that the message is fresh, valid, and trusted. 
     A system for cyber-physical vehicle management is described. Embodiments of the system may an ISDM Module mechanically coupled to and in communication with an associated CPV, the ISDM Module configured to broadcast a beacon of identity, a plurality of ISDM Stations wherein each ISDM station is configured to support at least one of the group of CPV authentication, CPV authorization, and secure communication between ISDM Modules and other ISDM Stations, and a cloud computing system in communication with the plurality of ISDM stations and including at least one processor, at least one database, and data stored on the at least one database including Module registration and authorization data, whereby the ISDM system is configured to securely receive, send, store, and relay CPV registration and authorization information. 
     A method of producing an apparatus for cyber-physical vehicle management is described. The method may include providing an ISDM Module mechanically coupled to and in communication with an associated CPV, the ISDM Module configured to broadcast a beacon of identity, providing a plurality of ISDM Stations wherein each ISDM station is configured to support at least one of the group of CPV authentication, CPV authorization, and secure communication between ISDM Modules and other ISDM Stations, and providing a cloud computing system in communication with the plurality of ISDM stations and including at least one processor, at least one database, and data stored on the at least one database including Module registration and authorization data, whereby the ISDM system is configured to securely receive, send, store, and relay CPV registration and authorization information. 
     In some examples, the plurality of ISDM stations comprises at least one Authority device configured to manage licensing and approval of CPVs. In some examples, the plurality of ISDM stations comprises at least one Node device configured to verify Module authenticity. In some examples, the plurality of ISDM stations comprises at least one Gateway device configured to relay ISDM communications between two devices from the group of CPVs and ISDM stations. 
     A system for cyber-physical vehicle management is described. Embodiments of the system may an ISDM Module mechanically coupled to and in communication with the CPV, the ISDM Module configured to provide a beacon of identity and including a Global Positions System (GPS) receiver configured to receive Real-Time Kinematic (RTK) correctional data and perform RTK positioning calculations based on the received RTK correctional data, whereby the position of the CPV is determined in real-time, at least one ISDM Station, wherein each ISDM station is one of an ISDM Node, an ISDM Authority, and an ISDM Gateway, wherein each ISDM station has a known location, includes a GPS receiver configured to determine RTK correctional data from received GPS signals, is configured to support authentication, authorization, and secure communication between ISDM Modules and other ISDM Stations, configured to send RTK correctional data to the ISDM Module, and configured to receive RTK correctional data from one of an Evolved Packet Core (EPC) Network and an Internet Gateway, and at least one base station including a GPS receiver configured to determine RTK correctional data from received GPS signals and configured to send RTK correctional data to at least one of the ISDM Module, at least one ISDM station, the EPC Network, and the Internet Gateway. 
     A method of producing an apparatus for cyber-physical vehicle management is described. The method may include providing an ISDM Module mechanically coupled to and in communication with the CPV, the ISDM Module configured to provide a beacon of identity and including a GPS receiver configured to receive RTK correctional data and perform RTK positioning calculations based on the received RTK correctional data, whereby the position of the CPV is determined in real-time, at least one ISDM Station, wherein each ISDM station is one of an ISDM Node, an ISDM Authority, and an ISDM Gateway, wherein each ISDM station has a known location, includes a GPS receiver configured to determine RTK correctional data from received GPS signals, is configured to support authentication, authorization, and secure communication between ISDM Modules and other ISDM Stations, configured to send RTK correctional data to the ISDM Module, and configured to receive RTK correctional data from one of an EPC Network and an Internet Gateway, and at least one base station including a GPS receiver configured to determine RTK correctional data from received GPS signals and configured to send RTK correctional data to at least one of the ISDM Module, at least one ISDM station, the EPC Network, and the Internet Gateway. 
     In some examples, the at least one base station includes a wireless infrastructure tower. In some examples, the wireless infrastructure tower is configured to send RTK data directly to the ISDM Module using wireless broadband communication. 
     In some examples, the wireless infrastructure tower is configured to send RTK data indirectly to the ISDM Module through one of the EPC Network and an Internet Gateway to one ISDM Station, whereby the ISDM station transmits the RTK data to the ISDM Module. 
     In some examples, the Module is further configured to search for and identify base stations within range of transmission of RTK data. 
     A method for cyber-physical vehicle management is described. Embodiments of the method may receiving of at least one GPS signal by a base station including a GPS receiver, determining, from the GPS signal, RTK correctional data by the base station, sending, by the base station, the RTK correctional data to an ISDM base station via one of an EPC Network and an Internet Gateway, wherein the ISDM base station is within wireless communication range of the CPV, authenticating, by the ISDM base station, an identity of the CPV, sending, by the ISDM base station in response to authenticating the identity of the CPV, the RTK correctional data to an ISDM Module mechanically coupled to and in communication with the CPV, receiving of at least one GPS signal by a GPS receiver of the ISDM Module, and performing, by the ISDM Module, RTK positioning calculations based on the at least one GPS signal received by the ISDM Module and the received RTK correctional data, whereby the position of the CPV is determined in real-time. 
     An apparatus for cyber-physical vehicle management is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be operable to cause the processor to receive of at least one GPS signal by a base station including a GPS receiver, determine, from the GPS signal, RTK correctional data by the base station, send, by the base station, the RTK correctional data to an ISDM base station via one of an EPC Network and an Internet Gateway, wherein the ISDM base station is within wireless communication range of the CPV, authenticate, by the ISDM base station, an identity of the CPV, send, by the ISDM base station in response to authenticating the identity of the CPV, the RTK correctional data to an ISDM Module mechanically coupled to and in communication with the CPV, receive of at least one GPS signal by a GPS receiver of the ISDM Module, and perform, by the ISDM Module, RTK positioning calculations based on the at least one GPS signal received by the ISDM Module and the received RTK correctional data, whereby the position of the CPV is determined in real-time. 
     A non-transitory computer readable medium storing code for cyber-physical vehicle management is described. In some examples, the code comprises instructions executable by a processor to: receive of at least one GPS signal by a base station including a GPS receiver, determine, from the GPS signal, RTK correctional data by the base station, send, by the base station, the RTK correctional data to an ISDM base station via one of an EPC Network and an Internet Gateway, wherein the ISDM base station is within wireless communication range of the CPV, authenticate, by the ISDM base station, an identity of the CPV, send, by the ISDM base station in response to authenticating the identity of the CPV, the RTK correctional data to an ISDM Module mechanically coupled to and in communication with the CPV, receive of at least one GPS signal by a GPS receiver of the ISDM Module, and perform, by the ISDM Module, RTK positioning calculations based on the at least one GPS signal received by the ISDM Module and the received RTK correctional data, whereby the position of the CPV is determined in real-time. 
     Some of the functional units described in this specification have been labeled as Modules, or components, to more particularly emphasize their implementation independence. For example, a Module may be implemented as a hardware circuit comprising custom very large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A Module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like. 
     Modules may also be implemented in software for execution by various types of processors. An identified Module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified Module need not be physically located together but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the Module and achieve the stated purpose for the Module. 
     Indeed, a Module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within Modules and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. 
     While the invention herein disclosed has been described by means of specific embodiments, examples and applications thereof, numerous modifications and variations could be made thereto by those skilled in the art without departing from the scope of the invention set forth in the claims.