Method for using certificate-based security in drone identity and broadcast

Abstract

Various embodiments enable broadcast communication security. Various embodiments enable authentication of broadcast communications. Various embodiments can enable asymmetric authentication and integrity protection of small size messages such as one or more signed messages with a total length of 250 bytes or less. Various embodiments can support encryption signature of beacon type messages using certificates. Various embodiments can include generating a beacon type message, encrypting signing the beacon type message using at least in part a certificate to generate a signed beacon message, and issuing the signed beacon type message in one or more broadcast transmissions in combination with or independent of certificate information used to verify the signed beacon message.

Description

[0001] Related applications

[0002] This application claims the benefit of priority to U.S. Provisional Application No. 63 / 016,780, filed April 28, 2020, entitled "Methods Of Using Certificate-Based Security With Drone Identity And Broadcasting," the entire contents of which are incorporated herein by reference for all purposes. Background Technology

[0003] Improvements in modern communication systems have spurred the emergence of many different types of devices that can benefit from secure communication, such as robotic vehicles (e.g., unmanned aerial systems (UAS), unmanned aerial vehicles (UAVs), autonomous vehicles, etc.) and Internet of Things (IoT) devices. While many devices can benefit from secure communication, constraints associated with certain devices, such as message size constraints, communication channel bandwidth constraints, and connection unreliability, have previously hindered the use of certificate-based security in the communication of such constrained devices. Summary of the Invention

[0004] Each aspect implements broadcast communication security. Each aspect implements broadcast communication authentication. Each aspect can implement asymmetric cryptographic authentication and integrity protection for small-sized messages, such as one or more signed messages with a total length of 250 bytes or less. Each aspect can support the use of certificates to cryptographically sign beacon-type messages. Each aspect can include methods executed by the processor of a device, such as a wireless device (e.g., unmanned aerial system (UAS), Internet of Things (IoT) device, broadcast receiver, user equipment (UE), autonomous or semi-autonomous vehicle, robot, roadside infrastructure device, etc.). Each aspect can include generating beacon-type messages, cryptographically signing beacon-type messages at least partially using certificates to generate signed beacon messages, and transmitting the signed beacon-type messages in one or more broadcast transmissions from the device. Each aspect can include generating beacon-type messages, cryptographically signing beacon-type messages at least partially using certificates to generate signed beacon messages, and transmitting the signed beacon-type messages in one or more broadcast transmissions from the device. In some respects, signed beacon-type messages can be sent in one or more broadcast transmissions from the device, either in conjunction with or independently of certificate information used to verify signed beacon messages.

[0005] In some aspects, signing the beacon type message using, at least in part, a private key of the certificate to generate the signed beacon type message can include generating a message payload, generating a digital signature using, at least in part, the certificate and the private key of the device, the private key corresponding to a public key of the device associated with the certificate, generating a certificate identification hash of the certificate, and embedding the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message.

[0006] In some aspects, the message payload can include a device message, and generating the digital signature using, at least in part, the private key of the certificate can include determining a signature timestamp, generating a hash of the certificate, combining the device message, the signature timestamp, and the hash of the certificate to form a header and a payload to be authenticated, and generating the digital signature using, at least in part, the payload to be authenticated and the private key. Generating the certificate identification hash of the certificate can include selecting a subset or all of the hash of the certificate as the certificate identification hash, and embedding the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message can include embedding the message payload, the signature timestamp, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message. In some aspects, the signature timestamp can be included in a header of the signed beacon type message in addition to or instead of in a payload of the signed beacon type message. In some aspects, the byte portion can be a minimum or maximum valid eight, sixteen, or twenty-four bytes of the certificate hash. In some aspects, the byte portion can be a full hash of the certificate or less than a full hash of the certificate.

[0007] In some aspects, generating the message payload can include determining a signature timestamp, determining a message set of one or more device messages, generating a hash of a combination of the message set and the signature timestamp, and selecting a first byte portion of the hash of the combination of the message set and the signature timestamp as the message payload, generating the digital signature using, at least in part, the certificate and the private key can include generating the digital signature using, at least in part, the first byte portion, the certificate, and the private key, generating the certificate identification hash of the certificate can include generating a hash of the certificate and selecting a second byte portion of the hash of the certificate as the certificate identification hash, and embedding the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message can include embedding the message payload, the signature timestamp, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message.

[0008] In some aspects, the first byte portion can be a maximum or minimum valid twelve, sixteen, or twenty-four bytes of a hash of a combination of the message set and the signature timestamp, and the second byte portion can be an appended hash of the certificate or a subset thereof. In some aspects, the first byte portion can be a full or partial output of a hash of a combination of the message or message set and the signature timestamp, and the second byte portion can be a subset or full hash of the certificate.

[0009] In some aspects, the signed beacon type message can also include the certificate or the certificate can be included in a different signed beacon type message. Various aspects can also include generating a second beacon type message including the certificate and transmitting the second beacon type message in one or more additional broadcast transmissions from the device. In some aspects, the beacon type message can be a Bluetooth beacon frame. In some aspects, the Bluetooth beacon frame can be a small Bluetooth 4 beacon frame or a Bluetooth 5 extended advertisement. In some aspects, the beacon type message can be a Wi-Fi beacon frame. In some aspects, the Wi-Fi beacon frame can be a Wi-Fi Neighbor Awareness Networking (NAN) service discovery frame.

[0010] Various aspects can also include generating an unsigned beacon type message pointing to the signed beacon type message, or a signed or unsigned certificate broadcast beacon or service advertisement message, and transmitting the unsigned beacon type message in one or more broadcast transmissions on a channel different from the channel of the one or more broadcast transmissions of the signed beacon type message. In some aspects, the signed beacon type message can be a Bluetooth 5 extended advertisement frame or a Wi-Fi NAN service discovery frame.

[0011] In some aspects, the message payload, digital signature, and certificate identification hash can have a combined size of 109, 125, 250, or 255 bytes or less. In some aspects, the certificate broadcast beacon or advertisement can have a combined size of 109, 125, 250, or 255 bytes or less and can be transmitted by a signer, proxy, or intermediary. In some aspects, a subset of the message payload can have a size of 25 bytes transmitted in a separate frame.

[0012] In some aspects, the device message can be an ASTM message. In some aspects, the device can be a UAS and the device message can be an ASTM F3411-19 message. In some aspects, the signed beacon type message can be an ASTM F3411-19 authentication message, an IEEE 1609.2 signed message contained within an ASTM F3411-10 compatible frame, or other unique protocol message that adapts to similar small message size constraints. In some aspects, the bit portion of the certificate can correspond to a serial number, a universally unique identifier (UUID), or a session identifier (session ID) assigned to the UAS or its operator. In some aspects, the embedded certificate identifier can be an encrypted binding of both the UAS identifier and the operator identifier, such as a full or partial hash of a secret operator identification key along with the UAS identifier and a counter or other non-repeating or unique parameter, or the embedded certificate identifier can be a keyed message authentication code using the same input. In some aspects, the UUID or certificate identifier can not be embedded in the certificate, but can be the first or last 64, 96, 100, or 128 bits of the certificate / hash. In some aspects, the certificate can include embedded permission bits that indicate the UAS or its operator’s vehicle type, operator type, role, and / or other permissions. In some aspects, the signed beacon type message can include a message consistency indication. In some aspects, the device message can be an automatic dependent surveillance-broadcast (ADS-B) message that is to be broadcast over a small beacon or service advertisement frame.

[0013] In some aspects, the certificate can be an implicit format certificate that does not include a full version of the public key. In some aspects, the certificate can include a public key reconstruction value configured to allow reconstruction of the public key. In various aspects, issuing the signed beacon type message in one or more broadcast transmissions from the device can include transmitting the signed beacon type message in multiple broadcast pages or broadcast frames from the device. In some aspects, the multiple broadcast pages or broadcast frames from the device can be five broadcast pages or broadcast frames from the device.

[0014] Various aspects can include receiving a signed beacon type message from a device, cryptographically signing the signed beacon type message using, at least in part, a certificate private key of the device, determining whether the signed beacon type message is valid based, at least in part, on the certificate, processing the signed beacon type message in response to determining that the signed beacon type message is valid, and discarding the signed beacon type message in response to determining that the signed beacon type message is not valid. In some aspects, the signed beacon type message can include a certificate identification hash of the certificate. Various aspects can also include determining an identity of the certificate based, at least in part, on the certificate identification hash of the certificate, and retrieving the certificate based on the determined one or more identities associated with the certificate.

[0015] In some aspects, retrieving the certificate based on the determined identity of the certificate can include retrieving the certificate from a certificate issuing server remote from the broadcast receiver device. In some aspects, retrieving the certificate based on the determined identity of the certificate can include retrieving the certificate from a memory of the broadcast receiver device. In some aspects, retrieving the certificate based on the determined identity of the certificate can include retrieving the certificate from a store of previous transmissions made from the broadcast issuer in the broadcast receiver device. In some aspects, the certificate can be received from the device in another beacon type message.

[0016] In some aspects, the broadcast receiver device can be a law enforcement broadcast receiver device. In some aspects, processing the signed beacon type message in response to determining that the signed beacon type message is valid can include determining, at least in part using the signed beacon type message, a drone identity, an operator identity of the drone, or a combination of the drone identity and the operator identity. In some aspects, processing the signed beacon type message in response to determining that the signed beacon type message is valid can include determining, at least in part using the signed beacon type message, a drone identity or an operator identity of the drone. In some aspects, the broadcast identifier can be contained within the signed certificate and the identifier can be a cryptographic output of a key hash, message authentication code algorithm, or public key signature algorithm. In some aspects, the broadcast identifier can be contained within the signed certificate and the identifier can be a cryptographic output of a key hash, message authentication code algorithm, or public key signature algorithm using UAS and / or UAS operator identification information as input. In some aspects, the key hash, message authentication code algorithm, or public key signature algorithm can be repeatedly invoked with a unique counter input or non-repeating random number, and each output can constitute another identifier of a short-lived broadcast ID certificate associated with the drone and the drone operator. In some aspects, the key hash, message authentication code algorithm, or public key signature algorithm can be repeatedly invoked with a unique counter input and / or non-repeating random number, and each output can constitute another identifier of a short-lived (session ID) broadcast ID certificate associated with the UAS and the UAS operator. In various aspects, the message payload can be an automatic dependent surveillance-broadcast (ADS-B) message to be broadcast on a small beacon or service advertisement frame.

[0017] Further aspects include a wireless device having a processor configured with processor-executable instructions to perform operations of any of the methods summarized above. Various aspects include a wireless device having components for performing the functionality of any of the methods summarized above. Various aspects include a non-transitory processor-readable medium having stored thereon processor-executable instructions configured to cause a processor of a wireless device to perform operations of any of the methods summarized above. BRIEF DESCRIPTION OF DRAWINGS

[0018] The accompanying drawings, which are incorporated herein and constitute a part of the specification, illustrate example embodiments of the claims and, together with the general description given above and the detailed description given below, serve to explain features of the claims.

[0019] Figure 1 is a system block diagram illustrating an example communication system suitable for implementing any of the various embodiments.

[0020] Figure 2A is a component block diagram illustrating components of an example computing and wireless modem system suitable for implementing any of the various embodiments.

[0021] Figure 2B is a component block diagram illustrating components of an unmanned aerial system (UAS) in accordance with various embodiments.

[0022] Figure 3 is a component block diagram illustrating a software architecture including a radio protocol stack for the user and control planes in wireless communication suitable for implementing any of the various embodiments.

[0023] Figure 4A shows an example broadcast of a beacon type message.

[0024] Figure 4B shows an example of an unpaired beacon or service discovery broadcast frame in addition to one-to-one transmission of security messages after pairing of two devices.

[0025] Figure 5 shows various aspects of an ASTM F3411-19 message.

[0026] Figure 6A is a process flow diagram illustrating a method for providing broadcast communication security in accordance with various embodiments.

[0027] Figure 6B is a process flow diagram illustrating a method for providing broadcast communication security in accordance with various embodiments.

[0028] Figure 6C is a process flow diagram illustrating a method for providing broadcast communication security in accordance with various embodiments.

[0029] Figure 7A is a block diagram illustrating broadcast transmission of beacon type messages according to various embodiments.

[0030] Figure 7B is a block diagram illustrating broadcast transmission of beacon type messages according to various embodiments.

[0031] Figure 7C is a block diagram illustrating broadcast transmission of beacon type messages according to various embodiments.

[0032] Figure 8 is a block diagram illustrating beacon type messages according to various embodiments.

[0033] Figure 9 is a process flow diagram illustrating a method for providing broadcast communication security according to various embodiments.

[0034] Figure 10 is a signature profile according to various embodiments.

[0035] Figure 11 is a process flow diagram illustrating a method for providing broadcast communication security according to various embodiments.

[0036] Figure 12A is a block diagram illustrating beacon type messages according to various embodiments.

[0037] Figure 12B is a block diagram illustrating beacon type messages and their encoder values and encoding sizes according to various embodiments.

[0038] Figure 12C illustrates elements of signature data for use in beacon type messages according to various embodiments.

[0039] Figure 13 is a process flow diagram illustrating a method for providing broadcast communication security according to various embodiments.

[0040] Figure 14 is a block diagram illustrating beacon type messages, message sets, and message packets according to various embodiments.

[0041] Figure 15 is a process flow diagram illustrating a method for authenticating broadcast communications according to various embodiments.

[0042] Figure 16 is a component block diagram of an IoT device suitable for use according to various embodiments of the present disclosure.

[0043] Figure 17 is a component diagram of an example server suitable for use with various embodiments.

[0044] Figure 18 is a component block diagram of a wireless device suitable for use with various embodiments. DETAILED DESCRIPTION

[0045] Various embodiments will be described in detail with reference to the drawings. Wherever possible, the same or like reference numerals will be used throughout the drawings to refer to same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the claims.

[0046] Various embodiments include systems, methods, and devices that enable broadcast communication security. Various embodiments enable authentication of broadcast communications. Various embodiments can enable asymmetric encryption authentication and integrity protection for small size messages, such as messages of 125 bytes or less in length. Various embodiments can use certificates to support encryption signature of beacon type messages. As a particular example, various embodiments can use implicit format certificates to support encryption signature of beacon type messages (e.g., Bluetooth 4 frames, Bluetooth 5 extended advertising frames, Wi-Fi Neighbor Awareness Networking (NAN) service frames, etc.). Various embodiments can use implicit format certificates to enable encryption signature of beacon type messages such that the length of the encryption overhead of the signed beacon type messages does not exceed 109 or 125 bytes. Various embodiments can enable signed beacon type messages, such as signed beacon type messages of 125 bytes or less in length, to be authenticated without any pairing operations between a device broadcasting the signed beacon type messages (e.g., an unmanned aerial system (UAS), an Internet of Things (IoT) device, a vehicle, a robot, etc.) and a broadcast receiver device (e.g., a user equipment (UE), a law enforcement device, etc.) receiving the broadcasted signed beacon type messages. Various embodiments can enable a device (e.g., a UAS, an IoT device, a vehicle, a robot, etc.) to be identified by its certificate, its embedded certificate ID, or a full or partial hash output of its certificate. As a particular example, various embodiments can enable a UAS to be identified by a certificate associated with a signed ASTM F3411-19 certification message broadcast by the device using Bluetooth or Wi-Fi beacon frames.

[0047] The term "wireless device" is used herein to refer to any one or all of cellular telephones, smart phones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, ultrabooks, palmtop computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless router devices, wireless appliances, medical devices and equipment, biometric sensors / devices, wearable devices (including smart watches, smart clothing, smart glasses, smart wrist bands, smart jewelry (e.g., smart rings, smart bracelets, etc.), entertainment devices (e.g., wireless game controllers, music and video players, satellite radios, etc.), Internet of Things (IoT) devices that support wireless networking (including smart meters / sensors, industrial manufacturing equipment, home or commercial appliances large and small, etc.), wireless communication elements in autonomous and semi-autonomous vehicles, wireless devices fixed in or attached to various mobile platforms, global positioning system devices, and any similar electronic device that includes a memory, a wireless communication component, and a programmable processor.

[0048] The term "IoT device" is used herein to refer to any one of a variety of devices that include a processor and a transceiver for communicating with other devices or networks. For ease of description, examples of IoT devices are described as communicating via radio frequency (RF) wireless communication links, but an IoT device can communicate with another device (or user) that is a participant in a communication network such as the Internet of Things via a wired or wireless communication link. Such communication can include communication with another wireless device, a base station (including cellular communication network base stations and IoT base stations), an access point (including IoT access points), or other wireless devices.

[0049] Various embodiments can be implemented within any device, system, or network that is capable of transmitting and receiving RF signals according to any of the Institute of Electrical and Electronics Engineers (IEEE) 16.11 standards, any of the IEEE 802.11 standards, standard (e.g., Bluetooth 4, Bluetooth 5, etc.), code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), Global System for Mobile Communications (GSM), GSM / General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Terrestrial Trunked Radio (TETRA), Wideband-CDMA (WCDMA), Evolution Data Optimized (EV-DO), 1xEV-DO, EV-DO Rev A, EV-DO Rev B, High Speed Packet Access (HSPA), High Speed Downlink Packet Access (HSDPA), High Speed Uplink Packet Access (HSUPA), Evolved High Speed Packet Access (HSPA+), Long Term Evolution (LTE), AMPS, or other known signals that are used to communicate within a wireless, cellular, or Internet of Things (IoT) network, such as IEEE 802.15.4 protocol (e.g., Thread, ZigBee, and Z-Wave), 6L0WPAN, Bluetooth Low Energy (BLE), LTE Machine Type Communications (LTE MTC), Narrow Band LTE (NB-LTE), Cellular IoT (CIoT), Narrow Band IoT (NB-IoT), BT Smart, Wi-Fi (e.g., Wi-Fi NAN, etc.), LTE-U, LTE-Direct, MuLTEfire, and relatively extended range wide-area physical layer interfaces (PHYs) such as Random Phase Multiple Access (RPMA), Ultra Narrow Band (UNB), Low Power Long Range (LoRa), Low Power Wide Area Network (LoRaWAN), Weightless, or systems that leverage 3G, 4G or 5G, cellular V2X, or further implementations thereof.

[0050] The term "system on a chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip that contains multiple resources and / or processors integrated on a single substrate. A single SOC can contain circuitry for digital, analog, mixed-signal, and radio-frequency functions. A single SOC can also include any number of general-purpose and / or special-purpose processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, Flash, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). An SOC can also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices.

[0051] The term "system-in-a-package" (SIP) is used herein to refer to a single module or package that contains multiple resources, compute units, cores, and / or processors on two or more IC chips, substrates, or SOCs. For example, a SIP can include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP can include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP can also include multiple independent SOCs coupled together and packaged in close proximity, such as on a single motherboard or in a single IoT device, via high-speed communication circuitry. The proximity of the SOCs facilitates high-speed communication as well as sharing of memory and resources.

[0052] The term "multi-core processor" is used herein to refer to a single integrated circuit (IC) chip or chip package that contains two or more independent processing cores (e.g., central processing unit (CPU) cores, Internet protocol (IP) cores, graphics processor unit (GPU) cores, etc.) that are configured to read and execute program instructions. An SOC can include multiple multi-core processors, and each processor in an SOC can be referred to as a core. The term "multi-processor" is used herein to refer to a system or device that includes two or more processing units that are configured to read and execute program instructions.

[0053] The term "server" is used herein to describe various embodiments to refer to any computing device capable of functioning as a server, such as a main exchange server, a web server, a mail server, a document server, a content server, or any other type of server. A server can be a dedicated computing device or a computing device that includes a server module (e.g., a server application) that is running an application that can cause the computing device to operate as a server. The server module (e.g., server application) can be a full-featured server module or a light or secondary server module (e.g., light or secondary server application) that is configured to provide synchronization services between a dynamic database on a sink device. The light or secondary server can be a scaled down version of the server type functionality that can be implemented on the sink device, thereby enabling it to function as an Internet server (e.g., an enterprise email server) only to the extent necessary to provide the functionality described herein.

