]> The Aerospace Corporation

14745 Lee Road Chantilly VA 20151 US michael.h.cole@aero.org https://aerospace.org

The Aerospace Corporation

14745 Lee Road Chantilly VA 20151 US sher.shah@aero.org https://aerospace.org

General Internet Engineering Task Force gps gnss authentication security chimera cbor cose Chips Message Robust Authentication (Chimera) is a technique by which a Global Navigation Satellite System (GNSS) constellation, such as the Global Positioning System (GPS), may provide user equipment (i.e., receivers) with authentication of pseudorange measurements on one or more publicly available (i.e., open) Positioning, Navigation, and Timing (PNT) signals. This specification describes a Fast Channel Chimera Marker Key Package, an efficient data structure for encoding one or more Fast Channel Chimera marker keys and associated metadata with a digital signature over all security relevant parameters. Concise Binary Object Representation (CBOR) Object Signing and Encryption (COSE) is used as the underlying message structure. This specification also describes a streaming network protocol by which Fast Channel Chimera Marker Key Packages may be distributed over the Internet.

Introduction Chimera is a technique by which a Global Navigation Satellite System (GNSS) constellation, such as the Global Positioning System (GPS), may provide authentication of user receivers' pseudorange measurements on one or more publicly available (i.e., open) Position, Navigation, and Timing (PNT) signals. Publicly available GPS and similar PNT signals transmitted on the same frequency are differentiated among each other using repeating bit (chip) patterns that are encoded on top of the carrier waveform (chipping sequences); this pattern is referred to as a pseudo-random noise (PRN) sequence. The repeating PRN sequence serves as the ranging code used by a GPS receiver to estimate the time interval between when the signal was broadcast by the satellite and when it was received (and thereby also the estimated distance); on some signals navigation message data is laid on top of this PRN sequence at a very slow encoding speed. Chimera uses a bit commitment scheme in which a symmetric cipher key is used for a short cryptoperiod to generate markers (i.e. punctures) within the GNSS signal's ranging code, followed by the authenticated public disclosure of the key that was used. Users of Chimera record the observed chipping sequences in a buffer, receive the authenticated Chimera key shortly after the applicable cryptoperiod, calculate the expected Chimera marker locations and values for that timespan, and then compare these expected values against the buffered observed chipping sequences. There are two categories of Chimera service: a slow channel (SC) and a fast channel (FC). A Chimera-capable constellation may provide either service or both services concurrently. In SC Chimera, the marker key is derived from information (such as a key generation key) distributed within the bandwidth-constrained navigation message that is broadcast by the constellation, at a relatively low frequency (on the order of minutes). In FC Chimera, the marker key is distributed out-of-band to network-enabled GNSS receivers more frequently, on the order of seconds, providing more frequent pseudorange authentication event opportunities. This specification focuses on the distribution of FC Chimera keys. This specification describes a Fast Channel Chimera Marker Key Package, an efficient data structure for encoding one or more FC Chimera marker keys and associated metadata with a digital signature over all security relevant parameters. Concise Binary Object Representation (CBOR) Object Signing and Encryption (COSE) is used as the underlying message structure. Chimera is one of the experiments on the Air Force Research Lab Navigation Technology Satellite - 3 (NTS-3) . An adaptation of Chimera is proposed for inclusion in a future GPS civil signal authentication service . In practice, service providers might only enclose one Fast Channel Chimera key, applicable to the most recent complete cryptoperiod across a whole constellation. However, the FC Chimera Marker Key Package format specified in the initial draft of this document is flexible enough to accommodate inclusion of multiple FC Chimera keys and multiple constellations within a single FC Chimera Marker Key Package (i.e., all protected by the same digital signature). This accommodates, for example:

• different FC Chimera keys for different signals (e.g., sets of PRNs on different cryptonets, or a test key for a signal under test)
• inclusion of multiple cryptoperiods-worth of FC Chimera keys (e.g., most recent N keys)
• Chimera keys for multiple constellations, in the case where a signal entity may be tasked with distribution of FC Chimera keys for multiple constellations (e.g., a GNSS core and a GNSS augmentation system operated by the same organization)

