Article Figures & Data
Figures
- FIGURE 1
Conceptual diagram of TESLA that demonstrates the delayed-release key secrecy schedule
The right section of the diagram follows the left section in time. The diagonally cross-hashed boxes include information held secret by the Provider. The box recedes each time a hash point is released.
- ALGORITHM 1
Provider Procedures for Single Satellite-Single Frequency Authenticated Message Distribution with TESLA
- ALGORITHM 2
Receiver Procedures for Single Satellite-Single Frequency Authenticated Message Distribution with TESLA
- FIGURE 2
Conceptual diagram depicting an overview of the entire scheme presented in this work
The objects depicted are defined and described in the Sections to follow. Multiple levels of ECDSA authenticate a Hash Path End (indicated as HPE in the diagram). Preimage Hash Points (HP in the diagram) together with HMACs are used to authenticate SBAS messages. Black arrows represent the direction of authentication; blue arrows, hashing operation, and red arrows, HMAC operations. The diagram reads from left-to-right with increasing time of release by the Provider, i.e., items to the right are released later by the Provider than items to the left.
- FIGURE 3
A conceptual diagram of how consecutive MT50 messages relate to each other The colors correspond to a specific Hash Point along the Hash Path. Each MT50 includes the HMACs of the five previous messages and the Hash Point used for the HMACs sent with six earlier messages.
- FIGURE 4
Conceptual diagram of accommodations made by the counter scheme to perturbations in the MT50 schedule
In the diagram, “m” denotes a standard message, and “I” represents an integrity message. Integrity messages that would be sent on a nominal schedule are marked blue and additional integrity messages during an alert are marked in yellow. Note that T ⊘ 6 does not change in the event of an alert message MT50 delay, as shown in red; thus, the Hash Path is preserved.
- ALGORITHM 3
Transmitting Salt SP without additional message with ECDSA
- FIGURE 5
Availability of contour maps from the output of MAAST
No authentication is shown on the left and with authentication is shown on the right. In the authentication case, messages were accepted by the receiver only after authentication. The pie graphs indicate the distribution of the different messages with no authentication (left) and with authentication (right). With authentication, MT51s were sent in 1 of every 6 messages. While our requirement specifies MT51 is to be sent in 1 of every 17 messages (i.e., about 6%), the simulation schedule replaces the remaining MT63s with MT51s. There are some small coverage differences between the figures, including north of Canada at approximately (−130°, 72°).
Tables
Preamble MT Reserved HMAC1 HMAC2 HMAC3 HMAC4 HMAC5 Hash Point Spare CRC 4 6 4 16 16 16 16 16 128 4 24 Note: As per SBAS definitions there are 250 bits per message.
MT51 Bit Allocation Preamble MT Reserved Payload Metadata OTAR Payload Segment CRC 4 6 4 84 128 24 Note: Table 3 describes the metadata which specifies how a receiver should interpret the payload. The Authentication Stack, defined in Section 2.5, is composed of a total 2048 bits and required the receipt of the 16 unique messages to OTAR.
MT51 Payload Metadata Section Bits Value Germane Service Provider ID 5 WAAS, EGNOS, MSBAS, GAGAN, et al. Germane Key Level 2 0 - Spare 1 - ECDSA AES key to decrypt Level 1 ECDSA Public Key 2 - ECDSA Level 2 Public Key 3 - TESLA Hash Path End Hash Point Germane Key Hash 16 Truncated Unsalted 16-bit Hash of Entire Germane Key Germane Key Expiration 32 Absolute GPS time (i.e., seconds since GPS epoch) of Germane Key Expiration Authenticating Key Hash 16 Truncated Unsalted 16-bit Hash of Entire Authenticating Key Payload Type 2 0 - Public Key, AES Decryption Key, or Hash Path End 1 - Authenticating pseudorandom data derived from the Authenticating Key 2 - Spare 3 - Core Constellation Broadcast Ephemerides Authentication Payload Segment Number 4 The ordered segment number of Germane authenticating pseudorandom data Parity Bit 1 Parity bit for a compressed public key Spare 6 Additional features possible discussed in Section 4.1 Sum Total 84 Note: To distinguish the key updated with a specific MT51 and the key used to authenticate that MT51, we call the key associated with the MT51-delivered payload the Germane Key and the key used to authenticate that delivered key the Authenticating Key.
- TABLE 4
List of All Unique MT51s in an example Authentication Stack as defined in Section 2.5
Unique MT51 Number OTAR Payload Segment Content 1 AES-128 Key to decrypt receiver-stored Level-1 ECDSA Public Key 2 ECDSA Level-2 Public Key, Segment 1 3 ECDSA Level-2 Public Key, Segment 2 4 ECDSA Level-1 Signature of ECDSA Level-2 Public Key, Segment 1 5 ECDSA Level-1 Signature of ECDSA Level-2 Public Key, Segment 2 ⋮ ⋮ 11 ECDSA Level-1 Signature of ECDSA Level-2 Public Key, Segment 8 12 TESLA Hash Path End 13 ECDSA Level-2 Signature of TESLA Hash Path End, Segment 1 14 ECDSA Level-2 Signature of TESLA Hash Path End, Segment 2 15 ECDSA Level-2 Signature of TESLA Hash Path End, Segment 3 16 ECDSA Level-2 Signature of TESLA Hash Path End, Segment 4 Note: This set is broadcast repeatedly by the Provider for cold-start receivers. A receiver must receive all of the unique MT51s to initiate authentication.
- TABLE 5
Delineation of the Number of MT51s Required to Complete a Single OTAR for a Specific Key
Key Level Security Level Public Key Length OTAR Bit Requirement MT51s Req. 1 256 512 128 1 2 128 256 1280 10 TESLA 128 128 640 5 Note: Level-1 keys require only the 128-bit AES decryption key, hence a single MT51. Level-2 keys require 256-bit key, and 1024 bits of authenticating pseudorandom data (twice the Level-1 public key length), hence, 1280 bits and 10 MT51s. TESLA Hash Path Ends require 128-bit Hash Point and 512 bits of authenticating pseudorandom data (twice the length of the level-2 public key), hence 640 bits and 5 MT51s. Each unique MT51 is required for OTAR.
- TABLE 6
Bit Allocation for a Specific MT51 to Authenticate a Subset of Ephemerides With a 128-bit Payload.
Metadata, etc HMAC1 HMAC2 HMAC3 HMAC4 HMAC5 HMAC6 HMAC7 HMAC8 CRC 98 16 16 16 16 16 16 16 16 24
Jump to section
Related Articles
Cited By...
- No citing articles found.