[0054] As used herein, the terms "robotic vehicle" and "drone" refer to one of various types of vehicles that include an on-board computing device configured to provide some autonomous or semi-autonomous capabilities. Examples of robotic vehicles include, but are not limited to: aerial vehicles, such as unmanned aerial vehicles (UAVs) or unmanned aerial systems (UASs); ground-based vehicles (e.g., self-driving or semi-self-driving cars, vacuum robots, etc.); water-based vehicles (i.e., vehicles configured to operate on the surface of or underwater); space-based vehicles (e.g., spacecraft or space probes); and / or some combination thereof. In some embodiments, a robotic vehicle can be manned. In other embodiments, a robotic vehicle can be unmanned. In embodiments where a robotic vehicle is autonomous, the robotic vehicle can include an on-board computing device configured to maneuver and / or navigate the robotic vehicle without remote operational instructions (i.e., autonomously), such as from a human operator (e.g., via a remote computing device). In embodiments where a robotic vehicle is semi-autonomous, the robotic vehicle can include an on-board computing device configured to receive some information or instructions, such as from a human operator (e.g., via a remote computing device), and autonomously maneuver and / or navigate the robotic vehicle in accordance with the received information or instructions. In some implementations, a robotic vehicle can be an aerial vehicle (unmanned or manned), which can be a rotorcraft or a winged aircraft. For example, a rotorcraft (also referred to as a multicopter or multicopter drone) can include multiple propulsion units (e.g., rotors / propellers) that provide propulsion and / or lift for the robotic vehicle. Specific non-limiting examples of rotorcrafts include tri-copters (three rotors), quad-copters (four rotors), hexa-copters (six rotors), and octo-copters (eight rotors). However, a rotorcraft can include any number of rotors.

[0055] Asymmetric authentication or signing, sometimes also referred to as public-key cryptography, can enable secure communication between parties without requiring a shared key between the parties as with symmetric cryptography. Since in asymmetric cryptography, parties do not need to share a secret, the same key, asymmetric cryptographic signatures reduce the problems and risks associated with sharing a key as in symmetric signatures and authentication.

[0056] Asymmetric cryptography relies on a key pair of a public key and a corresponding private key. The public key is freely available, while the private key is kept secret and is not shared during communication. Any message encrypted by a public key can only be decrypted using the private key corresponding to the public key, and any message encrypted or signed by a private key can only be decrypted or verified using the public key corresponding to the private key.

[0057] Asymmetric encryption systems can use certificates, often referred to as digital certificates, public key certificates, authorization certificates, or identity certificates, to verify ownership of a public key, to identify the issuer of the certificate, and / or to verify the issuer of the certificate and / or public key. A certificate can be a package of information that identifies a public key owner or a trusted entity associated with the certificate that is authorized to perform an action or communicate a particular message. A public key of the public key owner can be embedded into the certificate. A certificate that includes a public key can be referred to as an explicit format certificate. Rather than a public key itself, a public key reconstruction value that is configured to allow reconstruction (or generation) of the public key can be included in the certificate. A certificate that includes a public key reconstruction value (and does not include a full version of the public key itself) can be referred to as an implicit format certificate. A device that receives an implicit format certificate can use the public key reconstruction value within the certificate to reconstruct (or generate) the public key.

[0058] A certificate can be issued by a certificate authority (CA). A certificate can be signed by a private key of the CA and given an associated public key or public key reconstruction value that associates the public key with the CA signature. A recipient of the certificate can use the public key of the CA or the reconstruction value of the certificate to verify the signed message and verify the associated signed certificate.

[0059] While certificates can enable secure communications, typical certificates such as X.509 certificates that are used today throughout a communications network such as the Internet often range in size between 200-800 bytes and thus are not suitable for use in securing small size messages, such as messages that are 125 bytes or less in length. As a specific example, typical certificates such as X.509 certificates are not suitable for UAS broadcast ID messages defined by the American Society for Testing and Materials (ASTM) Standard F3411-19 “Standard Specification for Remote ID and Tracking” (referred to herein as “ASTM F3411-19”). Use of X.509 or similarly sized certificates requires sending the signed message to a networked authenticator for verification and no authentication of received broadcasts can be performed if no network connection is available. In ASTM F3411-19, no message structure included in the ASTM F3411-19 authentication messages provides sufficient space to fit a 200-800 byte certificate. Further, common signature formats such as PKCS7 (Cryptographic Message Syntax), additional certificate(s), and associated encoding do not conform to the ASTM F3411-19 authentication message payload or size limits.

[0060] Additionally, typical certificates, such as X.509 certificates, require retrieval of certificates or operation on certificates from messages relayed via a network-reachable directory service. In connection with a lack of connectivity to a network-reachable directory service, such as a lack of a wireless access network (RAN) connection, a lack of availability to Wi-Fi hotspots, etc., typical certificate authentication mechanisms do not support retrieval of certificates or invocation of external signature verification, and thus are unable to provide trust in authenticity and integrity of messages. As a particular example, typical certificates, such as X.509 certificates, would require a broadcast receiver to still have to retrieve a UAS certificate via a network-reachable directory service or request such a service to validate a signed message. If connectivity is lacking, the broadcast receiver is unable to retrieve the certificate and thus unable to trust authenticity and integrity of the UAS broadcast ID or other message types.

[0061] Various embodiments can provide asymmetric authentication methods and systems that overcome the limitations of typical certificates, such as X.509 certificates. Various embodiments can support certificate-based signing of small size messages, such as messages having a length of 125 bytes or less. As a particular example, various embodiments can implement certificate-based signing of ASTM F3411-19 authentication messages. As other examples, various embodiments can implement certificate-based signing of messages emitted from IoT devices, robots, vehicles, distributed sensors, etc. Various embodiments can leverage IEEE 1609.2 certificate format and signature scheme aspects to cryptographically sign beacon type messages, particularly small size beacon type messages, such as beacon type messages having a length of 125 bytes or less, that are internally or externally authenticated to authentication messages.

[0062] Various embodiments are discussed herein with reference to particular devices, message types, cryptography standards, and / or communication technologies, such as UAS, ASTM F3411-19 messages, IEEE 1609.2, and / or Bluetooth 4, Bluetooth 5, and Wi-Fi NAN. These discussions of particular devices, message types, cryptography standards, and / or communication technologies are used merely as examples to better illustrate aspects of various embodiments. Particular devices, message types, cryptography standards, and / or communication technologies, such as UAS, ASTM F3411-19 messages, IEEE 1609.2, and / or Bluetooth 4, Bluetooth 5, and Wi-Fi NAN, can be replaced by other devices, other message types, other cryptography standards, and / or other communication technologies without departing from the scope of various embodiments. As some examples only, IoT devices, robots, vehicles, roadside infrastructure devices, etc., and other communication technologies, such as Zigbee, LTE MTC, Bluetooth LE, etc., can be substituted in the various UAS and ASTM F3411-19 examples discussed.

[0063] Small Unmanned Aircraft Systems (UAS) or "drones" have become very popular in industrial and hobbyist applications. As a result, millions of drones are expected to be flown in the airspace of most countries around the world. In major industrialized countries, millions of small UAS can pose a serious problem to public safety, security, and privacy. UAS or drones can pose a threat to people and can threaten personal privacy when flying over private property. Equally pressing is the risk that UAS can pose to manned aircraft, especially low-flying helicopters and aircraft near airports. There have been several incidents of drones entering airport airspace resulting in disruption of commercial air traffic and economic disruption related to airport closures.

[0064] Law enforcement agencies have few tools to identify and track UAS and enforce emerging laws and regulations covering UAS. To address this problem, multiple Unmanned Traffic Management (UTM) concepts are in development. These include proposals and regulations by NASA / FAA and the creation of the Global UTM Association (GUTMA) to develop concepts for identification, tracking, and flight control of UAS.

[0065] As an example of such efforts, the UAS ID Aviation Rulemaking Committee (ARC) began making recommendations to the Federal Aviation Administration (FAA) on drone identity and tracking. The ARC report (released September 2017) states: "The transmission and reception of the required UAS information does not rely on a network for direct broadcast" and "The ARC recommends that the FAA adopt industry standards for data transmission that can need to be created to ensure that UA equipment and public safety receivers are interoperable. This would also help alleviate concerns about proprietary technology licensing and vendor exclusivity."

[0066] The U.S. National Aeronautics and Space Administration (NASA) published a Notice of Proposed Rulemaking (NPRM) on December 31, 2019 at https: / / www.govinfo.gov / content / pkg / FR-2019-12-31 / pdf / 2019-28100.pdf. This document proposes policies for "standard" remote identification of UAS, involving support for networked identification, "limited" remote identification relying on local beacons without network support, static identities (e.g., UAS serial numbers and "private" identities or identifiers (e.g., UUID / Sessionld)). The document addresses the use of "broadcast technology compatible with personal wireless devices. The FAA envisions that remote identification broadcast devices will use a spectrum similar to that used by Wi-Fi and Bluetooth devices for broadcast." The "when" requirements for standard vs broadcast (or both) identification are still to be resolved, but both are required and must be secure.

[0067] The NPRM provides a view of the requirements that can be imposed on UAS. “[T]he FAA is proposing to require all UAS equipped with remote identification to incorporate network security protections for the transmission and broadcast of information elements where appropriate. Network security protections are necessary to defend against network threats that can have an adverse effect on the authenticity or integrity of remote identification information transmitted to a remote ID USS by a UAS or broadcast from an unmanned aircraft.”

[0068] ASTM followed the ARC recommendations and established F38.02 Subcommittee, which published F3411-19 in February 2020. This document identifies three broadcast solutions using Bluetooth 4 beacon frames, Bluetooth 5 beacons, and WiFi Neighbor Awareness Networking (NAN). Bluetooth 4 beacon frames (“legacy advertising frames”) will have 25 bytes available for identification and authentication information between the beacon counter and the Cyclic Redundancy Check (CRC). Bluetooth 5 beacons with extended advertising will point to a 255-byte auxiliary frame on a non-beacon channel (called extended advertising). WiFi Neighbor Awareness Networking (NAN) will provide a management frame [Type 0, Subtype 13 “Action”] defined in 802.11-2016 Part 11, which provides a NAN Service Discovery frame with a length up to 255 bytes.

[0069] ASTM F3411-19 includes the following message elements: a Basic ID message (Type 0x0) that will be used for drone identification (e.g., serial number, UUID, etc.), which is limited to 25 bytes; a Position / Vector message (Type 0x1) that provides the drone’s position, velocity, direction, and altitude, which is also limited to 25 bytes; an Authentication message (Type 0x2) that includes a set of authentication messages up to 125 bytes (5 “pages”) to accommodate legacy beacons (BT4); a Self-ID message (Type 0x3) that can be short text describing the drone’s current action and is limited to 25 bytes; a System message (Type 0x4) that identifies the operator’s position and / or flight area and is limited to 25 bytes; an Operator ID message (Type 0x5) that includes the operator ID issued by the regulatory authority and is limited to 25 bytes; and a Message Pack (Type 0xF) that is a collection of n messages issued in one frame that must fit within 250 bytes, including the header, but only for Bluetooth 5 and WiFi technologies.

[0070] ASTM F3411-19 specifies three types of identities: UAS serial number; a'session ID' (UUID), which is a short-lived identifier; and an operator identifier issued by the CAA. The problem is that these identities are useless unless the identity can be looked up and / or authenticated in a backend system, or the identity is "self-authenticated" using a locally known digital certificate. F3411-19 does not explain how to have a self-authenticated identity, and mandates network connectivity to digitally verify received broadcast messages. Furthermore, authentication typically involves the use of digital certificates that can or can not be retrievable or usable over a communication network suitable for use with UASs.

[0071] Conventional authentication messages can be hindered by the Bluetooth 4 beacon size constraint that limits each page to 25 bytes for a total message size of 125 bytes. It can not be feasible to provide both authentication and drone ID (e.g., authTypes UAS ID signature) or operator ID (e.g., operator ID signature) within this limited message size using conventional authentication methods. Furthermore, a message set (i.e., authTypes "message set") can only be used in BT5-extended or WiFi, which allow 250 byte messages. In addition to authentication messages, there is no specified set of security capabilities (e.g., anti-replay, anti-spoofing, privacy) specified in F3411. Furthermore, there is no specification of identities and authentication relationships.

[0072] A suitable solution to meet the need for communication authentication and identity messages in a UAS architecture should be able to meet multiple goals. The solution should enable broadcast receivers to trust the authenticity and integrity of broadcasts when disconnected from IP / cellular service while minimizing cryptographic security overhead to fit within the frame size and field constraints of Bluetooth and Wi-Fi beacons defined in ASTM 3411-19. The solution should support secure broadcasts that protect privacy, where UAS Service Supplier (USS) identity information is not linkable to the operator and is only accessible by authorized parties such as regulatory agencies and law enforcement. The solution should support both disconnected and networked, including when both the UAS and receiver are connected to the network, both the UAS and receiver are disconnected from the network, the UAS is connected to the network while the receiver is disconnected from the network, and the UAS is disconnected from the network while the receiver is connected to the network.

[0073] The solution should support, but not limit, the USS / UTM network authentication methods so that the USS operators can use a variety of commercial, industry standard network authentication methods. Using IEEE 1609.2 (ISO 21177), X.509 certificates, OAUTH, cellular CN services, and many others Transport Layer Security (TLS) can be used for network security and authentication. Different USS / UTM systems can support different methods based on cost, commercial viability, and functional requirements and service differentiation.

[0074] Ideally, the solution should minimize deployment costs and time, integrate well into the security supply chain approach for UAS platform registration and onboarding, support the FAA and industry even possibly unaware of their security needs. To facilitate deployment, the solution should leverage mature standards that enjoy international adoption and deployment, and leverage security hardware / firmware technology available today that can be deployed in industrial and consumer electronics devices and supported by third party security services (e.g., Public Key Infrastructure (PKI) providers).

[0075] Considering the goals of the solution, it is clear that standard Internet certificate based solutions (e.g., X.509, PKCS7...) will not work in UAS applications because the certificates are too large, with sizes of 200-800 bytes, and require large PKCS7 or other Cryptographic Message Syntax (CMS) structures and encoding overhead.

[0076] The Wireless Access in Vehicular Environments (WAVE) protocol for the transportation industry is defined in the IEEE 1609 series of standards. While 1609.2 security is specifically designed for V2X communications, it operates above the radio access layer and is applicable to a variety of mobile IoT, application, or network security communication architectures. Given the small size of the 1609.2 certificates and their digital signature structure, 1609.2 certificates are well suited for the small frame sizes associated with WiFi Neighbor Awareness Networks (NAN) and Bluetooth.x beacons required by the ASTM specification. The well-structured interfaces and primitives defined in 1609.2 provide a variety of message security controls for broadcast senders and receivers, such as authentication / integrity, anti-replay, mitigation of certificate error binding attacks, and message consistency and correlation checks. Today, a variety of commercial services are available to support the 1609.2 based communication security ecosystem.

[0077] Accordingly, various embodiments start with the IEEE 1609.2 standard, which has been architected for low bandwidth V2X 5.9 GHz environments, and designed for "disconnected," mobile broadcast, or "unicast" based on application requirements and underlying media. Further, the IEEE 1609.2 standard provides a small certificate size (~100 bytes) using standard Elliptic Curve Digital Signature Algorithm (ECDSA) cryptography, which provides a small signature (ASN.1 SignedData) structure for a 25 byte signed ASTM payload that fits within the ASTM certification message auth data field (maximum size of 109 bytes). Accordingly, IEEE 1609.2 certification can sign and fit within any arbitrary 25 byte ASTM message, thereby supporting extensibility for new message types to be certified in ASTM or other standards that can emerge.

[0078] This is possible because IEEE 1609.2 is architected for this type of environment, i.e., heterogeneous, distributed, mobile, disconnected, or connected vehicular machine-to-machine communication. Further, there are two methods in 1609.2 to identify the signed certificate, including using a HashedID8, which is a truncated hash of the signed certificate that a message recipient can use to look up its certificate in a cache. In vehicle-to-everything (V2X) communication, a vehicle only sends its certificate for verifying its signed messages every so often (application configurable) because attaching the certificate to every signed message consumes too much radio spectrum.

[0079] IEEE 1609.2 certificates can be elliptic curve Qu Vanstone based "implicit certificates." The certificate authority (CA) is identified, but the CA signature is not included. The UAS public key is not included (at least not directly). What is included in the UAS certificate is a public key reconstruction value. The receiver computes the UAS public key from the public key reconstruction value and the known certificate authority. The UAS public key can then be used to verify the signed message. At the same time, this computation verifies the cryptographic chain (i.e., the CA signature on the UAS certificate). Accordingly, the size of the IEEE 1609.2 implicit certificate is half or less (depending on configuration) than a typical Internet X.509 certificate.

[0080] When open drone ID broadcasts are authenticated via a wireless network, the certificate should be discoverable in all cases, whether connected or disconnected, otherwise law enforcement and other broadcast receivers cannot verify / trust the UAS’s message when disconnected from the networked authentication “verifier” service. When a receiver device is connected to the network, verification of the drone ID broadcast can be achieved by the message receiver extracting the Hashedld8 (certificate hash) from the signature and performing a query via the authentication service to receive the certificate and verify it. Otherwise, the message receiver can relay the entire signature data and signed payload to the authentication service that holds the public key certificate. For example, the drone authentication service can indicate that the message was authenticated, or issue the full UAS certificate and let the message receiver verify it and all subsequent broadcasts from the drone on its own.

[0081] When the receiver device is disconnected (e.g., when a police officer is operating in a valley with no cellular connectivity, WiFi hotspots, etc.), the UAS adaptively or at pre-determined intervals (e.g., every 5-10 seconds), or on-demand broadcasts its certificate, and the message receiver caches the drone-sent certificate and uses it to verify all messages signed and broadcast from the drone. IEEE 1609.2 already has a mechanism for periodic broadcast of certificates, called Peer2Peer Certificate Distribution. The IEEE 1609.2 Peer2Peer Certificate Distribution message is small enough to be sent within the authentication data of an ASTM F3411-19 authenticated message (which has a maximum of 109 bytes) (using the ASTM “private” authentication type space or a new “1609.2-cert-broadcast” auth type officially adopted by ASTM). In essence, the UAS signs its own certificate broadcast. The validity of the certificate is vouched for by the certificate authority, and the utility of the certificate is evidenced by the fact that it verifies the signature of all other messages broadcast by the given UAS.

[0082] IEEE 1609.2 has more features that can be used, including message consistency checks for message age and whether the age has expired, and whether the message generating positioning and the sender are authorized to send certain message content within those positionings. The Secure Service Provider (SSP) is a permission bit that can be embedded into the certificate that indicates what content is allowed to be broadcast by the UAS. For example, the SSP can indicate whether the drone is associated with police, fire, or rescue services, and based on such a role, whether it is authorized to travel and broadcast with little restriction. As another example, the SSP can indicate that the UAS is a radio controlled (RC) aircraft that is only allowed to operate within a specified FAA flight area. Such additional features would take a little more overhead in the 1609.2 security header, and so are not yet done in all F3411-19 message formats. But if new 1609.2 integrated message types are used with ASTM, then such additional features can be supported.

[0083] Figure 1 is a system block diagram illustrating an example communication system 100 suitable for implementing any of the various embodiments. The communication system 100 can be a 5G New Radio (NR) network, or any other suitable network, such as an LTE network, a 5G (or next generation) network, etc. While a 5G network is illustrated, a next generation network can include the same or similar elements. Accordingly, references in the following description to a 5G network and 5G network elements are for purposes of illustration, and are not intended to be limiting. Figure 1

[0084] The communication system 100 can include a heterogeneous network architecture including a core network 140 and various devices (e.g., in communication with or not with each other). Figure 1 ​The diagram illustrates User Equipment (UE) 120a-120d, IoT device 120e, and UAS 120f. Communication system 100 may also include multiple base stations (BS 110a, BS 110b, BS 110c, and BS 110d) and other network entities. A base station is an entity that communicates with wireless devices and may also be referred to as a Node B, LTE Evolution Node B (eNodeB or eNB), Access Point (AP), Radio Header, Transmit / Receive Point (TRP), New Radio Base Station (NR BS), 5G NodeB (NB), Next Generation NodeB (gNodeB or gNB), etc. Each base station can provide communication coverage for a specific geographic area. In 3GPP, the term "cell" can refer to the coverage area of ​​a base station, a base station subsystem serving that coverage area, or a combination thereof, depending on the context in which the term is used. Core network 140 can be any type of core network, such as an LTE core network (e.g., an Evolved Packet Core (EPC) network), a 5G core network, etc. Although the communication system 100 is discussed with reference to various examples of the types of wireless devices 120a-120f (such as UE, UAS, IoT devices, etc.), these are merely examples and wireless devices 120a-120f can be any type of device, such as robots, vehicles, infrastructure, etc.