specifies CBOR data items used within the FC Chimera Marker Key Package that are potentially useful for other GNSS applications that use GPS Time. specifies the FC Chimera Marker Key Package. The packages are intended to be self-contained so that they may be distributed over any transport protocol. documents a streaming multicast IP network protocol by which FC Chimera Marker Key Packages MAY be distributed over the Internet to an arbitrarily large community of consumers. includes considerations for IANA assignment of values. is reserved for additional security considerations associated with the FC Chimera Marker Key Package and its use with a Chimera-enabled GNSS signal. contains example FC Chimera Marker Key Packages.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Common GNSS CBOR Data Items This section specifies data structures used within the Fast Channel Chimera Marker Key Package that potentially have broader utility for GNSS applications. Assignment of CBOR Tag IDs are proposed in .

GPS Time GPS Time is an epoch-based date/time representation expressed in a format used natively by the Global Positioning System as specified in IS-GPS-200 . GPS Time is encoded as an unsigned integer (Major Type 0), representing a whole number of GPS X1 epochs. GPS Time is also used by PNT services that are based on GPS time, such as Satellite Based Augmentation Systems. Fractions of an X1 epoch are not supported by this time representation. Applicaitons that require finer time granularity may adopt an alternate representation of time or supplement as needed to encode fractions of a X1 epoch (e.g., counting the number of chips into the X1 epoch). The GPS Time value SHALL be formatted as defined in Section 3.3.4 of IS-GPS-200 . The 19 least significant bits are the GPS Time of Week (TOW), a value between 0 and 403,199 inclusive, in which each integer step represents an X1 epoch of 1.5 seconds. The most significant bits contain the full (non-truncated) GPS Week Number. The zero time-point is defined as midnight on the night of January 5, 1980/morning of January 6, 1980 Coordinated Universal Time (UTC). The GPS Time value is 4 bytes long through GPS Week Number 8,191 (2^13 - 1) and is 8 bytes long starting at Week Number 8,192 (within the year 2137), plus one byte for CBOR raw data type and length encoding. For example, (Week Number = 2377, TOW = 403,196 X1 Epochs) is encoded as the 4-byte unsigned integer value 1,246,635,772 (0100101001001_1100010011011111100). The CBOR-encoded byte sequence is 0x1A4A4E26FC, where the first byte indicates Major Type 0 and a value length of 4 bytes (000_11010). Applications MAY choose to encode GPS Time with the GPS Week Number modulo 8,192 (2^13) to ensure GPS Time is represented using no more than a 32-bit integer; applications that choose to perform such Week Number truncation SHOULD document such behavior and account for GPS week number rollover.

GPS Time Span A GPS Time Span represents a specific window of time expressed in GPS Time. A GPS Time Span is constrained to time spans that begin and end on X1 epoch boundaries. Fractions of an X1 epoch are not supported by this timespan representation. A GPS Time Span is a two-element array (Major Type 4). The fields are defined as follows, in order:

• start_time: A GPS Time data item () representing the start of the time span.
• duration: An unsigned integer (Major Type 0) encoding the length of time in the time span, expressed in X1 epochs. The duration SHALL be a positive value. An X1 Epoch is defined as 1.5 seconds (See Section 3.3.4 of IS-GPS-200 ).

For example, the two-element array [1 246 635 772, 8] (which is CBOR-encoded as 0x821A4A4E26FC08) represents an eight X1-epoch (twelve-second) time span starting four X1 epochs (six seconds) before the rollover from GPS WN 2377 to GPS WN 2378, and ending four X1 epochs (six seconds) into GPS WN 2378. This GPS Time Span ends at the beginning of the GPS Time represented by integer value 1,246,756,868 (0100101001010_0000000000000000100).

Fast Channel Chimera Marker Key Package The FC Chimera Marker Key Package SHALL be a COSE_Sign1 structure, as described in . Metadata about the digital signature and payload are enclosed within the COSE header buckets, the payload is the FC Chimera Payload structure defined in , and the signature is calculated over the protected header parameters and payload. The FC Chimera Marker Key Package is structured as a CBOR array consisting of the following four fields, in order:

• protected: As described in
• unprotected: As described in
• payload: As described in in
• signature: As described in

The FC Chimera Marker Key Package MAY be identified with CBOR tag 18 to explicitly indicate it is a COSE_Sign1 structure.

COSE Protected Fields As defined in , the protected bucket is a byte string (bstr) wrapped CBOR map of parameters that are to be protected by the digital signature. The FC Chimera Marker Key Package SHALL include the following parameters within the protected bucket, using the labels and value encoding as defined in :

• alg: The algorithm value SHOULD be a digital signature algorithm defined in the COSE Header Parameters registry . When the public key is distributed using an X.509 certificate, the alg value SHOULD match the Subject Public Key Information within the end entity X.509 signing certificate that is used to generate the signature (See ).
• content type: The content type value SHALL be the CoAP Content Type assigned to the Fast Channel Chimera Payload (See ). The content type encoding SHOULD use the integer representation for efficiency.

COSE Unprotected Fields As defined in , the unprotected bucket is a CBOR map (not bstr wrapped) of parameters that are not protected by the digital signature. These OPTIONAL fields are merely helpful hints to end users and are not security critical fields. The FC Chimera Marker Key Package MAY include the following parameters within the unprotected bucket, using the labels and value encoding as defined in :

• kid: The value SHALL be a bstr representing any number of the least significant bytes of the Subject Key Identifier (SKI) of the X.509 certificate used to sign the FC Chimera Marker Key Package, up to and including the full SKI. (See .) The kid value SHALL NOT be a zero-length byte string. If the generator of the FC Chimera Marker Key Package chooses not to include the kid as an indicator of the certificate used, the kid field SHALL be omitted.

These OPTIONAL fields SHALL NOT be enclosed within the protected bucket. This allows for users to strip out these optional fields for redistribution bandwidth or storage efficiency while preserving the validity of the digital signature. This also allows for compatibility in the case where the same public key is issued within multiple valid certificates, as may be the case if a user organization issues cross-signed certificates or the issuing certificate authority is migrating to a new CA certificate.

Fast Channel Chimera Payload The Fast Channel Chimera Payload, or more descriptively the Fast Channel Chimera Key Information Payload, is a CBOR array of four fields (major type 4, value of 4). The fields of the array, in order, are:

• version: An unsigned integer (Major Type 0) representing the version of the FC Chimera Payload format in use. Currently only a value of 0 is defined. This number is only intended to be updated if and when a change is made to this specification that is not backwards compatible. For example, assigning meaning to an initially unassigned GNSS ID is generally a backwards compatible change--users that do not recognize a particular GNSS ID can still parse the message and then safely handle that portion of the package as unsupported. An example of a non-backwards compatible change would be a change in how GPS Time is CBOR-encoded.
• timestamp: A GPS Time of when this FC Chimera Payload was generated, immediately before signature generation. (See .)
• fc_configurations: a CBOR array (Major Type 4) of zero or more FC Chimera Configuration objects as defined in . An empty array SHALL be used when no configurations are enclosed. FC Chimera Configuration objects are referenced by the FC Chimera Key Entry objects enclosed within fc_key_entries.
• fc_key_entries: a CBOR array (Major Type 4) of one or more FC Chimera Key Entry objects, as defined in .

A FC Chimera Payload MAY be tagged with the assigned CBOR Tag ID (See ); however, its inclusion is redundant with the required content type within the protected header. The Fast Channel Chimera Payload, with or without tagging, is wrapped in a bstr in accordance with the COSE specification. GPS Time is used for the overall message timestamp in the initial publication of this specification to avoid potential confusion of using both POSIX and GPS Time in the same message, and also to avoid time zone ambiguity. The time format used for cryptoperiods depends on the identified GNSS ID within the Fast Channel Chimera Key Entry; however, for the initial publication, only the cryptoperiod format based on GPS Time is defined. The FC Chimera Payload's timestamp is the GPS Time of the payload's generation immediately prior to signing, regardless of the cryptoperiods of the enclosed Key Entries. An operational implementation SHOULD only enclose FC Chimera keys for cryptoperiods ending no later than the payload's timestamp (nominally ending in the recent past). In the case of NTS-3 , the simulated time for the NTS-3 Chimera experiment MAY be well into the past, whereas the payload timestamp SHOULD reflect live GPS Time.

Fast Channel Chimera Key Entry The FC Chimera Key Entry object contains a specific FC Chimera key and its associated metadata. The FC Chimera Key Entry object is a CBOR array of six fields (major type of 4, value of 6). The fields, in order, are:

• gnss_ids: An integer or array of integers identifying which GNSS system or systems this key applies to, as described in .
• fc_service_status: An unsigned integer indicating the service's status, as described in .
• fc_cryptoperiod: The cryptoperiod of enclosed key, as described in .
• fc_marker_alg: An unsigned or negative integer indicating the cryptographic algorithm used with this key to derive the Chimera marker information, as described in .
• fc_marker_key_value: A byte string (Major Type 4) containing the value of the Chimera maker key, as described in .
• fc_configuration_indices: An array of unsigned integers indicating which set of signals this key applies to, as described further in .