[0085] Base stations 110a-110d can provide communication coverage for macrocells, picocells, femtocells, another type of cell, or combinations thereof. Macrocells can cover a relatively large geographic area (e.g., a radius of several kilometers) and allow unrestricted access for mobile devices with service subscriptions. Picocells can cover a relatively small geographic area and allow unrestricted access for mobile devices with service subscriptions. Femtocells can cover a relatively small geographic area (e.g., a home) and allow restricted access for mobile devices associated with the femtocell (e.g., mobile devices in a Closed Subscriber Group (CSG)). A base station used for a macrocell can be referred to as a macro BS. A base station used for a picocell can be referred to as a pico BS. A base station used for a femtocell can be referred to as a femtocell BS or a home BS. Figure 1 In the example shown, base station 110a can be a macro BS for macro cell 102a, base station 110b can be a pico BS for pico cell 102b, and base station 110c can be a femto BS for femto cell 102c. Base stations 110a-110d can support one or more (e.g., three) cells. The terms "eNB", "base station", "NR BS", "gNB", "TRP", "AP", "Node B", "5G NB", and "cell" are used interchangeably herein.

[0086] In some examples, a cell can not be fixed and the geographic area of a cell can move according to the location of a mobile base station. In some examples, base stations 110a-110d can be interconnected to one or more other base stations, or network nodes (not shown) in the communications system 100, through various types of backhaul interfaces (such as a direct physical connection, a virtual network, or a combination of any suitable transport networks).

[0087] The base stations 110a-110d can communicate with the core network 140 through wired or wireless communication links 126. The wireless devices (e.g., user equipment (UE) 120a-120f) can communicate with the base stations 110a-110d through wireless communication links 122.

[0088] The wired communication links 126 can use a variety of wired networks, such as Ethernet, TV cable, phone, optical fiber, and other forms of physical network connections, which can use one or more wired communication protocols, such as Ethernet, point-to-point protocol, high-level data link control (HDLC), advanced data communication control protocol (ADCCP), and transmission control protocol / Internet protocol (TCP / IP).

[0089] The communications system 100 can also include relay stations (e.g., relay BS 110d). A relay station is an entity that can receive a transmission of data from an upstream station (e.g., a base station or a mobile device) and send a transmission of the data to a downstream station (e.g., a wireless device (e.g., UE) or a base station). A relay station can also be a mobile device that can relay transmissions for other mobile devices. Figure 1 In the illustrated example, the relay station 110d can communicate with the macro base station 110a and the wireless device 120d in order to facilitate communication between the base station 110a and the wireless device 120d. A relay station can also be referred to as a relay base station, a relay base station, a relay, or the like.

[0090] The communications system 100 can be a heterogeneous network that includes base stations of different types, e.g., macro base stations, pico base stations, femto base stations, relay base stations, or the like. These different types of base stations can have different transmit power levels, different coverage areas, and different impacts on interference in communications system 100. For example, macro base stations can have a high transmit power level (e.g., 5 to 40 Watts), whereas pico base stations, femto base stations, and relay base stations can have lower transmit power levels (e.g., 0.1 to 2 Watts).

[0091] A network controller 130 can couple to a set of base stations and can provide coordination and control for these base stations. The network controller 130 can communicate with the base stations via a backhaul. The base stations can also communicate with one another, e.g., directly or indirectly via a wireless or wireline backhaul.

[0092] Wireless devices (e.g., UEs, UASs, etc.) 120a, 120b, 120c, 120e, 120d, 120f can be dispersed throughout the communications system 100, and each can be stationary or mobile. A wireless device can also be referred to as an access terminal, terminal, mobile station, subscriber unit, station, user device (UE), unmanned aerial system (UAS), broadcast receiver device (BRD), Internet of Things (IoT) device, etc.

[0093] The macro base station 110a can communicate with a communication network 140 through a wired or wireless communication link 126. The wireless devices 120a, 120b, 120c, 120f can communicate with the base stations 110a-110d through wireless communication links 122.

[0094] The wireless communication links 122, 124 can include multiple carrier signals, frequencies or bands, each of which can include multiple logical channels. The wireless communication links 122 and 124 can utilize one or more radio access technologies (RATs). Examples of RATs that can be used in the wireless communication links include 3GPP LTE, 3G, 4G, 5G (e.g., NR), GSM, CDMA, WCDMA, Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile telephone communication technologies cellular RATs. Further examples of RATs that can be used in one or more of the various wireless communication links 122, 124 within the communications system 100 include medium range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire, and relatively short range RATs such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE).

[0095] Certain wireless networks (e.g., LTE) utilize orthogonal frequency division multiplexing (OFDM) on the downlink and single-carrier frequency division multiplexing (SC-FDM) on the uplink. OFDM and SC-FDM partition the system bandwidth into multiple (K) orthogonal subcarriers, which are also commonly referred to as tones, bins, or the like. Each subcarrier can be modulated with data. In general, modulation symbols are sent in the frequency domain with OFDM and in the time domain with SC-FDM. The spacing of adjacent subcarriers can be fixed, and the total number of subcarriers (K) can be dependent on the system bandwidth. For example, the spacing of the subcarriers can be 15 kHz and the minimum resource allocation (called a “resource block” (RB)) can be 12 subcarriers (or 180 kHz). Consequently, for a 1.25, 2.5, 5, 10, or 20 megahertz (MHz) system bandwidth, the nominal fast Fourier transform (FFT) size can be equal to 128, 256, 512, 1024, or 2048, respectively. The system bandwidth can also be partitioned into subbands. For example, a subband can cover 1.08 MHz (i.e., 6 resource blocks), and there can be 1, 2, 4, 8, or 16 subbands for a 1.25, 2.5, 5, 10, or 20 MHz system bandwidth, respectively.

[0096] While the description of some embodiments can use terminology and examples associated with the LTE technology, various embodiments can be applied to other wireless communication systems, such as a New Radio (NR) or 5G network. NR can utilize OFDM with a cyclic prefix (CP) on the uplink (UL) and downlink (DL) and include support for half-duplex operation using time division duplex (TDD). A single component carrier (CC) bandwidth of 100 MHz can be supported. An NR resource block can span 12 subcarriers with a subcarrier bandwidth of 75 kHz over a 0.1 millisecond (ms) duration. Each radio frame can consist of 50 subframes with a length of 10 ms. Consequently, each subframe can have a length of 0.2 ms. Each subframe can indicate a link direction (i.e., DL or UL) for data transmission and the link direction for each subframe can be dynamically switched. Each subframe can include DL / UL data as well as DL / UL control data. Beamforming can be supported and beam direction can be dynamically configured. Multiple input multiple output (MIMO) transmissions with precoding can also be supported. MIMO configurations in the DL can support up to eight transmit antennas with multiple layers of up to eight streams and up to two streams per wireless device. Multi-layer transmissions with up to two streams for each wireless device can be supported. Aggregation of multiple cells can be supported with up to eight serving cells. Alternatively, NR can support a different air interface that is not based on OFDM.

[0097] Some mobile devices can be considered machine-type communication (MTC) or evolved or enhanced machine-type communication (eMTC) mobile devices. MTC and eMTC mobile devices include, for example, robots, drones, remote devices, sensors, meters, monitors, location tags, etc., that can communicate with a base station, another device (for example, remote device), or some other entity. A wireless node can provide, for example, connectivity for or to a network (for example, a wide area network such as Internet or a cellular network) via a wired or wireless communication link. Some mobile devices can be considered Internet-of-Things (IoT) devices, or can be implemented as NB-IoT (narrowband internet of things) devices. The wireless devices (for example, UEs) 120a-e can be included in a housing that houses components of the wireless devices.

[0098] In general, any number of communication systems and any number of wireless networks can be deployed in a given geographic area. Each communication system and wireless network can support a particular radio access technology (RAT) and can operate on one or more frequencies. A RAT can also be referred to as a radio technology, an air interface, etc. A frequency can also be referred to as a carrier, a frequency channel, etc. Each frequency can support a single RAT in a given geographic area in order to avoid interference between wireless networks of different RATs. In some cases, 4G / LTE and / or 5G / NR RAT networks can be deployed. For example, a 5G non-standalone (NSA) network can use 4G / LTE RAT on the 4G / LTE RAN side of the 5G NSA network and 5G / NR RAT on the 5G / NR RAN side of the 5G NSA network. The 4G / LTE RAN and the 5G / NR RAN can be connected to each other and to a 4G / LTE core network (for example, an EPC network) in the 5G NSA network.

[0099] In some embodiments, two or more wireless devices 120a-f (e.g., illustrated as wireless device 120a and IoT device 120e or wireless device 120a and UAS 120f) can communicate directly using one or more sidelink channels 124 (e.g., without using base stations 110a-d as an intermediary to communicate with one another). For example, wireless devices 120a-e can communicate using peer-to-peer (P2P) communications, device-to-device (D2D) communications, a vehicle-to-everything (V2X) protocol (which can include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or similar protocols), a C-V2X protocol, Bluetooth communications, Wi-Fi communications, a mesh network, or similar, ADS-B broadcasts, or combinations thereof. In this case, wireless devices 120a-f can perform scheduling operations, resource selection operations, and other operations described elsewhere herein as being performed by base stations 110a.

[0100] In some embodiments, a certificate authority (CA) server 156 can provide certificates and manage keys, such as private keys, public keys, and the like, in network 100. CA server 156 can provide certificates (e.g., explicit certificates, implicit certificates, and the like) and / or keys (e.g., private keys, public keys, and the like) to wireless devices 120a-f.

[0101] Figure 2A FIG. 2 is a component block diagram illustrating an example computing and wireless modem system 200 suitable for implementing any of the various embodiments. The various embodiments can be implemented on a number of single and multi-processor computer systems including a system on a chip (SOC) or a system in a package (SIP).

[0102] With reference to Figure 1 and Figure 2AThe example wireless device 200 (which can be a SIP in some embodiments) shown includes two SOCs 202, 204 coupled to a clock 206, a voltage regulator 208, and a wireless transceiver 266 configured to transmit and receive wireless communications to / from network wireless devices such as base stations 110a and / or other wireless devices (e.g., wireless devices 120a-f) via an antenna (not shown). In some embodiments, the first SOC 202 operates as a central processing unit (CPU) of the wireless device, which implements instructions of software applications by performing arithmetic, logical, control and input / output (I / O) operations specified by the instructions. In some embodiments, the second SOC 204 can operate as a specialized processing unit. For example, the second SOC 204 can operate as a specialized 5G (or next generation) processing unit responsible for managing high capacity, high speed (e.g., 5 Gbps, etc.) and / or very high frequency short wavelength (e.g., 28 GHz mmWave spectrum, etc.) communications. In some embodiments, the wireless transceiver 266 can be a wireless transceiver configured to support peer-to-peer (P2P) communications, device-to-device (D2D) communications, vehicle-to-everything (V2X) protocols (which can include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or similar protocols), Bluetooth communications, Wi-Fi communications, etc.

[0103] The first SOC 202 can include a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor (AP) 216, one or more coprocessors 218 (e.g., vector co-processor) connected to one or more processors, a memory 220, custom circuitry 222, system components and resources 224, an interconnect / bus module 226, one or more temperature sensors 230, a thermal management unit 232, and a thermal power envelope (TPE) component 234. The second SOC 204 can include a 5G modem processor 252, a power management unit 254, an interconnect / bus module 264, a plurality of mmWave transceivers 256, a memory 258, and various additional processors 260 such as an application processor, a packet processor, etc.

[0104] Each processor 210, 212, 214, 216, 218, 252, 260 can include one or more cores, and each processor / core can perform operations independently of the other processors / cores. For example, the first SOC 202 can include processors that execute a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and processors that execute a second type of operating system (e.g., MICROSOFT WINDOWS 10). Additionally, any or all of the processors 210, 212, 214, 216, 218, 252, 260 can be included as part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).

[0105] The first and second SOCs 202, 204 can include various system components, resources, and custom circuitry for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations such as decoding data packets and processing encoded audio and video signals for presentation in a web browser. For example, the system components and resources 224 of the first SOC 202 can include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components for supporting processors and software clients running on the wireless device. The system components and resources 224 and / or custom circuitry 222 can also include circuitry to interface with peripheral devices such as cameras, electronic displays, wireless communication devices, external memory chips, etc.

[0106] The first and second SOCs 202, 204 can communicate via an interconnect / bus module 250. The various processors 210, 212, 214, 216, 218 can be interconnected to one or more memory elements 220, system components and resources 224, and custom circuitry 222 and thermal management unit 232 via an interconnect / bus module 226. Similarly, the processor 252 can be interconnected to the power management unit 254, mmWave transceiver 256, memory 258, and various additional processors 260 via an interconnect / bus module 264. The interconnect / bus modules 226, 250, 264 can include an array of reconfigurable logic gates and / or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications can be provided by an advanced interconnect such as a high-performance network-on-chip (NoC).

[0107] The first and / or second SOC 202, 204 can also include input / output modules (not shown) for communicating with resources external to the SOC, such as a clock 206 and a voltage regulator 208. Resources external to the SOC (e.g., clock 206, voltage regulator 208) can be shared by two or more of the internal SOC processors / cores.

[0108] In addition to the example SIP 200 discussed above, various embodiments can be implemented in a wide variety of computing systems, which can include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0109] A robotic vehicle can include an unmanned aerial system (UAS), such as a winged or rotorcraft class of flying robotic vehicles. Figure 2B An example of a robotic vehicle 270, such as a flying robotic vehicle (e.g., a UAS (e.g., UAS 120f), a UAV, etc.) is shown that utilizes a plurality of rotors 272 driven by respective engines to provide lift-off (or takeoff) as well as other flight movements (e.g., forward propulsion, ascent, descent, lateral movement, tilting, rotation, etc.). The robotic vehicle 270 is shown as an example of a robotic vehicle that can utilize various embodiments, but is not intended to imply or require that various embodiments are limited to flying robotic vehicles or rotorcraft robotic vehicles. Various embodiments can be used with winged robotic vehicles, land-based autonomous vehicles, water-based autonomous vehicles, sky-based autonomous vehicles, etc. In addition, while various embodiments are discussed with reference to vehicles such as UASs, vehicles are merely an example of a device that can utilize various embodiments, and the example of vehicles, particularly UASs, is not intended to imply or require that various embodiments are limited to vehicles or UASs. Various embodiments can be used with a variety of different devices, such as Internet of Things (IoT) devices, infrastructure devices, robots, etc.

[0110] With reference to Figures 1-2BThe robotic vehicle 270 can be similar to the UAS 120f. The robotic vehicle 270 can include a plurality of rotors 272, a frame 274, a landing column 276 or skid, and one or more indicators 281, such as one or more LEDs, one or more incandescent bulbs, one or more display screens, one or more or more speakers, one or more horns, one or more buzzers or bells, and the like. The frame 274 can provide structural support for the engines associated with the rotors 272. The landing column 276 can support the maximum load weight of the combination of components and payload (in some cases) of the robotic vehicle 270. Some detailed aspects of the robotic vehicle 270 are omitted for ease of description and illustration, such as wiring, frame structure interconnections, or other features known to those of skill in the art. For example, while the robotic vehicle 270 is shown and described as having a frame 274 with a plurality of support members or frame structures, the robotic vehicle 270 can be constructed using a molded frame, where support is obtained through the molded structure. While the illustrated robotic vehicle 270 has four rotors 272, this is merely exemplary and various embodiments can include more or less than four rotors 272.

[0111] The robotic vehicle 270 can also include a control unit 280, which can house various circuits and devices for driving and controlling the operation of the robotic vehicle 270. The control unit 280 can include a processor 282, a power module 287, sensors 240, one or more cameras 244, an output module 289, an input module 271, and a radio module 269. Optionally, the control unit can also include one or more of the indicators 281. The power module 287, the sensors 240, the one or more cameras 244, the output module 289, the input module 271, the radio module 269, and / or the one or more indicators 281 can be connected to the processor 282.

[0112] The processor 282 can be configured with processor-executable instructions to control the travel of the robotic vehicle 270 and other operations including the operations of various embodiments. The processor 282 can include or be coupled to a navigation unit 283, a memory 284, a gyro / accelerometer unit 285, a cryptography module 299, and an avionics module 286. The processor 282, the cryptography module 299, and / or the navigation unit 283 can be configured to communicate with another computing device (e.g., a broadcast receiver device, an operator’s computing device, an observer’s computing device, etc.) over a wireless communication link, such as the wireless communication links 122, 124.

[0113] The avionics module 286 can be coupled to the processor 282 and / or the navigation unit 283 and can be configured to provide information related to flight control, such as altitude, attitude, airspeed, heading, and similar information that the navigation unit 283 can use for navigation, such as dead reckoning between global navigation satellite system (GNSS) position updates. The gyroscope / accelerometer unit 285 can include an accelerometer, a gyroscope, an inertial sensor, or other similar sensor. The avionics module 286 can include or receive data from the gyroscope / accelerometer unit 285, which provides data related to the orientation and acceleration of the robotic vehicle 270 that can be used for navigation and positioning calculations, and provides data for various embodiments.

[0114] The processor 282 can also receive additional information from sensors 240, such as image sensors or optical sensors (e.g., sensors capable of sensing visible light, infrared, ultraviolet, and / or other wavelengths of light). The sensors 240 can also include a radio frequency (RF) sensor, a barometer, a humidity sensor, a sonar emitter / detector, a radar emitter / detector, a microphone or another acoustic sensor, a lidar sensor, a time-of-flight sensor (TOF) 3-D camera, or another sensor that can provide information that the processor 282 can use for movement operations, navigation and positioning calculations, and determining environmental conditions. The sensors 240 can also include one or more sensors configured to detect temperature generated by one or more robotic vehicle components, such as a thermometer, a thermistor, a thermocouple, a positive temperature coefficient sensor, and other sensor components.

[0115] The power module 287 can include one or more batteries that can provide power to various components including the processor 282, the sensors 240, the one or more cameras 244, the output module 289, the input module 271, the one or more indicators 281, and the radio module 269. Additionally, the power module 287 can include an energy storage component, such as a rechargeable battery. The processor 282 can be configured with processor-executable instructions to control charging (i.e., storage of harvested energy) of the power module 287, such as by using a charge control circuit to execute a charge control algorithm. Alternatively or additionally, the power module 287 can be configured to manage its own charging. The processor 282 can be coupled to the output module 289, which can output control signals for managing the engines that drive the rotors 272 and other components, including the one or more indicators 281 if not directly connected to the processor 282.

[0116] As the robotic vehicle 270 progresses toward the destination, the robotic vehicle 270 can be controlled by controlling the individual motors of the rotors 272. Control of the individual motors of the rotors 272 can enable the robotic vehicle to perform maneuvers (e.g., barrel rolls, descents, climbs, spins, etc.). The processor 282 can receive data from the navigation unit 283 and use such data in order to determine the current position and orientation of the robotic vehicle 270, as well as an appropriate route toward the destination or intermediate locations. In various embodiments, the navigation unit 283 can include a GNSS receiver system (e.g., one or more global positioning system (GPS) receivers) that enables the robotic vehicle 270 to navigate using GNSS signals. Alternatively or additionally, the navigation unit 283 can be equipped with radio navigation receivers for receiving navigation beacons or other signals from radio nodes such as navigation beacons (e.g., very high frequency (VHF) omnidirectional range (VOR) beacons), Wi-Fi access points, cellular network sites, radio stations, remote computing devices, other robotic vehicles, etc.

[0117] The radio module 269 can be configured to receive navigation signals, such as signals from aviation navigation facilities and the like, and provide these signals to the processor 282 and / or the navigation unit 283 to assist the robotic vehicle in navigation. In various embodiments, the navigation unit 283 can use signals received from identifiable RF transmitters on the ground (e.g., AM / FM radio stations, Wi-Fi access points, and cellular network base stations).

[0118] The navigation unit 283 can include a planning application that can perform calculations to plan a path of motion of the robotic vehicle within a volumetric space ("path planning"). In some embodiments, the planning application can use information to perform path planning, including information about aspects of a task to be performed by the robotic vehicle, environmental condition information, heat that can be generated by one or more components of the robotic vehicle in performing the task, and one or more thermal constraints.

[0119] The radio module 269 can include a modem 268 and transmit / receive antenna 272. In some embodiments, the radio module 269 and / or modem 268 can be separate processors and / or components of the same SOC. The radio module 269 can be configured to wirelessly communicate with various wireless communication devices, such as a broadcast receiver device (BRD) 290, examples of which include a wireless telephone base station or cell tower (e.g., base station 110a), a network access point (e.g., access point), a beacon, a smartphone, a tablet computer, a laptop computer, or other computing device with which the robotic vehicle 270 can communicate. As a particular example, the BRD 290 can be a wireless device of a law enforcement officer, emergency responder, military unit, or other government entity. The processor 282 can establish a bidirectional wireless communication link 294 via the modem 268 and antenna 272 of the radio module 269 and BRD 290 and via the transmit / receive antenna 292. In some embodiments, the radio module 269 can be configured to support multiple connections with different wireless communication devices using different radio access technologies. In some embodiments, the radio module 269 can be configured to broadcast beacon-type messages from the robotic vehicle 270, such as beacon messages for peer-to-peer (P2P) communications, beacon messages for device-to-device (D2D) communications, beacon messages for vehicle-to-everything (V2X) protocols (which can include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or similar protocols), beacon messages for Bluetooth communications, beacon messages for Wi-Fi communications, and the like.

[0120] In some embodiments, the cryptographic module 299 can be configured to encrypt and / or decrypt data and / or messages sent and / or received by the robotic vehicle. The cryptographic module 299 can manage keys, such as public keys, private keys, and / or the like, and / or certificates for the robotic vehicle 270. The cryptographic module 299 can be configured to generate hashes of various values, such as using a hash algorithm (e.g., secure hash algorithm (SHA) 256, or the like). In various embodiments, the cryptographic module 299 can be configured to cryptographically sign messages (e.g., beacon-type messages) of the robotic vehicle 270 to generate signed messages, such as signed beacon-type messages.

[0121] In some embodiments, the BRD 290 can connect to a server through an intermediate access point. In an example, the BRD 290 can be a server for a robotic vehicle operator, a third-party service (e.g., package delivery, billing, etc.), or a site communication access point. The robotic vehicle 270 can communicate with the server through one or more intermediate communication links, such as a wireless telephony network coupled to a wide area network (e.g., the Internet) or other communication device. In some embodiments, the robotic vehicle 270 can include and employ other forms of radio communication, such as mesh connections with other robotic vehicles or connections with other sources of information (e.g., balloons or other stations for collecting and / or distributing weather or other data gathering information).

[0122] In various embodiments, the control unit 280 can be equipped with input modules 271 that can be used for various applications. For example, the input modules 271 can receive images or data from the on-board camera 244 or sensors, or can receive electronic signals (e.g., payload) from other components.

[0123] While the various components of the control unit 280 are shown as separate components, some or all of these components (e.g., the processor 282, the output modules 289, the radio modules 269, and other units) can be integrated into a single device or module, such as a system-on-a-chip module.

[0124] Figure 3 is a component block diagram illustrating a software architecture 300 suitable for implementing any of the various embodiments, including a radio protocol stack for user and control planes in wireless communication. Reference is made to Figures 1-3The wireless device 320 can implement the software architecture 300 to facilitate communication between the wireless device 320 (e.g., wireless devices 120a-120f, 200, 270) and base stations 350 (e.g., base stations 110a, BRD 290) of a communication system (e.g., 100). In various embodiments, layers in the software architecture 300 can form a logical connection with corresponding layers in software of the base stations 350. The software architecture 300 can be distributed among one or more processors (e.g., processors 212, 214, 216, 218, 252, 260, 282). While described with respect to one radio protocol stack, in multi-SIM (subscriber identity module) wireless devices, the software architecture 300 can include multiple protocol stacks, each of which can be associated with a different SIM (e.g., in a dual-SIM card wireless communication device, two protocol stacks are associated with the two SIM cards, respectively). While described below with reference to LTE communication layers, the software architecture 300 can support any of a variety of standards and protocols for wireless communication, and / or can include additional protocol stacks supporting any of a variety of wireless communication standards and protocols, such as Wi-Fi communication, Bluetooth communication, V2X communication, IoT communication, etc.

[0125] The software architecture 300 can include a non-access stratum (NAS) 302 and an access stratum (AS) 304. The NAS 302 can include functions and protocols that support packet filtering, security management, mobility control, session management, and traffic and signaling between the SIM(s) of the wireless device and the core network 140 thereof. The AS 304 can include functions and protocols that support communication between the SIM(s) and entities of the supported access networks (e.g., base stations). Specifically, the AS 304 can include at least three layers (Layer 1, Layer 2, and Layer 3), each of which can contain various sub-layers.

[0126] In the user and control planes, Layer 1 (LI) of the AS 304 can be a physical layer (PHY) 306, which can oversee functions that enable transmission and / or reception over the air interface. Examples of such physical layer 306 functions can include cyclic redundancy check (CRC) attachment, coding blocks, scrambling and descrambling, modulation and demodulation, signal measurements, MIMO, etc. The physical layer can include various logical channels, including a physical downlink control channel (PDCCH) and a physical downlink shared channel (PDSCH).

[0127] In the user and control planes, layer 2 (L2) of AS 304 can be responsible for the link between wireless device 320 and base station 350 through physical layer 306. In various embodiments, layer 2 can include a medium access control (MAC) sublayer 308, a radio link control (RLC) sublayer 310, and a packet data convergence protocol (PDCP) 312 sublayer, each of which forms a logical connection that terminates at base station 350.

[0128] In the control plane, layer 3 (L3) of AS 304 can include a radio resource control (RRC) sublayer 313. Although not shown, software architecture 300 can include additional layer 3 sublayers, as well as various upper layers above layer 3. In various embodiments, RRC sublayer 313 can provide functions including broadcast of system information, paging, and establishment and release of an RRC signaling connection between wireless device 320 and base station 350.

[0129] In various embodiments, PDCP sublayer 312 can provide uplink functions including multiplexing of different radio bearers and logical channels, sequence number addition, handover data handling, integrity protection, ciphering, and header compression. In the downlink, PDCP sublayer 312 can provide functions including in-sequence delivery of data packets, duplicate data packet detection, integrity verification, deciphering, and header decompression.

[0130] In the uplink, RLC sublayer 310 can provide segmentation and concatenation of upper layer data packets, retransmission of lost data packets, and automatic repeat request (ARQ). In the downlink, RLC sublayer 310 functions can include reordering data packets to compensate for out-of-sequence reception, reassembly of upper layer data packets, and ARQ.

[0131] In the uplink, MAC sublayer 308 can provide functions including multiplexing between logical and transport channels, random access procedures, logical channel prioritization, and hybrid ARQ (HARQ) operation. In the downlink, MAC layer functions can include channel mapping, demultiplexing, discontinuous reception (DRX), and HARQ operation within a cell.

[0132] Although software architecture 300 can provide functions for transmitting data over a physical medium, software architecture 300 can also include at least one host layer 314 to provide data transfer services to various applications in wireless device 320. In some embodiments, application-specific functions provided by at least one host layer 314 can provide an interface between the software architecture and a general-purpose processor.

[0133] In other embodiments, the software architecture 300 can include one or more higher logical layers (e.g., transport, session, presentation, application, etc.) that provide host layer functionality. For example, in some embodiments, the software architecture 300 can include a network layer (e.g., IP layer) in which the logical connection terminates at a packet data network (PDN) gateway (PGW). In some embodiments, the software architecture 300 can include an application layer in which the logical connection terminates at another device (e.g., an end user device, a server, etc.). In some embodiments, the software architecture 300 can also include a hardware interface 316 between the AS 304 and the physical layer 306 and communication hardware (e.g., one or more radio frequency (RF) transceivers) in some embodiments.

[0134] Figure 4A An example broadcast of beacon-type messages 406 by a device 402 to a number of other broadcast receiver devices 407a-407d is shown. As used herein, a "beacon-type message" or "beacon-like" message can be a small, compact message that is typically broadcast as part of another radio access protocol in which the parent frame of each message within the protocol does not provide pairing, communication, or security related context, or an association between a broadcaster and a broadcast receiver. In view of their small size, beacon-type messages or beacon-like messages are often unprotected, or protected only by symmetric message authentication techniques. With reference to Figures 1-4A , the device 402 can be any device that broadcasts beacon-type messages 406, such as a wireless device (e.g., wireless devices 120a-120f, 200, 270, 320) or a base station (e.g., base stations 110a, 350, BRD 290). The broadcast receiver devices 407a-d can be any device that receives beacon-type messages 406, such as a wireless device (e.g., wireless devices 120a-120f, 200, 270, 320) or a base station (e.g., base stations 110a, 350, BRD 290). The beacon-type messages 406 can be management and service discovery frames that are broadcast to neighbors. For example, the beacon-type messages 406 can be Wi-Fi Aware (using a Wi-Fi Neighbor Awareness Network or "NAN", specifically a NAN service discovery frame), Bluetooth beacon messages (e.g., Bluetooth 4 beacon messages, Bluetooth 5 beacon messages, etc.), Zigbee beacon messages, or any other type of broadcast management and service discovery frame. The beacon-type messages 406 are typically issued without a security association. The beacon-type messages 406 can be small size messages, such as messages that are 125 bytes in length or less. As such, the beacon-type messages 406 cannot support the use of typical certificates such as X.509 certificates, which tend to be in the range of 200-500 in size.

[0135] Figure 4BAn example of one-to-one transmission of a secure message after pairing of two devices 402 and 407a is shown. Reference is made to Figures 1-4A After discovery, devices 402 and 407a can perform operations to establish one-to-one communication and pair with each other in accordance with operations of a communication protocol used for communication between devices 402 and 407a, such as a Wi-Fi pairing operation, a Bluetooth pairing operation, etc. Pairing of devices 407a and 402 enables a secure association between the two devices 402, 407a, and symmetrically authenticated / encrypted messages 420 can be exchanged between the two devices 402, 407a. The symmetrically authenticated / encrypted messages 420 issued as part of the pairing operation and / or after pairing is complete are not beacon type messages because the symmetrically authenticated / encrypted messages 420 are not used for discovery, advertising, or advertising of devices 402, 407a.

[0136] Figure 5 Various aspects of ASTM F3411-19 messages are shown. Reference is made to Figures 1-5 A smallest single ASTM F3411-19 message 502 is twenty-five bytes. Examples of twenty-five byte ASTM F3411-19 messages 502 include a basic ID message (type 0x0) that will be used for identification of a drone (e.g., serial number, UUID, etc.) that is limited to 25 bytes; a position / vector message (type 0x1) that provides position, velocity, heading, and altitude of the drone that is also limited to 25 bytes; a self-ID message (type 0x3) that can be a short text describing the current action of the drone and is limited to 25 bytes; a system message (type 0x4) that identifies operator position and / or flight area and is limited to 25 bytes; and an operator ID message (type 0x5) that includes an operator ID issued by a regulatory agency and is limited to 25 bytes. The 25 byte ASTM F3411-19 can be an example of a device message. Other examples of device messages can include Automatic Dependent Surveillance-Broadcast (ADS-B) messages, such as broadcast beacons or service advertisement frames that support NextGen air surveillance and tracking systems.

[0137] ASTM F3411-19 can also support messages 504 issued over multiple pages or frames, such as five pages or frames. In particular, the messages 504 can be authentication messages (type 0x2) that include an authentication message set that can be up to 125 bytes (5 “pages”) to accommodate legacy beacons (BT4);

[0138] ASTM F3411-19 can also support message packets 506 or message sets 508, such as message packets (type 0xF), which are a collection of n messages sent in one frame, must fit within 250 bytes, including headers, but only apply to Bluetooth 5 and WiFi technologies. As an example, message sets 508 can be Bluetooth 5 beacons with extended advertising, which will point to a 255 byte auxiliary frame on a non-beacon channel (called extended advertising). Similarly, WiFi Neighbor Awareness Networking (NAN) will provide a management frame [type 0, subtype 13 "action"] defined in 802.11-2016 Part 11, which provides a NAN service discovery frame up to 255 bytes in length.

[0139] Various embodiments can support certificate-based signing of small size messages, such as messages that are 125 bytes or less in length, small enough to fit in multi-page Bluetooth 4 beacons or Bluetooth 5 extended advertising or WiFi NAN service advertising frames. As a particular example, various embodiments can implement certificate-based signing of ASTM F3411-19 certified messages 504 and message sets 508. As other examples, various embodiments can implement certificate-based signing of messages emitted from IoT devices, robots, vehicles, and the like. Various embodiments can leverage IEEE 1609.2 certificate format and signing scheme aspects to cryptographically sign beacon type messages, especially small size beacon type messages such as 125 bytes or less in length. Various embodiments leverage the lightweight, strong encryption certificates specified in IEEE 1609.2 to authenticate and integrity protect UAS broadcast ID messages. When either the UAS, the broadcast receiver, or both communication endpoints have degraded or no cellular or other IP connectivity and cannot access a centralized authentication service, it is critical to provide a functional and secure broadcast ID. Various embodiments can meet the basic operational concepts described in the FAA's proposed drone ID and tracking NPRM, apply the 1609.2 security model, and pave the way for 1609.2's security services to play within the constraints of ASTM F3411-19.

[0140] Figure 6A is a process flow diagram illustrating a method 600 for providing security for broadcast communications that can be performed by a processor of a device. Reference is made to Figures 1-6AThe method 600 can be implemented by a processor of a device, such as a wireless device (e.g., the wireless devices 120a-120f, 200, 270, 320, 402, 407a-d) or a base station (e.g., the base stations 110a, 350, BRD 290). In some embodiments, the operations of the method 600 can be performed by a processor of a wireless device that is configured to broadcast small size messages, such as messages that are 125 bytes or less in length. As an example, the operations of the method 600 can be performed by a processor of an IoT device, a processor of an autonomous or semi-autonomous vehicle, a processor of a robot, a processor of a roadside infrastructure device, a processor of a UAS, etc. Reference is made to Figures 1-6A The component for performing each operation of the method 600 can be one or more processors of a device (e.g., the wireless devices 120a-120f, 200, 270, 320, 402, 407a-d, the base stations 110a, 350, BRD 290, etc.), such as one or more of the processors 210, 212, 214, 216, 218, 252, 260, etc.

[0141] In block 602, the processor can generate a beacon type message. The beacon type message can be a service, discovery, announcement, advertising, or management type message or frame that can be issued in a one-to-many broadcast prior to any one-to-one paired communication between the device issuing the beacon type message and another device. The beacon type message can be a small size message, such as a message that is 125 bytes or less in length. Examples of beacon type messages can include Bluetooth beacon frames (e.g., Bluetooth 4 beacon frames, Bluetooth 5 beacon frames, Bluetooth 5 extended advertising frames, etc.), Wi-Fi beacon frames (e.g., Wi-Fi NAN service discovery frames, etc.), Zigbee beacon frames, ASTM F3411-19 certification messages, etc.

[0142] In block 604, the processor can encrypt-sign the beacon type message using, at least in part, the certificate to generate a signed beacon type message. Encrypt-signing the beacon type message can include generating a digital signature using the certificate and / or other cryptographic elements (e.g., a hash identifier, a certificate identifier, a timestamp, a public key reconstruction value, an explicit certificate, an implicit certificate, etc.) and embedding the digital signature and / or other cryptographic elements in the beacon type message as cryptographic overhead, thereby generating a signed beacon. In various embodiments, the certificate can be an explicit certificate. In various embodiments, the certificate can be an implicit certificate. In various embodiments, the certificate can be provided by a CA. In various embodiments, the certificate or a portion of the certificate can correspond to an identifier of the device, such as a universally unique identifier (UUID) or a session identifier (session ID) assigned to the UAS. As a specific example, a bit portion of the certificate, such as the first 128 bits of the certificate, the last 128 bits of the certificate, the first 64 bits of the certificate, the last 64 bits of the certificate, the first 96 bits of the certificate, the last 96 bits of the certificate, the first 100 bits of the certificate, the last 100 bits of the certificate, etc. can correspond to the UUID or session ID assigned to the UAS.

[0143] The certificate used in block 604 can also contain an identifier (ID) defined by the cryptographic binding of a given UAS to a given UAS operator. Multiple such certificate IDs can be computed for the same tuple of {UAS, UAS_Operator}, representing a broadcast certificate that can be ephemeral but associated with the same drone and operator. In some aspects, the embedded certificate identifier can be a cryptographic binding of both the UAS identifier and the operator identifier, such as a full or partial hash of a secret operator identification key along with the UAS identifier and a counter or other non-repeating or unique parameter, or can be a keyed message authentication code using the same inputs. As a specific example, in a UTM system, each broadcast certificate can be identified by a cryptographic binding of the UAS identifier and the operator identifier. Such a cryptographic binding can reduce the number of certificate types and uses in a UTM system.

[0144] In various embodiments, the certificate can be an IEEE 1609.2 certificate. Various embodiments leverage the lightweight, strong cryptographic certificates specified in IEEE 1609.2 to authenticate and integrity protect UAS broadcast ID messages. Providing a functional and secure broadcast ID is critical when either the UAS, the broadcast receiver, or both communication endpoints have degraded or no cellular or other IP connectivity and cannot access a centralized authentication service. Various embodiments can meet the basic operational concepts described in the FAA’s Unmanned Aircraft ID and Tracking NPRM, apply the 1609.2 security model, and pave the way for 1609.2’s security services to play within the constraints of ASTM F3411-19.

[0145] IEEE 1609.2 is a standard that defines a compact certificate format using NIST FIPS 186-4 Elliptic Curve Cryptography (ECC). IEEE 1609.2 certificates can be summarized as being permission-based and / or identity-based. These provide a level of trust to the certificate holder and are well suited for on-line and off-line message passing. IEEE 1609.2 provides a security framework and primitive set that enables certificates to be used to meet a variety of communication security goals, not just simple identification and authentication of a message or its originator; provides optional message integrity checks, correlation checks, and 1609.2 security profile settings that can be tuned to the needs of a given application; and supports mobile broadcast security in environments that are disconnected from the network. IEEE 1609.2 is a planned and standardized security technology that can be used by millions of disconnected mobile devices (e.g., vehicle mounted equipment) as well as connected infrastructure equipment. The security based on IEEE 1609.2 is planned to work in environments characterized by tight bandwidth and message size limitations and / or high message broadcast rates. IEEE 1609.2 is also the de facto standard for protecting vehicle and transportation infrastructure broadcast messages. The United States has standardized its use for all V2X broadcast communications. At the end of 2018, Europe (ETSI) adopted V2X message passing security based on 1609.2 certificates for use throughout the European Union. Chipset manufacturers such as Autotalks, Qualcomm (High Tech), and others have integrated 1609.2 certificates and related secret and private key material into secure processors. Today, IEEE 1609.2 security stacks and ancillary V2X PKI services are at Technology Readiness Level (TRL) 8-9. As a result, the aviation community and ASTM compliant equipment manufacturers can benefit from reduced costs associated with expansion in software, hardware, and PKI services provided by companies such as Green Hills ISS, Blackberry, and others worldwide that support 1609.2. These services can be provided as integrated services within UTM / USS systems or as ancillary services to them.

[0146] IEEE 1609.2 certificates are the backbone of 1609.2 security services and are planned to be very small and work in bandwidth constrained environments without sacrificing cryptographic strength. 1609.2 certificates have an explicit format in which the complete public key of an end entity is included in a certificate signed by a certificate authority (CA). It also has an implicit format that “allows the associated public key to be reconstructed from a reconstructed value and the public key of the certificate authority, rather than providing the associated public key directly.”

[0147] Implicit certificates are based on the Qu-Vanstone Elliptic Curve Implicit Certificate scheme (ECQV) and are much smaller in size compared to explicit certificates that contain the full public key and a signature on the certificate by the certificate authority. The length of an 1609.2 implicit certificate is approximately 100 bytes, small enough to be sent in an ASTM certification or other custom message.

[0148] Pseudonym certificates, identity and application certificates are privacy preserving "authorized" certificate profiles defined using the IEEE 1609.2 structure. Pseudonym certificates do not contain long-term static identity information that can be linked to the certificate owner. Pseudonym certificates are intended to have very short periods of use and are only used for short periods of time to help exclude tracking and correlation threats. Identity and application certificates contain static identification information specific to the certificate owner. These can be used for long periods of time. 1609.2 identity and application certificates look the same (do not contain a link value) and only differ in the way they are generated with a PKI provider. Either can be used to protect UAS broadcast messages.