GNSS IDs One or more unique GNSS IDs associated with this Key Entry. A single GNSS ID SHALL be encoded as an unsigned or negative integer. Multiple GNSS IDs SHALL be encoded an array of integers. See for a list of GNSS ID values and their definitions. All other GNSS ID values are unassigned and may be defined in a future revision. Although not a strict requirement, it is intended for positive GNSS ID value assignments in this specification to align with those defined in for the Integrity Support Message Packet to the extent possible. Fast Channel Chimera Cryptoperiod and Configuration Formats by GNSS ID

GNSS ID	GNSS Name	FC Chimera Cryptoperiod Format	FC Chimera Configuration Format
-24	NTS-3		GPS FC Chimera Configuration
0	Reserved for Test	Unspecified	Unspecified
4	GPS		GPS FC Chimera Configuration

Fast Channel Chimera Service Status Fast Channel Chimera service statuses are defined in . Fast Channel Chimera Service Status Definitions

Value	Name	Description of Status
0	Unavailable	The Fast Channel Service for this GNSS ID is not available for the identified cryptoperiod. Use of this status provides an explicit, authenticated message regarding service unavailability or unsuitability for operational use. Chimera Fast Channel key and configuration information MAY be enclosed; however, consumers SHALL NOT use the enclosed information to authenticate PNT signals.
1	Test	The Fast Channel Service is in a test configuration for the identified GNSS ID. Consumers SHALL NOT use the enclosed information for operational PNT applications.
2	Operational	The Fast Channel Service for this GNSS ID is operational. Consumers SHOULD use the enclosed information for operational PNT applications to authenticate PNT signals, consistent with the signal-specific configuration and status within fc_configurations (See ).

Fast Channel Cryptoperiod The cryptoperiod associated with this key. The representation of cryptoperiod depends on the GNSS Constellation. The defined GNSS IDs for this specification and their respective Cryptoperiod Format are described in . When gnss_ids is an array of multiple GNSS IDs, all enclosed GNSS IDs SHALL use the same fc_cryptoperiod format. For the initial specification, only the GPS Fast Channel Chimera Cryptoperiod is defined. This format is used for GNSS constellations that are based on GPS time. Additional FC Chimera Cryptoperiod objects used by other GNSS constellations may be defined in a future revision of this specification. The GPS Fast Channel Chimera Cryptoperiod is defined as a GPS Time Span (See ). GPS FC Chimera Cryptoperiods always begin and end on GPS X1 epoch boundaries. For NTS-3, Fast Channel Chimera cryptoperiods have a duration of either 1 X1 epoch (1.5 seconds) or 4 X1 epochs (6 seconds), depending on the configuration.

Fast Channel Marker Algorithm An integer identifying the cryptographic algorithm this FC Chimera marker key is to be used with. identifies a list of supported Chimera marker algorithms and their encodings. contains initial assignments for defined Chimera marker cipher algorithms. Individual constellations SHOULD specify which algorithms are supported for their implementation of Fast Channel Chimera markers within their respective interface specifications (along with the plaintext to be used for a given cryptoperiod). Fast Channel Chimera Marker Cipher Algorithms and Modes

Marker Alg ID	Algorithm Name	Key Length (bytes)	References
0	Reserved for Test	Any
1	AES-256 in Electronic Code Book (ECB)	32

The FC Chimera marker generation algorithms supported depends on the GNSS Constellation. The defined GNSS IDs for this specification and their respective supported algorithm(s) are described in . When a GNSS Constellations uses a cipher in Electronic Code Book mode to generate Chimera marker ciphertext, it MUST ensure the uniqueness of the plaintext input for each block of ciphertext generated with the same key. For example, NTS-3 specifies within signal identifier, timestamp, and counter fields in the plaintext input to ensure the uniqueness of each block of marker location and marker value ciphertext.

Fast Channel Marker Key Value A byte string containing either a FC Chimera key of the appropriate length for the indicated algorithm or a zero-length byte string. identifies the key length for each supported marker generation algorithm. A zero-length byte string indicates no key is available for the identified GNSS ID. When the fc_service_status is Unavailable, this field MAY be either zero or of a valid key length, at the implementor's choice.

Fast Channel Chimera Configuration Indices A Key Entry object includes within the fc_configuration_indices field an array of zero or more unique index values into fc_configurations () enclosed earlier in the Payload. FC Configurations are incorporated by reference, and identify which configuration(s) are associated with this key. The fc_configurations field SHALL be populated with at least one element when the fc_service_status is any value other than Unavailable. The fc_configurations array MAY be a zero length array when the fc_service_status is Unavailable. Each referenced FC configuration object SHALL have a GNSS ID value equal to one of the GNSS IDs identified within this Key Entry object's gnss_id. When multiple Configurations are included, the set of individual signals described SHALL be mutually exclusive to avoid ambiguity. For example, for the GPS Configuration format, (GNSS ID=x, with PRN bit y set, Signal Type bit z set) cannot appear in two different configurations referenced within the same Key Entry object.