[0149] IEEE 1609.2 cryptographic signatures utilize strong elliptic curve cryptography, specifically the ECDSA algorithm defined in the National Institute of Standards and Technology (NIST) Federal Information Processing Standard (FIPS) 186-4. Supported elliptic curves include NIST P256 and Brainpool P256. Cryptographic extensions have also been developed to support further internationalization. Cryptographic signatures are defined in an IEEE 1609.2 Abstract Syntax Notation One (ASN.1) structure called SignedData. The length of an embedded European Conference on Software Architecture (ECSA) 1609.2 signature is 64 bytes. According to 1609.2, a signature can be performed on 1) an arbitrary signed SignedData Payload or 2) on a SHA-256 hash of arbitrary external data [HashedData]. The former must be used when applying 1609.2 to authenticate an ASTM message or message set.

[0150] In block 606, the processor can issue the signed beacon type message in one or more broadcast transmissions from the device. Broadcasting the signed beacon type message can enable one-to-many delivery of the signed beacon type message. In various embodiments, the issuance of the signed beacon type message can be periodic, such as every second, every ten seconds, etc. In various embodiments, issuing the signed beacon type message in one or more broadcast transmissions from the device can include issuing the signed beacon type message in multiple broadcast pages or broadcast frames from the device, such as in five broadcast pages or broadcast frames from the device (e.g., five Wi-Fi NAN pages, five Bluetooth 5 pages, five Bluetooth 4 pages, etc.).

[0151] Figure 6B is a process flow diagram illustrating a method 650 that can be performed by a processor of a device for providing broadcast communication security. Reference is made to Figures 1-6B , the method 650 can be implemented by a processor, such as 210, 212, 214, 216, 218, 252, 260, of a device, such as a wireless device (e.g., wireless devices 120a-120f, 200, 270, 320, 402, 407a-d) or a base station (e.g., base stations 110a, 350, BRD 290). In some embodiments, the operations of the method 650 can be performed by a processor of a wireless device that is configured to broadcast small size messages, such as messages that are 125 bytes in length or less. As an example, the operations of the method 650 can be performed by a processor of an IoT device, a processor of an autonomous or semi-autonomous vehicle, a processor of a robot, a processor of a roadside infrastructure device, a processor of a UAS, etc. Reference is made to Figures 1-6B , the means for performing each operation of the method 650 can be one or more processors of a device, such as wireless devices 120a-120f, 200, 270, 320, 402, 407a-d, base stations 110a, 350, BRD 290, etc., such as one or more of processors 210, 212, 214, 216, 218, 252, 260, etc. In various embodiments, the operations of the method 650 can be performed in conjunction with the operations of the method 600.

[0152] In block 652, the processor can generate a beacon type message that includes a certificate. The beacon type message can be a second beacon type message and can be similar to the beacon type message discussed with reference to block 602, such as a Bluetooth beacon frame (e.g., a Bluetooth 4 beacon frame, a Bluetooth 5 beacon frame, a Bluetooth 5 extended advertising frame, etc.), a Wi-Fi beacon frame (e.g., a Wi-Fi NAN service discovery frame, etc.), a Zigbee beacon frame, an ASTM F3411-19 certification message, etc. In some embodiments, the beacon type message generated in block 652 can be unsigned. In some embodiments, the beacon type message generated in block 652 may, for example, be signed by performing the operations of block 604. In various embodiments, the certificate used to generate the signed beacon type message in block 604 can be the certificate included in the beacon type message in block 652.

[0153] In block 654, the processor can emit a beacon type message including the certificate in one or more broadcast transmissions from the device. Broadcasting a beacon type message including the certificate can enable one-to-many delivery of the certificate to other devices. In various embodiments, the emission of the beacon type message including the certificate can be periodic, such as every second, every ten seconds, etc. In various embodiments, the emission of the beacon type message including the certificate in one or more broadcast transmissions from the device can include in multiple broadcast pages or broadcast frames from the device, such as in five broadcast pages or broadcast frames from the device (e.g., five Wi-Fi NAN pages, five Bluetooth 5 pages, five Bluetooth 4 pages, etc.) emitting the signed beacon type message. Emitting the beacon type message including the certificate can provide the certificate of the device directly to other devices. In this way, other devices can receive the certificate regardless of whether the other devices have network connectivity to a core network (e.g., core network 140) and / or a CA server (e.g., CA server 156). In various embodiments, the beacon broadcast of the certificate can be in response to a command or other request received by the device, such as from a ground-based electronic device, signaling on a network, etc. In various embodiments, the beacon type message including the certificate can also include one or more CA certificates and / or trust chain content (or pointers to such trust chain content). In various embodiments, the CA certificates and / or trust chain content can be transmitted by a third party device, such as a cellular base station.

[0154] Figure 6C FIG. 66 is a process flow diagram illustrating a method 660 that can be performed by a processor of a device for providing broadcast communication security. Referring to FIGS. 1-65 and 66, Figures 1-6C The method 660 can be implemented by a processor of a device, such as a wireless device (e.g., wireless devices 120a-120f, 200, 270, 320, 402, 407a-d) or a base station (e.g., base stations 110a, 350, BRD 290), such as processors 210, 212, 214, 216, 218, 252, 260. In some embodiments, the operations of the method 660 can be performed by a processor of a wireless device that is configured to broadcast small size messages, such as messages that are 125 bytes or less in length. As an example, the operations of the method 660 can be performed by a processor of an IoT device, a processor of an autonomous or semi-autonomous vehicle, a processor of a robot, a processor of a roadside infrastructure device, a processor of a UAS, etc. Referring to FIGS. 1-65 and 66, Figures 1-6CThe components for performing each operation of the method 660 can be one or more processors of a device (e.g., wireless devices 120a-120f, 200, 270, 320, 402, 407a-d, base stations 110a, 350, BRD 290, etc.), such as one or more of processors 210, 212, 214, 216, 218, 252, 260, etc. In various embodiments, the operations of the method 660 can be performed in conjunction with the operations of the methods 600 and / or 650.

[0155] In block 662, the processor can generate an unsigned beacon type message that points to the signed beacon type message. The unsigned beacon type message can be a beacon message that is emitted in a first channel that points to other beacon type messages that are broadcast in a different second channel. For example, the unsigned beacon type message can be a Bluetooth 5 beacon that points to an extended frame (e.g., up to 255 bytes) using Bluetooth 5 advertising extensions. As another example, the unsigned beacon type message can be a Wi-Fi NAN beacon that points to a message packet or set of messages that are emitted in another channel.

[0156] In block 664, the processor can emit the unsigned beacon type message in one or more broadcast transmissions on a channel that is different from the channel of the one or more broadcast transmissions of the signed beacon type message. In this way, the unsigned beacon type message that includes the pointer can be emitted in a different channel than the signed beacon type message broadcast in block 606. Another device that receives the unsigned beacon type message that includes the pointer can listen to the other channel indicated in the pointer to receive the signed beacon type message.

[0157] Figure 7A is a block diagram illustrating broadcast transmissions of beacon type messages according to various embodiments. Referring to Figures 1-7A Broadcasts of beacon type messages (e.g., Bluetooth 4 frames, Bluetooth 5 frames, Wi-Fi NAN frames, etc.) according to the operations of the methods 600, 650, and / or 660 are shown as Figure 7A indicated in FIGS. 6A-6D. Figure 7A Wireless device 402 is shown broadcasting a signed beacon type message 702. The signed beacon type message 702 can include cryptographic overhead 710, such as SignedData referenced in IEEE 1609.2, which serves as a signature for the beacon type message 702. The beacon type message 704 can be broadcast by the wireless device 402 and can include a certificate 712. In some embodiments, the beacon type message 706 carrying the certificate 712 can also include the cryptographic overhead 710.

[0158] Figure 7B is a block diagram illustrating broadcast transmissions of beacon type messages according to various embodiments. Referring toFigures 1-7B Broadcasts of beacon type messages (e.g., Bluetooth 4 frames, Bluetooth 5 frames, Wi-Fi NAN frames, etc.) in accordance with the operations of the methods 600, 650, and / or 660 are shown in Figure 7B Figure 7B It is shown that the wireless device 402 can segment the certificate signed data 720 (e.g., data of the message and cryptographic overhead 710 to sign the message data) across multiple beacon type messages 730, 731, 732, 733, such as across multiple frames or pages (e.g., Bluetooth frames or pages, Wi-Fi frames or pages, etc.). Figure 7B It is shown that the wireless device 402 can segment the certificate 712 across multiple beacon type messages 740, 741, 742, 743, such as across multiple frames or pages (e.g., Bluetooth frames or pages, Wi-Fi frames or pages, etc.).

[0159] Figure 7C is a block diagram illustrating broadcast transmission of beacon type messages in accordance with various embodiments. Reference is made to Figures 1-7C Broadcasts of beacon type messages (e.g., Bluetooth 4 frames, Bluetooth 5 frames, Wi-Fi NAN frames, etc.) in accordance with the operations of the methods 600, 650, and / or 660 are shown in Figure 7C Figure 7C It is shown that the wireless device 402 can emit a beacon type message 750 that includes pointers to other beacon type messages 752, 754, 756 that are broadcast in different channels. Figure 7A It is shown that the wireless device 402 can broadcast a signed beacon type message 752. The signed beacon type message 752 can include cryptographic overhead 710, such as SignedData referenced in IEEE 1609.2, which serves as a signature for the beacon type message 752. The beacon type message 754 can be broadcast by the wireless device 402 and can include the certificate 712. In some embodiments, the beacon type message 756 that carries the certificate 712 can also include the cryptographic overhead 710. As a particular example, the beacon type message 750 can be a Bluetooth 5 beacon that points to extended frames 752, 754, 756 (up to 255 bytes in size) that use Bluetooth 5 advertising extensions.

[0160] Figure 8 is a block diagram illustrating beacon type messages, such as F3411-19 authentication messages 800, in accordance with various embodiments. Reference is made to Figures 1-8 The F3411-19 authentication messages 800 can be beacon type messages that include a device certificate, such as a UAS certificate 804. The UAS certificate 804 can be carried in cryptographic overhead of the message, such as in a P2PCD feature 806 of the message 800.

[0161] ​​In some embodiments, the UAS can periodically broadcast its own certificate 804, peer's or CA certificate, such as using the Peer-to-Peer Certificate Distribution (P2PCD) feature 806 in IEEE 1609.2. The P2PCD feature 806 is designed for disconnected environments where message recipients are unable to validate messages due to missing certificates in their chain of trust. The UAS can use this technique to broadcast its certificate to surrounding devices.

[0162] The period of UAS certificate broadcast can be static, adaptive or responsive. In some embodiments, the UAS can broadcast its certificate every [certBroadcastlnterval] seconds, by generating an Ieee1609dot2Peer2PeerPDU 806 with a content field containing the current UAS certificate, setting the ASTM authentication message AuthType to A (i.e., private use) to indicate a dedicated authentication message used only for communicating the UAS certificate, generating an ASTM authentication message 800, populating its authentication data / signature field (up to 109 bytes) with the Ieee1609dot2Peer2PeerPDU 806, including a timestamp, and broadcasting the authentication message 800. The UAS can only broadcast its currently used certificate, as receivers will typically reject any expired certificate.

[0163] Upon receiving the broadcasted Ieee1609dot2Peer2PeerPDU 806, the broadcast receiver can parse and extract the UAS certificate information 804 from the Ieee1609dot2Peer2PeerPDU 806, cryptographically validate the certificate 804 based on its public key reconstituted value and known CA certificate, and perform a 1604.2 Hashedld8 on the certificate 804 (referred to as certHash). If the certHash is known (i.e., the UAS authorization certificate and public key have been cached), the broadcast receiver can discard the received certHash. Otherwise, the broadcast receiver can cache the certHash and associate it with the public key reconstituted from the certificate 804.

[0164] Given the low flight speed expected in most small UAS, a reasonable default certificate broadcast rate [certBroadcastlnterval] can be on the order of 5 to 10 seconds, but can be configured or adaptive according to regional policies and available technology. The cached certificate can then be used to immediately validate all subsequent broadcast messages from the UAS.