Fast Channel Chimera Configuration A FC Chimera Configuration object indicates the applicability of a particular key to a set of signals and the fast channel authentication service status for those signals. The FC Chimera Configuration objects are defined within the fc_configurations array near the start of the Payload (), and then referenced by individual FC Chimera Key Entry objects within fc_configuration_indices (). Which FC Chimera Configuration format is used depends on the GNSS ID indicated within the first field of the FC Chimera Configuration object. GNSS ID definitions are defined in . For the initial specification, only a GPS Fast Channel Chimera Configuration format is defined. Additional FC Chimera Configuration formats may be defined in a future revision of this specification.

GPS Fast Channel Chimera Configuration The GPS FC Chimera Configuration object is a CBOR array of six items (major type of 4, value of 6):

• gnss_id: The GNSS ID for this FC configuration object, encoded as a single unsigned or negative integer. See for a list of GNSS ID values and their definitions.
• prn_mask: a byte string. The information enclosed in this GPS FC Configuration applies to all PRNs indicated by the bits set within the prn_mask as described in .
• signal_type_mask: a byte string. The information enclosed in this GPS FC Configuration applies to all signal types identified by the signal_type_mask bits as defined in .
• signal_auth_status: an unsigned integer indicating the status for the identified signals on the identified PRNs as described in .
• duty_factor: an unsigned integer between 1 and 7 inclusive, as defined within the applicable PNT signal in space interface specification.
• additional_fields: a map (major type 5) of zero or more additional field identifier-value pairs as defined in .

GPS PRN Mapping Mappings for the GPS Constellation are defined in . The leftmost bit of the bstr is the MSB (Bit 7) of the first byte (Byte 0) of the bstr. The prn_mask bstr SHALL be encoded using the fewest bytes necessary as described in . GPS PRN Mapping

Byte (0-indexed)	Bit 7 MSB	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0 LSB
0	PRN 1	PRN 2	PRN 3	PRN 4	PRN 6	PRN 6	PRN 7	PRN 8
1	PRN 9	PRN 10	PRN 11	PRN 12	PRN 13	PRN 14	PRN 15	PRN 16
2	PRN 17	PRN 18	PRN 19	PRN 20	PRN 21	PRN 22	PRN 23	PRN 24
3	PRN 25	PRN 26	PRN 27	PRN 28	PRN 29	PRN 30	PRN 31	PRN 32
4	PRN 33	PRN 34	PRN 35	PRN 36	PRN 37	PRN 38	PRN 39	PRN 40
5	PRN 41	PRN 42	PRN 43	PRN 44	PRN 45	PRN 46	PRN 47	PRN 48
6	PRN 49	PRN 50	PRN 51	PRN 52	PRN 53	PRN 54	PRN 55	PRN 56
7	PRN 57	PRN 58	PRN 59	PRN 60	PRN 61	PRN 62	PRN 63	Reserved

GPS Signal Types The mapping of GPS signal types for the GPS FC Chimera Configuration format is defined in . Additional signal types may be added in the future. Assignment of bits in this specification is not intended to imply GPS or any other constellation provides FC Chimera service on those signal types. The signal_types_mask bstr SHALL be encoded using the fewest bytes necessary to indicate set signal types, as described in . For the initial publication of this specification, only one byte has assigned values for bits in this mask. GPS Signal Type Mapping

Byte (0-indexed)	Bit 7 MSB	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0 LSB
0	L1Cp	L2CL	L5Q	L1 C/A	Unas	Unas	Unas	Unas
L1Cp is defined in . L2CL is defined in . L5Q is defined in . L1 C/A is defined in . Unas = Unassigned

GPS Fast Channel Chimera Signal Authentication Status The signal_auth_status (GPS signal authentication status) is defined in . GPS Fast Channel Chimera Signal Authentication Status Definitions

Value	Name	Description of FC Signal Authentication Status
0	Test	FC Chimera is in a test or otherwise non-operational state on the indicated signals. Markers generated by the enclosed key may or may not be present on the indicated signals. Consumers SHALL NOT use the markers on the indicates signals for authentication in operational PNT applications.
1	Unconfirmed	The Fast Channel Markers for the identified PRNs may be present but are not confirmed by the Fast Channel Chimera service as being present and correct/consistent with the enclosed configuration and key. Consumers MAY use the enclosed Key Entry for these signals.
2	Operational	Fast Channel Markers are confirmed to be using the enclosed key and configuration. Consumers SHOULD use the enclosed Key Entry for these signals.
		All other values are unassigned.

GPS Fast Channel Duty Factor The Duty Factor (amount of the signal) punctured with Fast Channel Chimera markers. The Duty Factor enclosed in GPS Fast Channel Chimera Information objects SHALL be a value between 1 and 7. To indicate that a Fast Channel Chimera is not present on a signal (i.e., Duty Factor of zero), that signal instead SHALL NOT be included in the PRN/signal mask.

GPS Fast Channel Configuraiton Additional Fields The additional_fields map optionally contains additional configuraiton parameters, in which the map key is the field_id (a signed or unsigned integer). The additional_fields map is intended for future extensibility. Valid field_id identifiers and their corresponding definitions are enclosed within . GPS Fast Channel Chimera Configuration Additional Fields

field_id	Field Name	Field Definition and Valid Values
No additional fields are defined in this revision.

GPS Bit Mask Encoding The prn_mask and signal_type_mask are encoded using the fewest bytes possible to indicate all set bits. Higher assigned bit values that are all unset are implied. For example:

• A prn_mask in which PRNs 1 through 8 are set is encoded using a one-byte bstr (two bytes total).
• A prn_mask in which PRNs 1 through 31 are set is encoded using a 4-byte bstr (five bytes total).
• A prn_mask in which PRNs 1 through 40 are set is encoded sing a 5-byte bstr (six bytes total).
• A prn_mask in which only PRN 34 is set is encoded using a 5-byte string (six bytes total).

In the examples above, the "total" byte counts include the CBOR overhead byte containing the data type (bstr) and length.

COSE Signature The COSE signature enclosed within a Fast Channel Chimera Marker Key Package is generated as defined in . The signature length is dependent on the signature algorithm used, as identified within the COSE protected header (See ).

IP Network Distribution of FC Chimera Packages Because GNSS usage is ubiquitous, the distribution of FC Chimera packages must scale to support millions of devices. To achieve that, Source Specific Multicast (SSM) UDP/IP packets as defined in are used because they allow for an efficient way to send packets to many systems. The SSM protocol uses a sender and receiver model with the ability for receivers to subscribe to a sender, also known as a multicast group. This one-way communication from a "broadcasting" sender to receivers is aligned with how the FC Chimera protocol operates. The sender sets the destination address to an IP address in the 232.0.0.0/8 range. The receiver then subscribes to and listens for UDP IP packets sent from the server based on the server's source IP address and the multicast group (destination IP address). This specification leaves the destination group (destination multicast IP address) to the service provider's discretion. This allows for multiple FC Chimera key distribution streams with different content and communities of subscribers. For example, different streams could contain test versus operational packages, or different operational streams in which stream contains packages with only the most recent key vs. packages with the most recent N keys). Different streams could also contain the same content, signed using different digital signature algorithms. The source port number is used to indicate the SSM message stream as a GNSS Fast Channel Key Distribution service. A range of port numbers is proposed to accommodate the possibility of a single server source IP address for multiple FC Chimera key distribution streams (see ). If only a single port number is assigned by IANA, multiple source IP addresses MAY be bound to a server to achieve a similar goal. A Fast Channel Chimera key distribution multicast service SHALL use Source Specific Multicast as specified in . A Fast Channel Chimera key distribution multicast service SHALL include exactly one complete Fast Channel Chimera Marker Key Package within each SSM UDP datagram's Data field. This keeps the implementation as simple as possible by avoiding fragmentation of the payload. An operational Fast Channel Chimera key distribution multicast service SHALL use a source port number assigned by IANA, as proposed in . Test services MAY use alternate source ports designated for Experimentation or in the Dynamic Ports range as specified in . Use of a predictable source port assigned to the Fast Channel Chimera key distribution protocol facilitates network security configuration and compliance management such as within firewall rules.

Additional Protocol Requirements and Recommendations The Fast Channel Chimera Marker Key Package provides digitally signed symmetric keys after their period of use for marker generation within the signal in space. The enclosed key(s) are used to verify markers within associated signals implementing Fast Channel Chimera, thereby enabling authentication of pseudorange measurements.