[0165] Figure 9 is a process flow diagram illustrating a method 900 for providing broadcast communication security according to various embodiments. Reference is made to Figures 1-9Method 900 can be implemented by a processor (such as 210, 212, 214, 216, 218, 252, 260) of a device such as a wireless device (e.g., wireless devices 120a-120f, 200, 270, 320, 402, 407a-d) or a base station (e.g., base station 110a, 350, BRD 290). In some embodiments, operation of method 900 can be performed by a processor of a wireless device configured to broadcast small-sized messages, such as messages of 125 bytes or less in length. As an example, operation of method 900 can be performed by a processor of an IoT device, a processor of an autonomous or semi-autonomous vehicle, a processor of a robot, a processor of a roadside infrastructure device, a processor of a UAS, etc. Reference Figures 1-9 The component used to perform each operation of method 900 may be one or more processors of a device (e.g., wireless devices 120a-120f, 200, 270, 320, 402, 407a-d, base station 110a, 350, BRD 290, etc.), such as processors 210, 212, 214, 216, 218, 252, 260, etc. In various embodiments, the operation of method 900 may be performed in conjunction with the operation of methods 600, 650, and / or 660. In various embodiments, the operation of method 900 may be performed in conjunction with the operation of method 600 ( Figure 6A When generating a beacon-type message in box 602, the beacon-type message is at least partially cryptographically signed using a certificate to generate a signed beacon-type message.

[0166] In box 902, the processor can generate a message payload. In some embodiments, the message payload can be a device message. As an example, a device message can be an ASTM message, such as an ASTM F3411-19 message. As a specific example, a device message can be a 25-byte ASTM F3411-19 message. In some embodiments, the message payload can be a hash of other data, or a portion of a hash of other data, such as the least significant sixteen bytes of the hash of other data. Other data can be data within the message, such as the message's timestamp, other messages in the message set, header elements, etc. In some embodiments, the message payload can be an Automatic Dependent Surveillance-Broadcast (ADS-B) message that will be broadcast on a small beacon or service advertisement frame.

[0167] In block 904, the processor may generate a digital signature using at least partially the certificate and the device's private key, the private key corresponding to the public key of the device associated with the certificate. For example, the processor may generate a digital signature based on an IEEE 1609.2 security profile. In some embodiments, the digital signature may be a 64-byte signature or a 32-byte compressed signature.

[0168] In block 906, the processor can generate a certificate identification hash of the certificate. The certificate identification hash of the certificate can be a truncated hash of the certificate that a broadcast receiver uses to look up the full certificate. For example, the certificate identification hash of the certificate can be generated using the HashedID8 function defined in IEEE 1609.2.

[0169] In block 908, the processor can embed the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate a signed beacon type message. In some embodiments, the message payload, the digital signature, and the certificate identification hash can have a combined size of 109 bytes or less. In some embodiments, the embedded message payload, the digital signature, and the certificate identification hash can be an encryption overhead embedded in the beacon type message, thereby signing the beacon type message. As an example, the embedded message payload, the digital signature, and the certificate identification hash can be embedded as IEEE 1609.2 SignedData.

[0170] After generating the signed message, the processor can perform the operations of block 606 of Figure 6A to issue the signed beacon message.

[0171] Figure 10 is a signature profile according to various embodiments. Referring to Figures 1-10 , Figure 10 The signature profile of Figure 10It is shown that to reduce the size of the SignedData element of the signature, only the Provider Service Identifier (PSID) header information element can be included in the signature of the signature. Other IEEE 1609.2 header information elements can be optional and not included to limit the IEEE 1609.2 SignedData element to have a size of 109 bytes or less. Other IEEE 1609. header information elements, such as the generation time, expiration time, generation location, P2PCD request, missing certificate revocation list (CRL) identifier, and / or encryption key can optionally be included in the signature profile, but can result in the size of the IEEE 1609.2 SignedData element to be larger than 109 bytes. In some embodiments, the SignedData element can be larger than 109 bytes, such as 120 bytes or less, 125 bytes or less, etc. In some embodiments, the ASTM message or other type of message can be extended to support secure structures larger than 109 bytes, such as 120 bytes or less, 125 bytes or less, etc. In embodiments where the signed data structure (e.g., IEEE 1609.2 SignedData element, etc.) occupies an extended frame / advertisement type message (e.g., a beacon type message such as 250 bytes, a Bluetooth 5 extended advertisement frame, or a Wi-Fi NAN service discovery frame), the full extended frame / advertisement type message (e.g., full 250 bytes) can be used for both signing the data in the extended frame / advertisement type message and attaching the certificate together.

[0172] Figure 11 is a process flow diagram illustrating a method 1100 for providing broadcast communication security in accordance with various embodiments. Referring to Figures 1-11 , the method 1100 can be implemented by a processor (such as 210, 212, 214, 216, 218, 252, 260) of a device, such as a wireless device (e.g., wireless devices 120a-120f, 200, 270, 320, 402, 407a-d) or a base station (e.g., base stations 110a, 350, BRD 290). In some embodiments, the operations of the method 1100 can be performed by a processor of a wireless device configured to broadcast small size messages, such as messages having a length of 125 bytes or less. As an example, the operations of the method 1100 can be performed by a processor of an IoT device, a processor of an autonomous or semi-autonomous vehicle, a processor of a robot, a processor of a roadside infrastructure device, a processor of a UAS, etc. Referring to Figures 1-11The components for performing each of the operations of method 1100 can be one or more processors of a device (e.g., wireless devices 120a-120f, 200, 270, 320, 402, 407a-d, base stations 110a, 350, BRD 290, etc.), such as one or more of processors 210, 212, 214, 216, 218, 252, 260, etc. In various embodiments, the operations of method 1100 can be performed in conjunction with the operations of methods 600, 650, 660, and / or 900. In various embodiments, the operations of method 1100 can be performed when the message payload is a device message (e.g., an ASTM F3411-19 message, an ADS-B message, etc.) and the message payload is generated in block 902 of method 900 Figure 9

[0173] In some embodiments, the operations of blocks 1102, 1104, 1106, and 1107 can be performed by a processor to generate a digital signature at least in part using a certificate and a private key.

[0174] In block 1102, the processor can determine a signature timestamp. In some embodiments, the signature timestamp can indicate a time of signing of the message. In some embodiments, the signature timestamp can have a size of 4 bytes or up to 8 bytes if included in an IEEE 1609.2 security header.

[0175] In block 1104, the processor can generate a hash of the certificate. In some embodiments, the hash of the certificate can be a hash over the entire certificate, such as a SHA-256 hash digest over the entire certificate.

[0176] In block 1106, the processor can combine the device message, the signature timestamp, and the hash of the certificate to form an authenticated payload. The authenticated payload can be a payload used in a signature profile, such as the IEEE 1609.2 signature profile shown in Figure 10 to generate the digital signature.

[0177] In block 1107, the processor can generate a digital signature at least in part using the cryptographically authenticated payload, the certificate, and the private key. In some embodiments, the digital signature can be generated using a signature profile, such as the signature profile standardized in IEEE 1609.2 and shown in Figure 10 In some embodiments, the digital signature can have a length of 64 bytes, or 32 bytes if compressed.

[0178] ​In block 1108, the processor can select a byte portion of the hash of the certificate as the certificate identification hash. In this way, the processor can generate the certificate identification hash of the certificate. As an example, selecting a byte portion of the certificate hash as the certificate identification hash can include performing a HashedID8 operation to define the 8 least significant bytes of the SHA-256 hash digest over the entire certificate as the certificate identification hash.

[0179] In block 1110, the processor can embed the message payload, the signature timestamp, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message. In some embodiments, the message payload, the signature timestamp, the digital signature, and the certificate identification hash can have a combined size of 125, 109 bytes or less. In some embodiments, the embedded message payload, signature timestamp, digital signature, and certificate identification hash can be cryptographic overhead embedded in the beacon type message, signing the beacon type message. As an example, the embedded message payload, signature timestamp, digital signature, and certificate identification hash can be embedded as IEEE 1609.2 SignedData. In some embodiments, the signature timestamp can be included in the header of the signed beacon message in addition to or instead of in the payload of the signed beacon type message.

[0180] After generating the signed message, the processor can perform the operations of block 606 of FIG. 6 to issue the signed beacon message. Figure 6A

[0181] Figure 12A FIG. 12 is a block diagram illustrating a beacon type message 1200, in accordance with various embodiments. Reference is made to FIG. 11 for purposes of explanation of the beacon type message 1200. Figures 1-12A ​The beacon type message 1200 can be an example ASTM F3411-19 certification message generated according to the operations of the methods 600, 900, and 1100. The timestamp 1212 can be a signed timestamp. The 25-byte message 1208 can be a device message, such as a 25-byte ASTM message. Particular examples of the 25-byte message 1208 can include a basic ID message (type 0x0) for the drone’s identification (e.g., serial number, UUID, etc.) that is limited to 25 bytes; a position / vector message (type 0x1) that provides the drone’s position, velocity, heading, and altitude, also limited to 25 bytes; a self-ID message (type 0x3) that can be a short text describing the drone’s current action, and limited to 25 bytes; a system message (type 0x4) that identifies the operator’s position and / or flight area, and limited to 25 bytes; and / or an operator ID message (type 0x5) that includes the operator’s ID issued by the regulatory authority, and limited to 25 bytes. The IEEE 1609.2 SignedData 1206 can be the encryption overhead for the message 1200 and can include the 25-byte message 1208 and the signature 1210 (e.g., 64-byte signature). The message 1200 can be issued across five pages (pages 0-4) of a broadcast transmission (e.g., five Bluetooth 4 pages, five Bluetooth 5 pages, five Wi-Fi NAN pages, etc.).

[0182] Figure 12B is a block diagram illustrating a beacon type message 1200 and its encoder value 1250 according to various embodiments. Reference is made to Figures 1-12B , Figure 12BFurther shown is the SignerIdentifier 1222, a certificate identification hash (e.g., HashedID8 of the UAS certificate) included with the 25-byte message 1208 (or optionally, an additional certificate) and the signature 1210. IEEE 1609.2 supports additional signature size reduction by omitting the 1609.2 certificate (containing the verification public key or reconstitution value) from the signature and instead appending a hash-based identifier of the certificate. While omission of the certificate is supported, appending the full certificate is also supported. The structure indicating which method is used is provided in the SignedData substructure SignerIdentifier 1222. When the signature certificate is pointed to using its hash, the type of SignerIdentifier 1222 is 'digest' [HashedId8 structure], where HashedId8 is defined as the 8 least significant bytes of a SHA-256 hash digest over the entire certificate. The size of the full 1609.2 SignedData structure using the 1609.2 HashedId8 to identify the signature certificate is approximately 100 bytes. 1609.2 support for ASTM is achieved through the compactness of this structure and its ability to fit the 5-page, 109-byte certification data structure defined in ASTM certification messages or similar message types constructed from multiple pages, each with a length limit of 25 bytes.

[0183] Figure 12C Elements for signed data in beacon-type messages such as message 1200, such as IEEE 1609.2 SignedData 1206, are shown in accordance with various embodiments. Referring to Figures 1-12C , the 125-byte container can include the following fields: AuthType (options are 'none', 'UAS ID signature', 'operator ID signature','message set signature', and 'authentication provided by network remote ID') - 4 bits; page number shown per page (4 bits); page count shown only on page 0 (1 byte); length (1 byte) indicating the length of the contents in the certification data / signature field; timestamp (4 bytes) indicating the time of signature; certification data / signature (109 bytes) indicating all signature-related data providing the IEEE 1609.2 SignedData structure, which fits as Figure 12C The 109-byte constraint of the certification data / signature field shown, or optionally a larger message size if embedded in a native IEEE 1609.2 header.

[0184] In some embodiments, a message 1200 can be generated to support legacy single message authentication using any of Bluetooth 4, Bluetooth 5, and WiFi communication technologies. In such embodiments, the authentication method allows a UAS to authenticate its identity, a UAS operator’s identity, or a single arbitrary 25-byte ASTM message using a 5-page ASTM authentication message or an IEEE 1609.2 SignedData structure independent of ASTM message size constraints. ASTM version 0 legacy mode supports a single authentication message composed of up to 5 pages of 25 bytes that can be broadcast in 25-byte sequences over Bluetooth 4 beacons (legacy) or either of the 250-byte Bluetooth 5 or WiFi NAN protocols. A 125-byte container can include the following fields: AuthType (options are 'none', 'UAS ID signature', 'operator ID signature','message set signature', and 'authentication provided by network remote ID') - 4 bits; page number shown per page (4 bits); page count shown only on page 0 (1 byte); length (1 byte) indicating the length of the contents in the authentication data / signature field; timestamp (4 bytes) indicating the time of the signature; authentication data / signature (109 bytes) indicating all signature-related data provided by method A of the IEEE 1609.2 SignedData structure that fits the 109-byte constraint of the authentication data / signature field. A minimized but complete IEEE 1609.2 SignedData structure with a 25-byte signed payload (e.g., an arbitrary ASTM message) with a 1-byte PSID, SignerIdentifier type of 'digest' can be produced as follows: Figure 12A-C. Thus, using the IEEE 1609.2 method, the UAS can use legacy Bluetooth communication techniques to authenticate any of the 25-byte legacy F3411-19 messages, not just the identity information. When signed using this embodiment, there is no need to issue a dedicated message to authenticate the UAS or its operator (i.e., the Basic ID message or the Operator ID message), as the use of the certificate associated with either identifier type already authenticates both the message signed using the certificate and the identity of the issuer. For example, the IEEE 1609.2 signature of the ASTM position / vector message authenticates both the issuer and the message. In this embodiment, the message signing process can include: generating the ASTM 25-byte message, i.e., the payload; collecting a timestamp and performing a 1609.2 ECDSA signature on {payload + timestamp + cert-hash}, which is the signature; indicating the signer of the 'digest' type according to section 6.3.26 of IEEE 1609.2, generating the Hashedld8 of the certificate according to [1609.2], and filling it into the signer's 'digest' field; filling the signature field with the signature; C-OER encoding the [1609.2] SignedData structure with the resulting binary number put into the ASTM authentication message authentication data / signature field, and including the same timestamp used in the signature; and cryptographically authenticating the resulting authentication message, embedding the ASTM message and the message issuer. The UAS can then broadcast the resulting message over Bluetooth 4, Bluetooth 5 extended advertising, or WiFi NAN, according to ASTM. In a similar embodiment, the native IEEE 1609.2 SignedData structure can form its own authentication message with similar size constraints (i.e., segmented across a small number of 25-byte beacon frames) but independent of the ASTM authentication message fields.

[0185] In this embodiment, in IEEE 1609.2, the inclusion of the certHash in the signature is automatic, which prevents certificate misbinding attacks. Most signature types today do not provide this additional protection.

[0186] Figure 13 FIG. 13 is a process flow diagram illustrating a method 1300 for providing broadcast communication security, in accordance with various embodiments. Reference is made to FIG. 1 for purposes of explanation of the method 1300. Figures 1-13, the method 1300 can be implemented by a processor, such as 210, 212, 214, 216, 218, 252, 260, of a device, such as a wireless device (e.g., wireless devices 120a-120f, 200, 270, 320, 402, 407a-d) or a base station (e.g., base stations 110a, 350, BRD 290). In some embodiments, the operations of the method 1300 can be performed by a processor of a wireless device that is configured to broadcast small size messages, such as messages that are 125 bytes or less in length. By way of example, the operations of the method 1300 can be performed by a processor of an IoT device, a processor of an autonomous or semi-autonomous vehicle, a processor of a robot, a processor of a roadside infrastructure device, a processor of a UAS, etc. Reference is made to Figures 1-13 The means for performing each of the operations of the method 1300 can be one or more processors of a device, such as one or more of the processors 210, 212, 214, 216, 218, 252, 260, of the wireless devices 120a-120f, 200, 270, 320, 402, 407a-d, the base stations 110a, 350, the BRD 290, etc. In various embodiments, the operations of the method 1300 can be performed in conjunction with the operations of the methods 600, 650, 660, and / or 900. In various embodiments, the operations of the method 1300 can be performed to authenticate a set of messages. The operations of the method 1300 can support native ASTM encapsulation using various broadcast technologies, such as Bluetooth 5, Wi-Fi communication technologies, etc. The operations of the method 1300 can be performed when generating a beacon type message in block 602 of the method 600 (FIG. 6).

[0187] In some embodiments, the operations of blocks 1102, 1302, 1304, and 1306 can be performed by a processor to generate a message payload.

[0188] In block 1102, the processor can determine a signature timestamp. For example, the processor can perform operations as discussed with reference to the method 1100( Figure 11 ) to determine a signature timestamp.

[0189] In block 1302, the processor can determine a set of messages of one or more device messages. The set of messages can be a group of messages, such as ASTM messages to be broadcast by a device.

[0190] In block 1304, the processor can generate a hash of a combination of the set of messages and the signature timestamp. For example, the processor can perform a SHA-256 hash of the set of messages and the signature timestamp according to IEEE 1609.2.

[0191] In block 1306, the processor can select a first byte portion of a hash of the combination of the message set and the signature timestamp as the message payload. For example, the Hashedldi6 (the lowest 16 significant bytes of a SHA-256 hash) on the concatenation of the message and the timestamp can be selected as the message payload, or the message payload can be the entire ASTM message package if sent on a service advertisement frame of length up to 250 or 255 bytes.

[0192] In block 1308, the processor can generate a digital signature using at least in part the first byte portion, the certificate, and the private key. For example, the processor can perform an IEEE 1609.2 signature on the message payload to generate an IEEE 1609.2 SignedData structure (using a signer of type 'Digest') as the digital signature.

[0193] In some embodiments, the processor can perform the operations of blocks 1310 and 1312 to generate a certificate identification hash.

[0194] In block 1310, the processor can generate a hash of the certificate. The hash of the certificate can be a SHA-256 hash of the certificate, according to Hashedld8 of IEEE 1609.2.

[0195] In block 1312, the processor can select a second byte portion of the hash of the certificate as the certificate identification hash. The certificate identification hash of the certificate can be a truncated hash of the certificate that a broadcast receiver uses to look up the full certificate. As an example, the certificate identification hash of the certificate can be generated using Hashedld8 of IEEE 1609.2.

[0196] In block 1110, the processor can embed the message payload, the signature timestamp, the digital signature, and the certificate identification hash in the beacon type message to generate a signed beacon type message. For example, the processor can perform operations as discussed with reference to method 1100 Figure 11 ) to embed the message payload, the signature timestamp, the digital signature, and the certificate identification hash in the beacon type message to generate a signed beacon type message.

[0197] After generating the signed message, the processor can perform the operations of block 606 of method 600 Figure 6A to transmit the signed beacon message.

[0198] Figure 14 is a block diagram illustrating a beacon type message 1400, a message set 1423, and a message package 1424, in accordance with various embodiments. Reference is made to Figures 1-14The beacon type message 1400 can be an example ASTM F3411-19 certification message generated according to the operations of the methods 600, 900, 1100, and 1300. The message set 1423 can include a base ID message 1420, a position vector message 1421, and a self-ID message 1422. The timestamp 1412 can be a signed timestamp. The IEEE 1609.2 SignedData 1406 can be the cryptographic overhead of the message 1400 and can include a message payload 1408 that can be a HashedID 16 over a concatenation of the message set 1423 and the timestamp 1412. The IEEE 1609.2 SignedData 1406 can also include a signature 1410 (e.g., a 64-byte signature or a 32-byte compressed signature). The beacon type message 1400 can be issued across a broadcast transmission of five pages (pages 0-4) (e.g., five Bluetooth 5 pages, five Wi-Fi NAN pages, etc.) as part of a message packet 1424 that includes the message set 1423 and the beacon type message 1400.

[0199] In some embodiments, the beacon type message 1400 can be generated by a UAS to certify message sets with native ASTM encapsulation using various communication technologies such as Bluetooth 5, Wi-Fi, etc. communication technologies. In such embodiments, the certification method allows a UAS to certify arbitrary message sets by appending a 5-page ASTM certification message to it. This method allows for the certification of open drone ID message sets by appending an ASTM certification message to one or more ASTM defined broadcast ID messages. A UAS can certify a message as long as the cumulative length of the message along with the appended certification message does not exceed 250 bytes. Alternatively, the pre-existing ASTM messages can be fully contained in the native IEEE 1609.2 SignedData structure and certified without pre-hashing or providing pointers to the pre-existing content to be included in the signature calculation.

[0200] In this embodiment, the flow for a message originator can include: generating an ASTM message set; generating a timestamp for the message set; performing IEEE 1609.2 Hashedldl6 (SHA-256 hashed lowest 16 significant bytes) on the concatenation of the message set and the timestamp (the result is called the payload); performing IEEE 1609.2 signing on the payload to produce an IEEE 1609.2 SignedData structure (using a signer of type 'digest'); placing the signature and header information into the SignedData structure; inserting the COER-encoded SignedData structure into the authentication data / signature field of an ASTM certification message (per ASTM Table 8-9), resulting in a 99-100 byte field (depending on whether a 1-byte or 2-byte PSID is used); placing the COER-encoded SignedData into the authentication data / signature field of an ASTM certification message including the timestamp; and appending the certification message to the message set in a message packet that does not exceed the 250 byte limit. The result is a certified message set, and the completed message packet can be broadcast over Bluetooth 5 extended advertising or Wi-Fi NAN.

[0201] According to this embodiment, a broadcast receiver can verify a message by: parsing and extracting the message set; appending the timestamp obtained from the certification message to the message set; generating a Hashedldl6 on this data (the result is called toBeVerified); determining whether this value is the same as the payload in the SignedData structure, a verification failure; and in response to toBeVerified not being the same as the payload in the SignedData structure, performing a signature verification on the payload using the public key from the cached UAS certificate. If the signature verification succeeds, the message set and the UAS are certified. If toBeVerified is not the same as the payload in the SignedData structure, the verification fails.

[0202] In another embodiment method, the UAS can use Bluetooth 5 or WiFi communication technology to authenticate messages or message packets with full IEEE 1609 encapsulation. In such an embodiment, the authentication method encapsulates the full ASTM message or message packet in its own message type of IEEE 1609.2 SignedData structure and does not use the version 0 ASTM authentication message. This authentication method can use the IEEE 1609.2 security services more broadly and excludes the use of the ASTM authentication message (message 4) and its 109 byte limit on authentication data size. This method will exceed the existing 109 limit at least slightly and thus cannot use Bluetooth 4 communication technology. If constrained to the 109 byte or 125 byte ASTM message and frame size limits, this embodiment can also work over multiple pages of a Bluetooth 4 beacon and embed a single 25 byte ASTM message as the signed payload.

[0203] This embodiment can involve defining an additional message type. By adding a new message type in the ASTM or other standard, Bluetooth 5 extensions and WiFi NAN broadcasts can benefit from using additional IEEE 1609.2 encapsulation, 1609.2 header elements, and associated security capabilities. This method uses 1609.2 SignedData encapsulation of the full ASTM message packet. The proposed message structure can be a variant of the version 0 ASTM message packet message.

[0204] In this embodiment, the process by which the UAS authenticates the broadcast ID message can include: generating an ASTM message or message packet composed of multiple messages (up to six (6)) referred to as AuthenticatedData; generating an IEEE 1609.2 security header that includes one or two bytes of Provider Service Identifier (PSID) and an 8 byte GenerationTime entry, and any additional IEEE 1609.2 header parameters as required by the security profile for the broadcast application, referred to as Headerlnfo; concatenating the SignedDataPayload with the Headerlnfo to generate tbsData; generating an IEEE 1609.2 SignedData structure by performing a 1609.2 signature on tbsData using a private key corresponding to the IEEE 1609.2 public key of the UAS certificate using the signer type 'digest', and indicating which UAS authorization certificate signed this message by indicating its Hashedld 8; and encapsulating the SignedData in Ieee1609Dot2Data (2 byte header).

[0205] The embodiment method will support ASTM message packets of up to six messages (150 bytes) in length and does not use native ASTM certified messages. In addition, the embodiment method utilizes IEEE 1609.2 security services to provide a message generation time (8 bytes), which can help mitigate replay attacks at the receiving application even before the message is received for processing. The embodiment method also provides greater flexibility in using additional security header fields related to generating position, service-specific permissions, etc.

[0206] In this embodiment, a broadcast receiver can validate an IEEE 1609.2-secured message or message packet by extracting the 1609.2 authenticated data from the 1609 SecuredMessagePack message; validating the 1609.2 ECDSA signature; if the signature validation is successful, checking the generation time in the 1609.2 security header for message freshness; extracting the message payload, i.e., the fully qualified ASTM message packet (or message); and parsing and processing the ASTM message packet.

[0207] Existing PKI definitions, client interfaces, and services that support 1609.2 are now available for UAS broadcast IDs. The client interface for the PKI is defined in IEEE 1609.2.1. For any UAS to operate securely in the National Airspace System, the PKI is the source of trust based on 1609.2 credentials. Based on the architecture defined for the transportation industry, the PKI can include the following nodes: a root CA, which can be the root of trust, self-signed or elector signed credentials, for issuing intermediate CA, registration CA, and other CA credentials within the PKI; a registration CA, which can issue registration credentials to UAS communication modules in the manufacturing environment (or secure warehouse facility); an intermediate CA, which issues other intermediate CAs, misbehavior authorities, registration authorities, and authorization authorities (possible in a specific domain); an authorization CA, which signs and issues authorization certificates for UAS. The authorization certificates can be of the identity type (using static identifiers) or pseudonym type (short-lived certificates without a public linked identifier that links the operator to the UAS); a registration authority (RA), which provides an external interface through which a UAS obtains an authorization certificate from the authorization CA; a misbehavior authority (MA), which is a PKI entity through which the FAA can revoke a UAS registration from its trust relationship in the National Airspace System (NAS).

[0208] In this PKI trust architecture, the UAS can not interact directly with the authorized CA (the entity that issues the certificate for signing the UAS broadcast ID message) and can need to go through a registration authority (RA). The RA can be run by the USS provider, or the USS can have a direct contractual service from the RA. The UAS can connect to the RA directly or via the USS. In the Misbehavior Authority (MA) PKI entity, the FAA can direct (directly or via the USS) that a UAS with a particular serial number, registration certificate, or authorization certificate needs to be revoked. The MA can coordinate the blacklisting of the registration certificate (so that it can no longer get an authorization certificate) and the addition of the UAS to a publicly available Certificate Revocation List (CRL). The MA (or the registration CA, depending on the implementation) can expose an interface to law enforcement that allows discovery of the UAS owner / operator associated with a given certificate (as obtained by a misbehaving UAS that broadcasts its certificate-signed ID / tracking data).

[0209] Activities related to UAS production and supply in the supply chain can include security processes to ensure the security of the deployed ID and tracking functionality. Broadly, supply chain security can include the following processes: onboarding and registering UAS hardware; registering UAS; commissioning UAS; transferring ownership; and revoking UAS.

[0210] Providing trusted UAS ID / tracking communications in the National Airspace System (NAS) can involve the following processes. A chip set hardware manufacturer can provide an encrypted hardware root of trust for the chip into the chip / substrate hardware security module (HSM). All subsequent trust for the chip set is derived from this root of trust. A UAS manufacturer can purchase a chip set or communication module with an integrated chip. The UAS manufacturer integrates the communication module with flight command, control, and communication firmware into the UAS. The UAS manufacturer can authenticate the chip via its root of trust and trust relationship with the chip set manufacturer, assign and install a UAS serial number, and onboard and register the UAS into the SCMS (public key infrastructure). At the end of this stage, the UAS has a serial number and an IEEE 1609.2 registration certificate mapped to or containing that serial number. The UAS owner or operator can later use the registration certificate (e.g., via UAS ground control software) to sign and request an authorization [broadcast ID] certificate from the PKI. The broadcast ID certificate can be short-lived or long-lived, and their embedded identifiers can be constructed cryptographically using a secret or private key value in combination with an encryption function that takes operator and / or UAS identifier information as input.

[0211] The registration certificate (with the UAS serial number) and / or its hash value can be sent to or made available to the FAA. However, the FAA has not yet associated this registration with a particular operator until the operator registers the UAS and communicates the same serial number.

[0212] After purchase, the owner / operator can obtain the UAS from the seller / manufacturer. During FAA registration, the FAA can link the known UAS (serial number) and registration certificate to the registered owner. In this process, the UAS owner / operator can use the FAA registration portal to register the UAS with the FAA, providing the UAS serial number, registration certificate hash, and owner / operator information. The FAA can then look up the registration certificate based on its hash (provided by the manufacturer), confirm that the provided UAS serial number matches the serial number in the stored registration certificate, map the registration certificate (and embedded UAS serial number) to the owner / operator, and provide a registration receipt to the owner / operator. The UAS owner / operator now has the FAA registration receipt that can be used during USS / PKI enrollment to indicate that the owner / operator is entitled to obtain an authorized (broadcast ID) certificate from a PKI certificate provider and to obtain USS identity and tracking services. In some embodiments, the registration receipt can be replaced by utilizing a trusted interface between the FAA and the USS / certification provider through which the registration status of the registration certificate and serial number can be provided to the USS. The USS can additionally provide PKI registration services and provide the authorized certificate upon obtaining the USS services. Otherwise, the UAS operator can obtain the certificate directly from the PKI as a prerequisite to registering with the USS. The USS entity can support both options. Additionally, the UAS owner can add or remove other operators as authorized operators for a given UAS. These operators can obtain unique broadcast ID certificates that associate or bind them to the given UAS.