For Consumers Consumers SHALL validate the digital signature before processing enclosed information in the Fast Channel Chimera Marker Key Package, including service status, configuration, and marker keys. Failure to validate prior to use exposes the user to attacks attempting to induce denial of service, insert malformed information into the receiver, or insert illegitimate Chimera keys in used by a PNT signal spoofer. Consumers SHALL confirm the validity of the X.509 certificate used (e.g., for expiration and revocation) and that the subject associated with that X.509 certificate is trusted / suitable as a source for the enclosed GNSS FC Chimera Key Entries. The consumer is responsible for determining which certificates it trusts for a particular Fast Channel Chimera service, and protecting the integrity of its trusted certificate list(s). As a general rule, though, a consumer SHOULD reject a FC Chimera Marker Key Package signed with a certificate only used for Slow Channel Chimera. A consumer SHOULD also reject a FC Chimera Marker Key Package signed using a different constellation service provider's certificate. Enforcing which certificates are trusted for which services limits the user's risk exposure. For example, the compromise of one GNSS provider's Slow Channel private key will not directly impact the Fast Channel service, and the compromise of one provider's certificate chain will not compromise other provider's authentication services. Consumers SHOULD ensure their local device clock is accurate to one half of the Fast Channel Chimera key cryptoperiod or better prior to PNT signal acquisition. For example, if the Fast Channel Chimera cryptoperiod is six seconds, then the local clock should be accurate to +/- 3 seconds or better. This may be achieved through a combination of clock quality, occasional synchronization with alternate authenticated time sources, and operator procedures invoked when performing a cold start. An insufficiently accurate local clock may succumb to a code generation spoofer that uses a revealed Fast Channel Chimera key after its legitimate cryptoperiod and lies about the current time.

For Providers Constellation Service Providers implementing Fast Channel Chimera SHALL publish and clearly identify which certificate(s) are to be used for their respective Fast Channel Chimera service(s). The applicable PNT service(s) and use for Fast Channel Chimera SHOULD be encoded within the X.509 certificate. One possible approach is by encoding the approved use within the Subject Name or a Subject Alternative Name. For example, "primary.fast-signing.gps.gnss.pnt" would identify the certificate as the primary certificate used for GPS Fast Channel Chimera key signing. Encoding this information within the certificate facilitates policy enforcement within GNSS receiver implementations without relying on operator configuration to relate certificates to their applicable constellations and functions.

IANA Considerations This document includes the following requests to Internet Assigned Numbers Authority (IANA): This document requests the assignment of CBOR Tag IDs within the CBOR Tags registry for the following data items: Proposed CBOR Tag IDs

Tag	Data Item	Semantics
65,472 (0xFFC0)	uint or array	GPS Time. See .
65,473 (0xFFC1)	array	GPS Time Span. See .
65,474 (0xFFC2)	array	Fast Channel Chimera Key Payload. See .
65,475 (0xFFC3)	COSE_Sign1	Fast Channel Chimera Marker Key Package. See .

Examples within the initial draft submission of this document use ID values in the experimental range for the CoAP Content Type. Content Type values outside of the experimental range will eventually need to be allocated within the CoAP Content-Formats registry . The experimental CoAP values used in the enclosed examples, and the proposed assignments, are as follows: Experimental CoAP Content-Format IDs

Content Type & Media Type (TBR)	Experimental ID	Proposed ID
application/gnss-fc-chimera-key-payload+cbor	65,474 (0xFFC2)	10,230
application/gnss-fc-chimera-key-package+cose	65,475 (0xFFC3)	10,231

This document requests the assignment of the following within the Service Name and Transport Protocol Port Number Registry : Proposed Service Name and Transport Protocol Port Numbers

Service Name	Port Number	Transport Protocol	Description
gnss-fcchimera	10,230	udp	Global Navigation Satellite System Fast Channel Chimera key distribution (SSM)
gnss-fcchimera2	10,231	udp	Global Navigation Satellite System Fast Channel Chimera key distribution (SSM)
gnss-fcchimera3	10,232	udp	Global Navigation Satellite System Fast Channel Chimera key distribution (SSM)
gnss-fcchimera4	10,233	udp	Global Navigation Satellite System Fast Channel Chimera key distribution (SSM)