[0213] The owner / operator can enroll and obtain USS services. Prior to such enrollment, or in conjunction with such enrollment, the UAS can be provided with a UAS broadcast ID certificate from the PKI. The PKI services can be provided to the UAS owner opaquely via the USS. The USS can implement its own PKI registration authority or obtain contracted services from a third-party registration authority.

[0214] Ownership changes can be performed by the UAS owner / operator initiating a'release' of the UAS (allowing its registration certificate and serial number to be associated with a new owner) with the FAA registration portal. A release code (receipt of release) can be provided by the FAA to the old owner / operator. This release is also indicated to the PKI. Once released, the new UAS owner can register the UAS with the FAA and secure her own PKI and USS services. The new owner can then add or remove authorized operators that can obtain unique broadcast ID certificates that individually bind them to the UAS.

[0215] The owner / operator can use the FAA registration portal to request deactivation to permanently deactivate and deregister the UAS. This can be necessary, for example, if the UAS is damaged or otherwise inoperable. In response to such a request, the FAA can disallow the registration certificate and serial number to be associated with a new owner / operator. The FAA can additionally notify the PKI of the 'issuer' of the registration certificate so that it will broadcast a request to blacklist the ID certificate. To ensure that the aviation community no longer trusts the UAS, the PKI can add any of the UAS's unexpired broadcast certificates to a network-published certificate revocation list (CRL).

[0216] Figure 15 FIG. 15 is a process flow diagram illustrating a method 1500 for authenticating a broadcast communication, in accordance with various embodiments. Reference is made to FIGS. 1-14 for context. Figures 1-15 Method 1500 can be implemented by a processor, such as 210, 212, 214, 216, 218, 252, 260, of a device, such as a wireless device (e.g., wireless device 120a-120f, 200, 270, 320, 402, 407a-d) or a base station (e.g., base station 110a, 350, BRD 290). In some embodiments, the operations of method 1500 can be performed by a processor of a wireless device configured to receive small size messages broadcast by another device, such as messages of 125 bytes or less in length. As an example, the operations of method 1500 can be performed by a broadcast receiver device of a law enforcement entity (e.g., a police UE), a broadcast receiver device of an emergency responder, a broadcast receiver device of a military unit, etc. Reference is made to FIGS. 1-14 for context. Figures 1-15 The means for performing each operation of method 1500 can be one or more processors of a device, such as wireless device 120a-120f, 200, 270, 320, 402, 407a-d, base station 110a, 350, BRD 290, etc., such as one or more of processors 210, 212, 214, 216, 218, 252, 260, etc. In various embodiments, the operations of method 1500 can be performed in conjunction with the operations of methods 600, 650, 660, 900, 1100, and / or 1300. In various embodiments, the operations of method 1500 can be performed to authenticate messages originating from a device, such as messages originating from a UAS, an IoT device, a vehicle, a robot, etc.

[0217] In block 1502, the processor can receive a signed beacon type message from a device, the signed beacon type message being cryptographically signed at least in part using a certificate of the device. For example, the signed beacon type message can be a signed beacon type message broadcast by a device (e.g., wireless device 120a-120f, 200, 270, 320, 402, 407a-d, base station 110a, 350, BRD 290, etc.) in block 606 according to the operations of methods 600, 900, 1100, and / or 1300.

[0218] In optional block 1504, the processor can determine an identity of the certificate based at least in part on a certificate identification hash of the certificate. For example, the processor can determine the identity of the certificate using the HashedID8 procedure of IEEE 1609.2.

[0219] In optional block 1506, the processor can retrieve the certificate based on the determined certificate identity. In some embodiments, the certificate can be cached on the broadcast receiver device and can be retrieved from memory of the broadcast receiver device. In some embodiments, the processor can download the certificate from a remote entity such as a CA server (e.g., CA server 156) or other trust establishment entity.

[0220] Blocks 1504 and 1506 can be optional, as in some embodiments the certificate itself can be included in the signed beacon type message.

[0221] In determination block 1506, the processor can determine whether the signed beacon type message is valid based at least in part on the certificate. For example, the processor can use the certificate to perform various cryptographic functions to verify the signed beacon type message, data elements within the signed beacon type message, and / or a signature of the signed beacon type message.

[0222] In response to determining that the signed beacon type message is not valid (i.e., determination block 1508 = "invalid"), the processor can discard the signed beacon type message in block 1510.

[0223] In response to determining that the signed beacon type message is valid (i.e., determination block 1508 = "valid"), the processor can process the signed beacon type message in block 1512. Processing the signed beacon type message can include authenticating the broadcasting device, determining an identity of the broadcasting device, beginning a pairing operation with the broadcasting device, etc.

[0224] In various embodiments, a broadcast receiver can use the certificate hash as an index to the full certificate it received from a previous UAS broadcast or from an out-of-band method (e.g., a network-based authentication service lookup). When disconnected from the network, the UAS certificate can be available to a broadcast receiver that needs its public key to encrypt a broadcast message that verifies the drone. The caching of the certificate hash and the associated certificate public key can enable fast receiver-side signature verification of UAS messages.

[0225] The size of the full 1609.2 SignedData structure that signs the 1609.2 Hashedld8 identity is approximately 100 bytes. The support of 1609.2 by ASTM is enabled by the compactness of this structure and its ability to fit the 5-page, 109-byte authentication data structure defined in the ASTM certification messages.

[0226] Various embodiments can include methods for protecting UAS IDs and tracking broadcasts within the constraints of ASTM. The cryptographic identity can be represented and authenticated in the form of a digital certificate that contains a public key that is vouched for, i.e.,'signed' by a certificate authority. Broadcast receivers can use the public key to verify messages signed by a UAS. Both the issuer and the recipient can trust the certificate authority that generated the UAS certificate. Without the cryptographic binding of a UAS identity to its certificate, the verification of UAS broadcasts is infeasible without network support.

[0227] To enable 1609.2 authentication of messages, a certificate authority trust chain can be deployed in the broadcast receiver or made available to it. A certificate authority trust chain is a structure that indicates one or more certificate authorities and their trust roots. This structure can be published electronically and made available to any entity that needs to trust UAS broadcasts.

[0228] To implement 1609.2 authentication, a UAS can be provisioned with a 1609.2 registration certificate and issued a flight certificate. The UAS will use this certificate to request a flight- available authorization certificate from an approved certificate provider (described in the certificate management service) or a USS that integrates a PKI. The UAS can use this flight certificate to sign its broadcasts. This certificate is defined as the IEEE 1609.2 identity or application certificate (note: the certificate type must be 'implicit' to ensure the compactness of the certificate and its ability to be broadcast within the ASTM message size limit).

[0229] To enable 1609.2 authentication of messages, a broadcast receiver can acquire the UAS certificate so that it can verify signed messages received from a UAS.

[0230] The proposed federal aviation regulations specify three methods of identification that ASTM supports in its Basic ID message (Type 0x0): UAS serial number - in the format of ANSI / CTA-2063-A serial number; Civil Aviation Authority (CAA) issued registration ID; and UTM assigned identifier in the form of 128-bit UUID (16 bytes). The maximum size of these identifiers can be 20 bytes if the ASTM Basic ID message is used.

[0231] If UAS identity can be authenticated and integrity and non-repudiation of all UAS broadcast messages can be maintained and cryptographically bound to a specific UAS, then the basic communication security goals can be facilitated in a disconnected network environment. If these provisions are lacking, any entity can easily tamper with, spoof, or maliciously replay UAS broadcast ID messages.

[0232] Various embodiments include methods of binding broadcast identifier types to 1609.2 UAS certificates, which can include embedding existing, pre-generated identifiers. An additional option defines the UAS UUID as a cryptographic hash (or derivative thereof) of the UAS broadcast certificate.

[0233] In some embodiments, a UAS is identified using its static serial number. In this case, the UAS serial number (or a cryptographic hash or keyed message authentication code over the UAS serial number and operator ID) can populate the certificate id field of the 1609.2 certificate. The UAS certificate profile can include the UAS serial number or related identifier and have a format such as the following: Type: implicit certificate (value reconstructed using public key); certificate id = serial number (length = 16 bytes); 1 byte PSID (Provider Service Identifier); 2 bytes SSP (Service Specific Permissions); and Signer Identifier Type = Hash. The UAS certificate based on the serial number can be static and unchanging and, therefore, should not be used by entities requiring higher privacy. Short-lived identities can be used to enhance privacy and further enhance privacy by rotating the broadcast ID certificate each time the Bluetooth or WiFi MAC address is changed. The period of use of the serial number based 1609.2 certificate identifier can be directly encoded in the 1609.2 certificate; however, regional policies can allow this identifier to be indefinite. Most non-commercial UASs can use this method. The UAS certificate size when embedding the UAS serial number can be 86 bytes.

[0234] In some embodiments, the UAS is identified using a CAA-issued identifier used to populate the certificate id field of the 1609.2 certificate. With this 20-byte identifier embedded, the UAS certificate profile can have the following format: Type: Implicit Certificate (value reconstructed using public key); certificate id = CAA-issued identifier (length = up to 20 bytes); 1 byte PSID (Provider Service Identifier); 2 bytes SSP (Service Specific Permissions); and Signer Identifier Type = Hash. The CAA-issued identifier can be short-term or long-term, and its period of use can be directly encoded in the 1609.2 certificate, as determined by regional policy. With the CAA-issued registration ID embedded, the total size of the UAS certificate can be 90 bytes.

[0235] In some embodiments, the UAS is identified using a short-term UUID similar to a network session ID. The UUID is intended to be short-lived to reduce privacy threats related to tracking of the UAS operator. In some embodiments, the UUID can be cryptographically authenticated by embedding it into the UAS certificate, or constructed from a 128-bit hash-based or message authentication code value using the operator and / or UAS identifier as input. In some embodiments, the UUID can be cryptographically authenticated by defining it as the least significant 16 bytes of a SHA-256 hash of the UAS certificate. Either option can be performed depending on the USS and certificate service business model. The latter option can be simpler and does not require managing both the UUID and the certificate hash to link the UUID to the certificate.

[0236] In embodiments where the UUID is cryptographically authenticated by embedding it into the UAS certificate in conjunction with the operator's certificate request, the USS provides a fresh UUID to an internal or external PKI service. The UUID can be provided with the operator's certificate request generated during flight planning. The PKI can be used to generate the UAS certificate with the UUID provided by the USS and authenticate the certificate. With a 16-byte embedded UUID in this embodiment, the 1609.2 certificate profile can have the following format: Type: Implicit Certificate; certificate id = UUID (16 bytes); 1 byte PSID (Provider Service Identifier); 2 bytes SSP (Service Specific Permissions); and Signer Identifier Type = Hash. The certificate size with the USS-issued ID embedded (option 1) can be 86 bytes.

[0237] In embodiments in which a UUID can be cryptographically authenticated by defining the UUID or session ID as the least significant 8 or 16 bytes of a SHA-256 hash of the UAS certificate, the USS can obtain a short-term UUID by passing a request to the PKI for the operator's UAS certificate and indicating 'no pre-generated UUID.' The PKI can be used to generate a certificate_id with a null value or a code indicating the cryptographic hash function used to derive the UUID from the certificate. In this embodiment, the certificate profile has the following format: Type: implicit certificate; certificate_id = NULL (0 bytes); 1 byte PSID (Provider Service Identifier); 2 bytes SSP (Service Specific Permissions); and a signer identifier type = hash. The UAS certificate size in this embodiment can be at least 72 bytes. This small size is achievable because the UUID (certificate identifier) is not a separate parameter, but rather the result of a one-way function of the certificate itself. The USS can compute the UUID by performing an IEEE 1609.2 Hashedld8 or Hashedldl6 of the UAS certificate, both of which are truncations of the SHA-256 hash of the certificate. This value can be converted to human-readable form within the user interface as desired.

[0238] In various embodiments, a broadcast receiver needs a UAS's broadcast ID certificate to validate messages originating from the UAS. The broadcast receiver can obtain the UAS certificate in various ways. In some embodiments, the broadcast receiver can detect a UAS-signed message broadcast and determine whether the broadcast receiver already has the UAS certificate and can cryptographically validate the message signed with it. This can be performed by checking the Hashedld8 value indicated in the 1609.2 SignedData structure of the received broadcast and determining whether the receiver has cached a UAS authorization certificate pertaining to that value. If the certificate is already cached, no action is needed because the broadcast receiver can use the cached authorization certificate to validate the signature of that broadcast and subsequent broadcasts from the broadcasting UAS. If the certificate is not cached, the broadcast receiver can choose to temporarily store the unvalidated message and validate it once the broadcast receiver obtains the UAS authorization certificate from the UAS's own broadcast. In some embodiments, the UAS can also discard the unvalidated message and only validate subsequent UAS broadcasts once it obtains the UAS certificate.

[0239] When connected to a network, a broadcast receiver can also query an authentication service to 1) obtain a copy of the certificate using the HashedId8 identifier obtained by the receiver from the signed broadcast, or 2) relay the signed message to the service for proxy authentication. Both options can be useful during the flight of a UAS transitioning into and out of a network connection. For example, in some cases of network connectivity, a broadcast receiver may choose to correlate an authenticated UAS broadcast with authentication from an authentication service.

[0240] When the network connection is lost, the broadcast receiver cannot access third-party authentication services and may therefore need to trust the encrypted identity within the UAS in-flight environment. Public keys sent outside of certificates should not be trusted, as they can originate from anywhere and cannot be properly verified outside of a trusted certificate issuance process.

[0241] Various embodiments can be implemented on various IoT devices, with examples in the form of a circuit board for use in the device. Figure 16 As shown in the image. (Reference) Figures 1-16 The IoT device 1600 may include a first SOC 202 (e.g., an SOC-CPU) coupled to a second SOC 204 (e.g., a 5G-capable SOC). The first and second SOCs 202 and 204 may be coupled to internal memory 1606. Additionally, the IoT device 1600 may include or be coupled to an antenna 1604 for transmitting and receiving wireless signals from a cellular transceiver 1608 or within the second SOC 204. The antenna 1604 and transceiver 1608 and / or the second SOC 204 may support communication using various RATs, including NB-IoT, CIoT, GSM, Bluetooth, Wi-Fi, VoLTE, etc.

[0242] The IoT device 1600 may also include a voice codec (CODEC) circuit 1610 that digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes the received voice data packets to generate an analog signal that is provided to a speaker to generate sound, thereby supporting voice or VoLTE calls. Furthermore, one or more of the processors of the first and second SOCs 202, 204, the wireless transceiver 1608, and the CODEC 1610 may include digital signal processor (DSP) circuitry (not shown separately).

[0243] Some IoT devices may include an internal power source, such as a battery 1612 configured to power a SoC and one or more transceivers. Such IoT devices may include a power management component 1616 to manage the charging of the battery 1612.

[0244] Various embodiments (including but not limited to the above references) Figures 1-15The embodiments discussed can also be implemented on any of a variety of commercially available server devices, such as the server 1700 shown in FIG. 17. Figure 17 Referring to FIG. 17, such a server 1700 typically includes a processor 1701 coupled to volatile memory 1702 and a large capacity nonvolatile memory, such as a disk drive 1703. The server 1700 can also include a floppy disc drive 1706 coupled to the processor 1701 or other removable memory reader. The server 1700 can also include one or more network transceivers 1704, such as network access ports, coupled to the processor 1701 for establishing network interface connections with a communication network 1707, such as a local area network coupled to other bulletin board computer and server systems, the Internet, a public switched telephone network, and / or a cellular network (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, 5G, LTE, or any other type of cellular network). Figures 1-17

[0245] Figure 18 is a component block diagram of a wireless device 1800 suitable for use with various embodiments. Referring to FIG. 18, various embodiments can be implemented on a variety of wireless devices 1800 (e.g., wireless devices 120a-120f, 200, 270, 320, 402, 407a-d, 290), an example of which is shown in the form of a smartphone in FIG. 2. The wireless device 1800 can include a first SOC 202 (e.g., SOC-CPU) coupled to a second SOC 204 (e.g., SOC with 5G capability). The first and second SOCs 202, 204 can be coupled to internal memory 1816, a display 1812, and a speaker 1814. Additionally, the wireless device 1800 can include an antenna 1804 for emitting and receiving electromagnetic radiation, which can be connected to a wireless transceiver 266 coupled to one or more processors in the first and / or second SOCs 202, 204. The wireless device 1800 can also include menu selection buttons or rocker switches 1820 for receiving user inputs. Figures 1-18 Figure 18 The wireless device 1800 also includes sound encoding / decoding (CODEC) circuitry 1810 that digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes received sound data packets to generate analog signals that are provided to a speaker to generate sound. Moreover, one or more processors in the first and second SOCs 202, 204, the wireless transceiver 266, and the CODEC 1810 can include digital signal processor (DSP) circuitry (not shown separately).

[0246] The wireless device 1800 also includes sound encoding / decoding (CODEC) circuitry 1810 that digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes received sound data packets to generate analog signals that are provided to a speaker to generate sound. Moreover, one or more processors in the first and second SOCs 202, 204, the wireless transceiver 266, and the CODEC 1810 can include digital signal processor (DSP) circuitry (not shown separately).

[0247] ​​The processors of the IoT device 1600, the server 1700, and the wireless device 1800 can be any programmable microprocessor, microcomputer or one or more multiple processor chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions in the various embodiments described below. In some mobile devices, multiple processors can be provided, such as one processor within the SOC 204 dedicated to wireless communication functions, and another processor within the SOC 202 dedicated to running other applications. Software applications can be stored in memory before they are accessed and loaded into the processor. The processors can include internal memory sufficient to store the application software instructions.

[0248] As used in this application, the terms "component," "module," "system" and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution, configured to perform particular operations or functions. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a wireless device and the wireless device can be referred to as a component. One or more components can reside within a process and / or thread of execution and a component can be localized, co-resident, or distributed across one or more processors or cores. Also, these components can execute from various non-transitory computer readable media having various instructions stored thereon. Components can communicate via local and / or remote processes, function- or procedure-calls, electronic signals, data packets, memory reads / writes, and other known computer, processor, and / or process related communication methods.

[0249] Many different cellular and mobile communication services and standards are available or contemplated in the future, all of which can implement and benefit from the various embodiments. Such services and standards include, for example, Bluetooth, Wi-Fi, Third Generation Partnership Project (3GPP), LTE systems, Third Generation Wireless Mobile Communication Technology (3G), Fourth Generation Wireless Mobile Communication Technology (4G), Fifth Generation Wireless Mobile Communication Technology (5G), and New Generation 3GPP technologies, Global System for Mobile Communications (GSM), Universal Mobile Telecommunication System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020™), Enhanced Data Rates for GSM Evolution (EDGE), Advanced Mobile Phone System (AMPS), IS-136 / TDMA, Evolution-Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Network (WLAN), Wi-Fi Protected Access I and II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN). Each of these technologies involves the transmission and reception of, for example, voice, data, signaling, and / or content messages. It should be understood that any reference to terminology and / or technical details related to a single telecommunication standard or technology is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless explicitly recited in the claims.

[0250] The various embodiments shown and described are provided by way of example only to illustrate various features of the claims. However, the features shown and described in relation to any given embodiment are not necessarily limited to the associated embodiment and can be used or combined with other embodiments shown and described. Moreover, the claims are not intended to be limited by any one example embodiment. For example, one or more of the operations of the methods 600, 650, 660, 900, 1100, 1300, and / or 1500 can replace or be combined with one or more operations of the methods 600, 650, 660, 900, 1100, 1300, and / or 1500, and vice versa.

[0251] Example implementation scenarios are described in the following paragraphs. While some of the example implementation scenarios below are described with respect to example methods, further example implementations can include: the example methods discussed in the following paragraphs being implemented by a device such as a wireless device, a broadcast receiver device, or any other type of device, including a processor configured to perform the operations of the example methods; the example methods discussed in the following paragraphs being implemented by a device such as a wireless device, a broadcast receiver device, or any other type of device, including means for performing the functions of the example methods; and the example methods discussed in the following paragraphs being implemented as a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a device such as a wireless device, a broadcast receiver device, or any other type of device to perform the operations of the example methods.