Additionally, if this specification were to be promoted to the standards track, there may be merit in managing CBOR-encoded GNSS ID value assignments under the IANA process. The authors propose adoption of CBOR IDs in the range 65,472 (0xFFC0) through 65,534 (0xFFFE) for CBOR data items associated with Global Navigation Satellite Systems. The "prefix" of ten set bits (0b1111_1111_11) is equal to 1023 in decimal, honoring (October 23rd) and the importance of the number 1023 to Position, Navigation, and Timing services. Similarly, the User Port assignment of 10,230 is proposed as the primary source port for streaming multicast of GNSS FC Chimera key packages. 10,230 is a chipping code length used within several GNSS signals, including signals broadcast by GPS, Galileo, and QZSS. Assignment of three additional contiguous port numbers are proposed to accommodate multiple streams broadcast from the same IP address (see ). By the same logic, CoAP content identifiers starting with 10,230 are proposed.

Security Considerations This section does not contain any additional security considerations.

References Normative References Informative References Internet Assigned Numbers Authority Internet Assigned Numbers Authority Internet Assigned Numbers Authority Institute of Navigation United States Government United States Government United States Government United States National Institute of Standards and Technology United States National Institute of Standards and Technology Air Force Research Laboratory Air Force Research Laboratory The Aerospace Corporation The Aerospace Corporation The Aerospace Corporation The Aerospace Corporation

Examples

Test Certificate for Enclosed Examples The following X.509 certificate is used to validate the signatures in the examples below. This test certificate is self-signed and used solely to generate and enable validation of the example digital signatures and, by extension, the construction of the signed message. An operational Fast Channel Chimera service SHOULD use certificates issued by an Issuing Certificate Authority within an appropriate public key infrastructure for the Constellation Service Provider.

Simple Example: One NTS-3 Fast Channel Chimera Key The following is an example Fast Channel Chimera Payload (defined in ) using the First FC Chimera Key in the NTS-3 Test Vector from : The resulting fully assembled Fast Channel Chimera Marker Key Package (defined in ) containing this payload is as follows:

Consecutive NTS-3 Fast Channel Keys The following is an example Fast Channel Chimera Key Payload (defined in ) that includes four NTS-3 Fast Channel Chimera keys with consecutive one X1 epoch long cryptoperiods. In this example, the Configuration Information associated with each Key Entry is the same, but this is not guaranteed for Key Entry objects in the same FC Chimera Package since the signal configuration and monitoring of the signal may change over time. The resulting fully assembled Fast Channel Chimera Marker Key Package (defined in ) containing this payload is as follows:

Complex Example: Two GPS Cryptonets with Multiple Configuration Information Objects The following is an example Fast Channel Chimera Key Payload (defined in ) that includes two cryptoperiods-worth of FC Chimera keys for two constellations: GPS and Other. In this example, the GPS Constellation has two cryptonets: an operational cryptonet used for most PRNs, and a test cryptonet used on one PRN. The Fast Channel service is in a test configuration on the L1C signals, and an operational configuration for L2C and L5. In the earlier cryptoperiod, FC Chimera markers for two of the PRNs are unconfirmed, and they are confirmed in the most current cryptoperiod. The Other constellation is using the test GNSS ID. In this example, the Other constellation adopts the GPS Time, GPS Time Span, and Configuration data structures, with PRN mask assignment and Signal Type mask values that are not defined in this specification. This example might not be a realistic payload for a service provider to generate (e.g., Test keys and associated PRNs may be excluded from an operational key streaming service), but it demonstrates the flexibility of the message format. The resulting fully assembled Fast Channel Chimera Marker Key Package (defined in ) containing this payload is as follows:

Fast Channel Chimera Service Unavailable The following is an example Fast Channel Chimera Key Payload (defined in ) that indicates the FC Chimera Service is unavailable for GPS. In this example, the package timestamp is one X1 epoch after the end of the Cryptoperiod described within the Key Entry object. This demonstrates how the FC Chimera Status is reported on a per-cryptoperiod basis: the Cryptoperiod is always on a Fast Channel Chimera period boundary, regardless of when the FC Chimera Marker Key Package is generated. In this example, the FC Chimera period is 6 seconds (4 X1 epochs). The resulting fully assembled Fast Channel Chimera Marker Key Package (defined in ) containing this payload is as follows:

Acknowledgements The authors would like to acknowledge the United States Federal Aviation Administration and United States Department of Transportation for funding the development of this initial draft specification.

Contributors The authors would like to thank the following individuals for suggested edits that were incorporated into this document:

• Dr. Joseph J. Rushanan (The MITRE Corporation)
• Dr. Yeh-Ching "Brian" Tung (The Aerospace Corporation)
• Dr. James T. Gillis (The Aerospace Corporation)