[0252] Example 1. A method performed by a processor of a device for providing broadcast communication security, comprising: generating a beacon type message; cryptographically signing the beacon type message using at least in part a certificate to generate a signed beacon message; and issuing the signed beacon type message in one or more broadcast transmissions from the device.

[0253] Example 2. The method of example 1, wherein cryptographically signing the beacon type message using at least in part the certificate to generate the signed beacon type message comprises: generating a message payload; generating a digital signature using at least in part the certificate and a private key of the device, the private key corresponding to a public key of the device associated with the certificate; generating a certificate identification hash of the certificate; and embedding the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message.

[0254] Example 3. The method of example 2, wherein: the message payload comprises a device message; generating the digital signature using at least in part the certificate and the private key comprises: determining a signature timestamp; generating a hash of the certificate; combining the device message, the signature timestamp, and the hash of the certificate to form an authenticated payload; and generating the digital signature using at least in part the authenticated payload, the certificate, and the private key; generating the certificate identification hash of the certificate comprises selecting a byte portion of the hash of the certificate as the certificate identification hash; and embedding the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message comprises: embedding the message payload, the signature timestamp, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message.

[0255] Example 4. The method of example 3, wherein the byte portion is: a least significant octet of the hash of the certificate; a most significant octet of the hash of the certificate; a least significant or most significant sixteen octets of the hash of the certificate; a least significant or most significant twenty-four octets of the hash of the certificate; a byte portion less than the hash of the certificate; or a full hash of the certificate.

[0256] Example 5. The method of example 2, wherein: generating the message payload comprises: determining a signing timestamp; determining a single message or a set of messages of the one or more device messages; generating a hash of the combination of the message or set of messages and the signing timestamp; selecting a first byte portion of the hash of the combination of the message or set of messages and the signing timestamp as the message payload; generating the digital signature using at least in part the certificate and the private key comprises: generating the digital signature using at least in part the first byte portion, the certificate, and the private key; generating the certificate identification hash of the certificate comprises: generating a hash of the certificate; and selecting a second byte portion of the hash of the certificate as the certificate identification hash; and embedding the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message comprises: embedding the message payload, the signing timestamp, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message.

[0257] Example 6. The method of example 5, wherein: the first byte portion is a full or partial output of the hash of the combination of the message or set of messages and the signing timestamp; and the second byte portion is a subset or full hash of the certificate.

[0258] Example 7. The method of any of examples 1-6, wherein the signed beacon type message further comprises the certificate.

[0259] Example 8. The method of any of examples 1-6, further comprising: generating a second beacon type message containing the certificate, certificate trust chain information, or certificate revocation information; and issuing the second beacon type message in an additional one or more broadcast transmissions from the device.

[0260] Example 9. The method of any of examples 1-8, wherein the beacon type message is a Bluetooth beacon frame.

[0261] Example 10. The method of example 9, wherein the Bluetooth beacon frame is a Bluetooth 4 beacon frame or a Bluetooth 5 beacon.

[0262] Example 11. The method of any of examples 1-8, wherein the beacon type message is a Wi-Fi beacon frame.

[0263] Example 12. The method of example 11, wherein the Wi-Fi beacon frame is a Wi-Fi Neighbor Awareness Networking (NAN) Service Discovery frame.

[0264] Example 13. The method of any of examples 1-8, further comprising: generating an unsigned beacon type message that points to the signed beacon type message; and issuing the unsigned beacon type message in one or more broadcast transmissions on a channel different from the channel on which the one or more broadcast transmissions of the signed beacon type message are sent.

[0265] Example 14. The method of example 13, wherein the signed beacon type message is a Bluetooth 5 extended advertising frame or a Wi-Fi Neighbor Awareness Networking (NAN) service discovery frame.

[0266] Example 15. The method of any of examples 1-14, wherein the message payload, the digital signature, and the certificate identification hash have a combined size of 109 bytes or less or a combined size of 125 bytes or less.

[0267] Example 16. The method of any of examples 1-15, wherein the signed message payload has a size of 25 bytes.

[0268] Example 17. The method of any of examples 1-16, wherein the device is an Internet of Things (IoT) device, a smartphone, a tablet computer, an autonomous or semi-autonomous vehicle, a robot, or a roadside infrastructure device.

[0269] Example 18. The method of any of examples 1-16, wherein the device is an unmanned aerial system (UAS).

[0270] Example 19. The method of example 18, wherein the device message is an ASTM F3411-19 message.

[0271] Example 20. The method of any of examples 18-19, wherein the signed beacon type message is an ASTM F3411-19 authentication message or an IEEE 1609.2 signed message contained within an ASTM F3411-19 compatible frame.

[0272] Example 21. The method of any of examples 18-21, wherein the bit portion of the certificate hash corresponds to a universally unique identifier (UUID) or a session identifier (session ID) assigned to the UAS, its operator, or a tuple of the UAS and its operator.

[0273] Example 22. The method of example 21, wherein the bit portion is the first or last 64, 96, 100, or 128 bits of the certificate hash.

[0274] Example 23. The method of any of examples 18-22, wherein the certificate includes an embedded permission bit that indicates a type, role, and / or permission of the UAS or its operator.

[0275] Example 24. The method of any of examples 18-23, wherein the signed beacon type message comprises a message consistency indication.

[0276] Example 25. The method of any of examples 1-24, wherein the certificate is an implicit format certificate that does not include a full version of the public key.

[0277] Example 26. The method of example 25, wherein the certificate comprises a public key reconstruction value configured to allow the public key to be reconstructed.

[0278] Example 27. The method of any of examples 1-26, wherein issuing the signed beacon type message in one or more broadcast transmissions from the device comprises transmitting the signed beacon type message in multiple broadcast pages or broadcast frames from the device.

[0279] Example 28. The method of example 27, wherein the multiple broadcast pages or broadcast frames from the device are five broadcast pages or broadcast frames from the device.

[0280] Example 29. A method performed by a processor of a broadcast receiver device for authenticating a broadcast communication, comprising: receiving a signed beacon type message from a device, the signed beacon type message being cryptographically signed at least in part using a certificate of the device; determining whether the signed beacon type message is valid based at least in part on the certificate; in response to determining that the signed beacon type message is valid, processing the signed beacon type message; and in response to determining that the signed beacon type message is invalid, discarding the signed beacon type message.

[0281] Example 30. The method of example 29, wherein the signed beacon type message comprises a certificate identification hash of the certificate, the method further comprising: determining an identity of the certificate based at least in part on the certificate identification hash of the certificate; and retrieving the certificate based on the determined identity of the certificate.

[0282] Example 31. The method of example 30, wherein retrieving the certificate based on the determined identity of the certificate comprises retrieving the certificate from a certificate issuing server remote from the broadcast receiver device.

[0283] Example 32. The method of example 30, wherein retrieving the certificate based on the determined identity of the certificate comprises retrieving the certificate from a memory of the broadcast receiver device.

[0284] Example 33. The method of example 32, wherein the certificate is received from the device in another beacon type message.

[0285] Example 34. The method of any of examples 29-33, wherein: the device is a device according to any of examples 1-28; the signed beacon type message is a signed beacon type message according to any of examples 1-28; the certificate is a certificate according to any of examples 1-28; and / or the certificate identification hash of the certificate is a certificate identification hash of a certificate according to any of examples 1-28.

[0286] Example 35. The method of any of examples 29-34, wherein the broadcast receiver device is a law enforcement broadcast receiver device.

[0287] Example 36. The method of any of examples 29-35, wherein processing the signed beacon type message in response to determining that the signed beacon type message is valid comprises determining, at least in part using the signed beacon type message, an unmanned aircraft vehicle identity and / or an operator identity of the unmanned aircraft vehicle.

[0288] Example 37. The method of example 36, wherein the broadcast identifier is contained within the signing certificate, and the broadcast identifier is an encryption output of a key hash, message authentication code algorithm, or public key signature algorithm using UAS and / or UAS operator identification information as input.

[0289] Example 38. The method of example 37, wherein the key hash, message authentication code algorithm, or public key signature algorithm is repeatedly invoked with a unique counter input and / or non-repeating random number, and each output constitutes another identifier of a short-lived (session ID) broadcast ID certificate associated with the UAS and UAS operator.

[0290] Example 39. The method of example 2 or 34, wherein the message payload is an automatic dependent surveillance-broadcast (ADS-B) message to be broadcast over a small beacon or service advertisement frame.

[0291] The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by one of ordinary skill in the art, the order of operations in the foregoing embodiments can be performed in any order. Words such as "thereafter," "then," "next," etc. are not intended to limit the order of the operations; these words are simply used to guide the reader through the description of the methods. Furthermore, any reference to claim elements in the singular, for example, using the articles "a," "an" or "the" is not

[0292] The various illustrative logical blocks, modules, components, circuits, and algorithm operations described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0293] The hardware used to implement various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field

[0294] In one or more embodiments, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored as one or more instructions or code on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The operations of a method or algorithm disclosed herein can be embodied in a processor-executable software module or processor-executable instructions, which can reside on a non-transitory computer- or processor-readable storage medium. Non-transitory computer- or processor-readable storage media can be any storage media that can be accessed by a computer or a processor. By way of example, and not limitation, such non-transitory computer- or processor-readable storage media can include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes compact discs (CD), laser discs, optical discs, digital versatile discs (DVD), floppy disks and blu-ray discs where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer- and processor-readable media. Additionally, the operations of a method or algorithm can reside in one or any combination of the above memory hardware, which can be incorporated in software or code and / or instructions as a computer program product.

[0295] The foregoing description of disclosed embodiments enables a person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the claims and the principles and novel features disclosed herein.

Claims

1. A method performed by a processor of a device for providing broadcast communication security, comprising: generating a beacon type message; cryptographically signing the beacon type message using at least in part a certificate to generate a signed beacon message, wherein cryptographically signing the beacon type message using at least in part the certificate to generate a signed beacon message comprises: generating a message payload comprising a device message; generating a digital signature using at least in part the certificate and a private key of the device, the private key corresponding to a public key of the device associated with the certificate, wherein generating the digital signature using at least in part the certificate and the private key comprises: generating a hash of the certificate; combining the device message, a determined signature timestamp, and the hash of the certificate to form an authenticated payload; and generating the digital signature using at least in part the authenticated payload, the certificate, and the private key; generating a certificate identification hash of the certificate; and embedding the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message; and issuing the signed beacon type message in one or more broadcast transmissions from the device.

2. The method of claim 1, wherein: generating the certificate identification hash of the certificate comprises: selecting a first byte portion of the hash of the certificate as the certificate identification hash; and embedding the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message comprises: embedding the message payload, the signature timestamp, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message.

3. The method of claim 1, wherein: generating the message payload comprises: determining a signature timestamp; determining a single message or a set of messages of one or more device messages; generating a hash of a combination of the message or set of messages and the signature timestamp; selecting a first byte portion of the hash of the combination of the message or set of messages and the signature timestamp as the message payload; generating the digital signature using at least in part the certificate and the private key comprises: using at least in part the first byte portion as the authenticated payload; generating the certificate identification hash of the certificate comprises: generating a hash of the certificate; and selecting a second byte portion of the hash of the certificate as the certificate identification hash; and embedding the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message comprises: embedding the message payload, the signature timestamp, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message.

4. The method of claim 3, wherein: the first byte portion is a full or partial output of a hash of a combination of the message or message set and the signed timestamp; and the second byte portion is a subset or full hash of the certificate.

5. The method of claim 1, wherein the signed beacon-type message further includes the certificate or the certificate is included in a different signed beacon-type message.

6. The method of claim 1, further comprising: generating a second beacon-type message including the certificate, certificate chain-of-trust information, or certificate revocation information; and issuing the second beacon-type message in one or more broadcast transmissions from the device.

7. The method of claim 1, further comprising: generating an unsigned beacon-type message pointing to the signed beacon-type message; and issuing the unsigned beacon-type message in one or more broadcast transmissions on a different channel than the one or more broadcast transmissions of the signed beacon-type message.

8. The method of claim 7, wherein the signed beacon-type message is a Bluetooth 5 extended advertising frame or a Wi-Fi Neighbor Awareness Networking (NAN) service discovery frame.

9. The method of claim 1, wherein: the device is an unmanned aerial system (UAS); and the device message is an ASTM F3411-19 message.

10. The method of claim 9, wherein the signed beacon-type message is an ASTM F3411-19 authentication message or an IEEE 1609.2 signed message included within an ASTM F3411-19 compatible frame.

11. The method of claim 9, wherein the bit portion of the certificate hash corresponds to a universally unique identifier (UUID) or session identifier (session ID) assigned to the UAS, its operator, or a tuple of the UAS and its operator.

12. The method of claim 11, wherein the bit portion is a first or last 64, 92, 120, or 128 bits of the certificate hash.

13. The method of claim 9, wherein: the certificate includes embedded permission bits indicating a type, role, and / or permissions associated with the UAS or its operator; and the signed beacon-type message includes a message consistency indication.

14. The method of claim 1, wherein the certificate is an implicit format certificate that does not include a full version of the public key.

15. The method of claim 1, wherein the certificate includes a public key reconstruction value configured to allow the public key to be reconstructed.

16. The method of claim 1, wherein the message payload is an automatic dependent surveillance-broadcast (ADS-B) message to be broadcast over a small beacon or service advertising frame.

17. The method of claim 1, wherein issuing the signed beacon type message in one or more broadcast transmissions from the device comprises: issuing the signed beacon-type message in multiple broadcast pages or broadcast frames from the device.

18. A method performed by a processor of a broadcast receiver device for authenticating a broadcast communication, comprising: receive a signed beacon type message from a device, the signed beacon type message being cryptographically signed at least in part using a certificate of the device; retrieve the certificate based at least in part on a certificate identification hash of the certificate, wherein retrieving the certificate comprises retrieving the certificate from a memory of the broadcast receiver device; in response to determining that the signed beacon type message is valid based at least in part on the certificate, process the signed beacon type message; and in response to determining that the signed beacon type message is invalid based at least in part on the certificate, discard the signed beacon type message.

19. The method of claim 18, wherein the certificate is received from the device in another beacon type message.

20. The method of claim 18, wherein processing the signed beacon type message in response to determining that the signed beacon type message is valid comprises: determine a UAV identity or an operator identity of a UAV at least in part using the signed beacon type message.

21. The method of claim 20, wherein a broadcast identifier is contained within the signed certificate and the broadcast identifier is a cryptographic output of a key hash, message authentication code algorithm, or public key signature algorithm.

22. The method of claim 21, wherein the key hash, message authentication code algorithm, or public key signature algorithm is repeatedly invoked with a unique counter input or non-repeating random number, and each output constitutes another identifier of a short-lived broadcast ID certificate associated with a UAV and a UAV operator.

23. A device for providing broadcast communication security, comprising: a processor configured with processor-executable instructions to: generate a beacon type message; cryptographically sign the beacon type message at least in part using a certificate to generate a signed beacon message, wherein cryptographically signing the beacon type message at least in part using the certificate to generate a signed beacon message comprises: generate a message payload comprising a device message; generate a digital signature at least in part using the certificate and a private key of the device, the private key corresponding to a public key of the device associated with the certificate, wherein generating the digital signature at least in part using the certificate and the private key comprises: generate a hash of the certificate; combine the device message, a determined signature timestamp, and the hash of the certificate to form an authenticated payload; and generate the digital signature at least in part using the authenticated payload, the certificate, and the private key; generate a certificate identification hash of the certificate; and embed the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message; and emit the signed beacon type message in one or more broadcast transmissions from the device.

24. The device of claim 23, wherein: the processor is further configured with processor-executable instructions to generate the certificate identification hash of the certificate by selecting a byte portion of the hash of the certificate as the certificate identification hash; and the processor is further configured with processor-executable instructions to generate the certificate identification hash of the certificate by selecting a byte portion of the hash of the certificate as the certificate identification hash; and The processor is further configured with processor-executable instructions to generate the message payload by: determining a signing timestamp; determining a single message or a set of messages of one or more device messages; generating a hash of a combination of the message or set of messages and the signing timestamp; selecting a first byte portion of the hash of the combination of the message or set of messages and the signing timestamp as the message payload; The processor is further configured with processor-executable instructions to generate the digital signature at least partially using the certificate and the private key by: at least partially using the first byte portion as the authenticated payload; The processor is further configured with processor-executable instructions to generate the certificate identification hash of the certificate by: generating a hash of the certificate; and selecting a second byte portion of the hash of the certificate as the certificate identification hash; and The processor is further configured with processor-executable instructions to embed the message payload, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message by: embedding the message payload, the signing timestamp, the digital signature, and the certificate identification hash in the beacon type message to generate the signed beacon type message.

26. The device of claim 25, wherein: the first byte portion is a full or partial output of the hash of the combination of the message or set of messages and the signing timestamp; and the second byte portion is a subset or full hash of the certificate.

27. The device of claim 23, wherein the signed beacon type message further includes the certificate or the certificate is included in a different signed beacon type message.

28. The device of claim 23, wherein the processor is further configured with processor- executable instructions to: generate a second beacon type message including the certificate, certificate chain of trust information, or certificate revocation information; and issue the second beacon type message in one or more broadcast transmissions from the device.

29. The device of claim 23, wherein the processor is further configured with processor- executable instructions to: generate an unsigned beacon type message pointing to the signed beacon type message; and issue the unsigned beacon type message in one or more broadcast transmissions on a channel different from a channel of one or more broadcast transmissions of the signed beacon type message.

30. The device of claim 29, wherein the signed beacon type message is a Bluetooth 5 extended advertising frame or a Wi-Fi Neighbor Awareness Networking (NAN) service discovery frame.

31. The device of claim 23, wherein: the device is an unmanned aerial system (UAS); and the device message is an ASTM F3411-19 message.

32. The device of claim 31, wherein the signed beacon type message is an ASTM F3411-19 authentication message or an IEEE 1609.2 signed message included within an ASTM F3411-19 compatible frame.

33. The device of claim 31, wherein a bit portion of the certificate hash corresponds to a universally unique identifier (UUID) or a session identifier (session ID) assigned to the UAS, its operator, or a tuple of the UAS and its operator.

34. The device of claim 33, wherein the bit portion is a first or last 64, 92, 120, or 128 bits of the certificate hash.

35. The device of claim 31, wherein: the certificate includes embedded permission bits indicating a type, role, and / or permissions associated with a UAS or its operator; and the signed beacon type message includes a message consistency indication.

36. The device of claim 23, wherein the certificate is an implicit format certificate that does not include a full version of the public key.

37. The device of claim 23, wherein the certificate includes a public key reconstruction value configured to allow the public key to be reconstructed.

38. The device of claim 23, wherein the message payload is an automatic dependent surveillance-broadcast (ADS-B) message to be broadcast over a small beacon or service advertising frame.

39. The device of claim 23, wherein the processor is configured with processor- executable instructions to issue the signed beacon type message in one or more broadcast transmissions from the device by issuing the signed beacon type message in multiple broadcast pages or broadcast frames from the device.

40. A broadcast receiver device comprising: a processor configured with processor-executable instructions to: receive a signed beacon type message from a device, the signed beacon type message being cryptographically signed at least in part using a certificate of the device; retrieve the certificate based at least in part on a certificate identification hash of the certificate, wherein retrieving the certificate includes retrieving the certificate from a memory of the broadcast receiver device; in response to determining that the signed beacon type message is valid based at least in part on the certificate, process the signed beacon type message; and in response to determining that the signed beacon type message is invalid based at least in part on the certificate, discard the signed beacon type message.

41. The broadcast receiver device of claim 40, wherein the certificate is received from the device in another beacon type message. ​ 42. The broadcast receiver device of claim 40, wherein the processor is further configured with processor-executable instructions to process the signed beacon type message in response to determining that the signed beacon type message is valid by determining, at least in part using the signed beacon type message, a drone identity or an operator identity of a drone.

43. The broadcast receiver device of claim 42, wherein a broadcast identifier is contained within a signature certificate and the broadcast identifier can be a cryptographic output of a key hash, message authentication code algorithm, or public key signature algorithm.

44. The broadcast receiver device of claim 43, wherein the key hash, message authentication code algorithm, or public key signature algorithm is repeatedly invoked with a unique counter input and / or a non-repeating random number, and each output constitutes another identifier of a short-lived broadcast ID certificate associated with a drone and a drone operator.

Images