APPENDIX B

LINKING PROTECTION

TABLE OF CONTENTS

PARAGRAPH PAGE

B.1 GENERAL. 239B.1.1 Scope. 239B.1.2 Applicability. 239B.2 APPLICABLE DOCUMENTS. 239B.2.1 General. 239B.2.2 Government documents. 239B.2.2.1 Specifications, standards, and handbooks. 239B.2.2.2 Other Government documents, drawings, and publications. 240B.3 DEFINITIONS. 240B.3.1 Standard abbreviations and acronyms. 240B.3.2 Definitions of timing signals. 241B.4 GENERAL REQUIREMENTS. 241B.4.1 LP overview. 241B.4.1.1 Linking protection application levels. 243B.4.1.1.1 AL-0. 243B.4.1.1.2 AL-1. 244B.4.1.1.3 AL-2. 244B.4.1.1.4 AL-3. 244B.4.1.1.5 Classified application level AL-4. 244B.4.2 Protocol transparency. 244B.4.3 Transmit processing. 244B.4.4 Receive Processing. 244B.4.5 Time of day (TOD) synchronization. 245B.5 DETAILED REQUIREMENTS 246B.5.1 Linking protection. 246B.5.2 LPCM. 246B.5.2.1 Scrambler interfaces. 246B.5.2.2 TOD. 246B.5.2.2.1 TOD entry. 246B.5.2.2.2 Time exchange protocols. 247B.5.2.3 Seed format. 247B.5.3 Procedure for 2G ALE. 247B.5.3.1. Transmitting station. 249B.5.3.2 Receiving station. 251B.5.3.3 Message sections. 252B.5.3.4 Data block message (DBM) mode. 252B.5.4 Procedure for 3G ALE - not tested (NT). 252B.5.4.1 Encryption of 3G protocol data units (PDU). 252B.5.4.2 Procedure for synchronous-mode 3G ALE. 253B.5.4.3 Procedure for asynchronous-mode 3G ALE. 253B.5.4.3.1 Protected 3G asynchronous-mode scanning call. 253B.5.4.3.2 Protected 3G asynchronous-mode response. 253TABLE OF CONTENTS(continued)PARAGRAPH PAGEB.5.4.4 Protected 3G PI progression. 253B.5.5 Time protocols. 253B.5.5.1 Time exchange word format. 253B.5.5.2 Active time acquisition (protected). 253B.5.5.2.1 Time Request call (protected). 254B.5.5.2.2 Time Service response (protected). 254B.5.5.2.3 Time Server request (protected). 254B.5.5.2.4 Authentication and adjustment (protected). 255B.5.5.3 Active time acquisition (non-protected). 255B.5.5.3.1 Time Request call (non-protected). 255B.5.5.3.2 Time Service response (non-protected). 255B.5.5.3.3 Authentication and adjustment (non-protected mode). 256B.5.5.4 Passive time acquisition (optional). 256B.5.5.5 Time broadcast. 256B.5.5.6 Advanced time distribution protocols. 257B.5.6 The Lattice Algorithm. 257B.5.6.1 Encryption using the Lattice Algorithm. 257B.5.6.2 Decryption using the Lattice Algorithm. 258B.5.6.4 Lattice Algorithm examples. 261B.5.7 The SoDark Algorithm (NT). 264B.5.7.1 Encryption using the SoDark-3 Algorithm. 264B.5.7.2 Decryption using the SoDark-3 Algorithm. 264B.5.7.3 Encryption using the SoDark-6 Algorithm. 265B.5.7.4 Decryption using the SoDark-6 Algorithm. 267

TABLES

TABLE B-I. Encryption table f(Ú). 260TABLE B-II. Decryption table g(Ú). 261

FIGURES

FIGURE B-1. Data link layer with linking protection sublayer. 242FIGURE B-2. Data flow in a protected radio. 243FIGURE B-3. Seed formats. 248FIGURE B-4. Transmitting and receiving stations state diagram. 250FIGURE B-5. Lattice Algorithm schematic diagram (encryption). 259FIGURE B-6. SoDark-3 Algorithm schematic diagram (encryption). 266FIGURE B-7. SoDark-6 Algorithm schematic diagram (encryption). 268

LINKING PROTECTION

B.1 GENERAL.

B.1.1 Scope.

This appendix contains the requirements for the prescribed protocols and directions for the implementation and use of high frequency (HF) automatic link establishment (ALE) radio linking protection.

B.1.2 Applicability.

This appendix is a mandatory part of MIL-STD-188-141 whenever linking protection (LP) is a requirement for the HF radio implementation. The functional capability herein described includes linking protection, linking protection application levels, and timing protocols. The capability for manual operation of the radio in order to conduct communications with existing, older generation, non-automated radios shall not be impaired by implementation of these automated procedures.

B.2 APPLICABLE DOCUMENTS.

B.2.1 General.

The documents listed in this section are specified in B. 3, B. 4, and B. 5 of this standard. This section does not include documents cited in other sections of this standard or recommended for additional information or as examples. While every effort has been made to ensure the completeness of this list, document users are cautioned that they must meet all specified requirements documents cited in B. 3, B. 4, and B. 5 of this standard, whether or not they are listed.

B.2.2 Government documents.

B.2.2.1 Specifications, standards, and handbooks.

The following specifications, standards, and handbooks form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) and supplement thereto.
STANDARDS
FEDERAL
FED-STD-1037 Telecommunications: Glossary of Telecommunication Terms

(Unless otherwise indicated, copies of federal and military specifications, standards, and handbooks are available from the Standardization Document Order Desk, 700 Robbins Avenue, Building #4, Section D, Philadelphia, PA 19111-5094.)

B.2.2.2 Other Government documents, drawings, and publications.

The following other Government documents, drawings, and publications form a part of this document to the extent specified herein. Unless otherwise specified, the issues are those cited in the solicitation.

None.

B.3 DEFINITIONS.

B.3.1 Standard abbreviations and acronyms.

The abbreviations and acronyms used in this document are defined below. Those listed in the current edition of FED-STD-1037 have been included for the convenience of the reader.
2Gsecond generation
3Gthird generation
2G ALEsecond generation automatic link establishment
3G ALEthird generation automatic link establishment
AL-0unprotected application level
AL-1unclassified application level
AL-2unclassified enhanced application level
AL-3unclassified but sensitive application level
AL-4classified application level
ALEautomatic link establishment
AMDautomatic message display
ASCIIAmerican Standard Code for Information Interchange
BW1
CMDALE preamble word COMMAND
CRCcyclic redundancy check
DBMdata block message
DO
DODISSDepartment of Defense Index of Specifications and Standards
DTMdata text message
FECforward error correction
HFhigh frequency
ICDinterface control document
LPlinking protection
LPCMlinking protection control module
msmillisecond
NSANational Security Agency
NTNot Tested
PDU
PIprotection interval
REP
TODtime of day

B.3.2 Definitions of timing signals.

The abbreviations and acronyms used for timing symbols are contained in Annex A to Appendix A.

B.4 GENERAL REQUIREMENTS.

B.4.1 LP overview.

The LP procedures specified herein shall be implemented as distinct functional entities for control functions and bit randomization functions. (Unless otherwise indicated, distinct

hardware for each function is not required.) Figure B-1 shows a conceptual model of the
MIL-STD-188-141 data link layer functions, showing the placement within the data link layer at which LP shall be implemented. The linking protection control module (LPCM) shall perform all control functions specified herein and interface to the ALE controller as shown on figure B-2. Scrambler(s) shall perform all cryptographic operations on ALE words, under the control of the LPCM. Use of LP shall neither increase the time to establish a link compared to the non-protected radio, nor degrade the probability of linking below the standard set for non-protected linking in Appendix A, table A-II. A means shall be provided to disable the LP functions and operate the radio in the clear unprotected application level (AL-0). Hardware scramblers shall be removable without impairment of the unprotected application level functionality of a radio.



FIGURE B-1. Data link layer with linking protection sublayer.


FIGURE B-2. Data flow in a protected radio.

B.4.1.1 Linking protection application levels.

The application levels of LP are defined herein. The classified application level (AL-4), which offers the highest degree of protection, and the unclassified but sensitive application level (AL-3) use National Security Agency (NSA) controlled algorithms described in classified documents. This standard can only make reference to these documents with very little other descriptive material. All protected radios shall be capable of operation at the unclassified application level (AL-1). A means shall be provided to disable automatic linking at linking protection application levels less secure than the application level in use by the station being called. For example, a station which is operating at unclassified enhanced application level (AL-2) shall be able to disable the receiver from listening for linking attempts at unprotected application level (AL-0) and AL-1. (Design objective (DO): Alert the operator but do not link automatically when a valid call is received from a transmitter with a lower linking protection application level.) This mechanism shall not preclude the operator from manually initiating ALE using a disabled application level. This manual override is required for interoperability.

B.4.1.1.1 AL-0.

Assignment of the AL-0 indicates that no linking protection is being employed. No protection is provided against interfering, unintentional, or malicious linking attempts. All protected HF radios shall be capable of operation in the AL-0 mode.

B.4.1.1.2 AL-1.

The AL-1 unclassified application level is mandatory for all protected radio systems, and therefore, provides protected interoperability within the U.S. Government. All protected radios shall be capable of operation in the AL-1 mode even if they also provide application levels with greater protection. The AL-1 scrambler shall employ the lattice encryption algorithm as specified in B.5.6, and may be implemented in hardware or software with manufacturer-specified interfaces. This scrambler is for general U.S. Government and commercial use. The AL-1 protection interval (PI) is 60 seconds, which provides slightly lower protection than any of the other available protected modes but allows for relaxed synchronization requirements.

B.4.1.1.3 AL-2.

The AL-2 scrambler shall employ the same algorithm as specified for the AL-1, and may be implemented in hardware or software, with manufacturer-specific interfaces. This scrambler is for general U.S. Government and commercial use. The AL-2 PI is 2 seconds.

B.4.1.1.4 AL-3.

AL-3 shall use distinct hardware scramblers and shall employ an algorithm and the corresponding interface control document (ICD) developed by the NSA. Systems employing the AL-3 LP shall meet NSA security requirements. The AL-3 PI is a maximum of 2 seconds.

B.4.1.1.5 Classified application level AL-4.

AL-4 shall use distinct hardware scramblers and shall employ an algorithm and the corresponding ICD developed by NSA. An AL-4 scrambler may be used to protect classified orderwire traffic. Systems employing classified application level LP shall meet NSA security requirements. The AL-4 PI is a maximum of 1 second.

B.4.2 Protocol transparency.

A principal consideration in implementing LP is that the presence of an LP module in a radio (or its controller) shall have no impact on any protocols outside of the protection sublayer in the datalink layer. In particular, this means that achieving and maintaining crypto sync shall occur transparently to the ALE waveform and protocols, and that scanning radios shall be able to acquire cypto sync at any point in the scanning call portion of a protected transmission if this transmission was encrypted under the key in use by the receiving station. Thus, LP modules shall not insert sync bits into the data stream, and shall acquire crypto sync without the use of synchronization preambles or message indicator bits.

B.4.3 Transmit processing.

The LP module in a sending station shall encrypt each 24-bit ALE word to be sent using the seed data then in use (frequency, PI number, word number, etc. See B.5.2.3.) and delivers the encrypted word to the FEC module. (Data Block Mode is a special case. See B. 5. 3. 4.)

B.4.4 Receive Processing.

The receiver side of an LP module is responsible for achieving crypto sync with transmitting stations, and for decrypting protected ALE words produced by Golay decoder. In operation, when a scanning receiver arrives at a channel carrying valid tones and timing, the FEC sublayer (majority voter, de-interleaver, and Golay decoder) shall process the output of the ALE modem and alert the LP receive module when an acceptable candidate word has been received. (This occurs roughly once every 8 milliseconds (ms) when the Golay decoders are correcting three errors, or once every 78 ms when correcting one error per Golay word.)

The receive LP module shall then decipher the candidate word, and pass it to the receiving ALE module, which will determine whether word sync has been achieved by checking for acceptable preamble and ASCII subset. This task is complicated by the possibility that the received word (even if properly aligned) may have been encrypted using a different PI than that at the receiver, requiring the receiving LP module to decrypt each candidate word under several seeds.

A further complication is the possibility, though small, that a word may satisfy the preamble and character set checks under multiple seeds. When this occurs, the valid successors to all seeds, which produced valid words, are used to decrypt the next word, and each result is evaluated in the context of the corresponding first word. The probability is vanishingly small that multiple PI possibilities will exist after this second word is checked.

For example, if during a scanning call (or sound), a received word decrypts to ìTO SAMî using seed A, and to ìDATA SNVî using seed B, the next word is decrypted using the successors to those seeds, denoted A´ and B´. If the result of decrypting this next word under A´ is not ìTO SAM,î the first decrypt under seed A was invalid because the word following a TO word in a scanning call must be the same TO word. To be valid in a scanning call or sound, a word following ìDATA SNVî must have three ASCII-38 characters and a THRU, REPEAT, TIS or
TWAS preamble. All valid preamble sequences may be found in Appendix A (table A-VIII).

B.4.5 Time of day (TOD) synchronization.

Because LP employs PIs (which are time-based), all stations must maintain accurate TOD clocks. Practical considerations suggest that station local times may differ by significant fractions of a minute unless some means is employed to maintain tighter synchronization. Because the effectiveness of LP increases as the length of the PI decreases, there is a trade-off between protection and the cost of implementing and using a time synchronization protocol.

The approach taken here is to rely on operators to get station times synchronized to within 1 minute (plus or minus 30 seconds), and then to employ a protocol to synchronize stations to within 1 or 2 seconds (fine sync) for full linking protection. While it is possible to operate networks with only coarse (1 minute) time synchronization, this reduces the protection offered by this system against playback (tape recorder) attacks.

Synchronization of local times for LP requires some cooperation between the protocol entity and the LP time base. For this reason, the LP module, which already has access to the time base for its normal operations, appears to be the logical entity to execute the synchronization protocols, although these protocols are logically at a higher layer in the protocol stack than the LP procedure. In this case, the LP module would need to examine the contents of received transmissions to extract relevant message sections.

If, instead, the synchronization protocols are executed by the ALE entity, the division of function by level of abstraction is cleaner. One concept of how the coordination across the ALE-LP sublayer boundary may be effected in this case is as follows:

a. TOD is maintained by the ALE entity, and is provided to the LP entity as required.

b. The transmit LP entity uses the TOD provided by the transmit ALE entity to form seeds during Tsc and for the initial time setting for Tlc. Thereafter, the TOD from ALE is ignored, and the transmit LP entity sequences seeds in accordance with the state diagram in figure
B-4.

c. On the receive side, seed sequencing is performed by the functions responsible for achieving and maintaining word sync. These functions may be implemented within either the LP or the ALE module, but must know the current phase of the ALE protocol (e.g., Tsc, Tlc, and so on).

d. For authentication of clear mode time exchanges, the ALE module must be able to call upon the LP module to encrypt and decrypt individual ALE words ìoff line.î

B.5 DETAILED REQUIREMENTS

B.5.1 Linking protection.

The following requirements apply to both second generation automatic link establishment (2G ALE) and third generation automatic link establishment (3G ALE) unless otherwise stated.

B.5.2 LPCM.

The LPCM shall execute the LP procedure specified in B.5.3 and control the attached scrambler(s) as specified below.

B.5.2.1 Scrambler interfaces.

The LPCM shall interact with the scrambler(s) in accordance with the circuits and protocols specified in the interface control document (ICD) for each scrambler (see B.4.1.1.4 and B.4.1.1.5). For AL-1, the ICD is prepared and controlled by the manufacturer.

B.5.2.2 TOD.

The LPCM requires accurate time and date for use in the LP procedure. The local time base shall not drift more than ±1 second per day when the station is in operation.

B.5.2.2.1 TOD entry.

A means shall be provided for entry of TOD (date and time) via either an operator interface or an electronic fill port or time receiving port (DO: provide both operator interface and electronic port). This interface should also provide for the entry of the uncertainty of the time entered. If time uncertainty is not provided, a default time uncertainty shall be used. Defaults for the various time fill ports may be separately programmable. Default time uncertainty shall be determined by the procuring agency or manufacturer. Default uncertainty of ± 15 seconds is suggested.

B.5.2.2.2 Time exchange protocols.

After initialization of TOD, the LPCM shall execute the time protocols of B.5.5 as required, to maintain total time uncertainty less than the PI length of the most secure LP mode it is using. The LPCM shall respond to time requests in accordance with B.5.5.3 unless this function is disabled by the operator.

B.5.2.3 Seed format.

The LPCM shall maintain randomization information for use by the scrambler(s), and shall provide this information, or ìseed,î to each scrambler in accordance with the applicable ICD. The 64-bit seed shall contain the frequency, the current PI number, the date, and a word number in the format shown on figure B-3, where the most significant bits of the seed and of each field are on the left. The TOD portion of the seed shall be monotonically non-decreasing. The remaining bits are not so constrained. The date field shall be formatted in accordance with figure B-3. The month field shall contain a 4-bit integer for the current month (1 for January through 12 for December). The day field shall contain a 5-bit integer for the current day of the month (1 through 31). A mechanism shall be provided to accommodate leap years. The PI field shall be formatted in accordance with figure B-3. The coarse time field shall contain an 11-bit integer which counts minutes since midnight (except that temporary discrepancies may occur as discussed in B.5.3). The 6-bit fine time field shall be set to all 1s when time is not known more accurately than within 1 minute (i.e., time quality of six or seven). When a time synchronization protocol (see B.5.5) is employed to obtain more accurate time, the fine time field shall be set to the time obtained using this protocol and incremented as described in B.5.3. The fine time field shall always be a multiple of the PI length, and shall be aligned to PI boundaries (e.g., with a 2-second PI, fine time shall always be even). The word field shall be used to count words within a PI, as specified in B.5.3. The frequency field shall be formatted in accordance with figure B-3. Each 4-bit field shall contain one binary-coded decimal digit of the frequency of the current protected transmission. Regardless of time quality, the fine time field shall be set all 1s for the unclassified application level of LP.

B.5.3 Procedure for 2G ALE.

The procedure to be employed in protecting transmissions consisting entirely of 24-bit ALE words is presented in B.5.3.1 and B.5.3.2. When a radio is neither transmitting nor receiving, the PI number shall be incremented as follows. When using linking protection level AL-2 and local time quality (see Appendix A, A.5.6.4.6) is ì5î or better, the fine time field shall be incremented at the end of each PI by the length of the PI, modulo 60. When the fine time field rolls over to ì0,î the coarse time field shall be incremented, modulo 1440. At midnight, the coarse and fine time fields shall be set to ì0,î and the date and month fields updated. When using linking protection level AL-1, or when the local time quality (see appendix A, A.5.6.4.6) is ì6î or ì7,î the fine time field shall contain all ì1s,î and the coarse time field shall be incremented once per minute, modulo 1440. At midnight, the coarse time field shall be set to ì0î, and the date and month fields updated. Whenever the local time uncertainty is greater than the PI, the system shall:

a. Present an alarm to the operator.

b. Optionally, also attempt resynchronization (if enabled). The first attempt at resynchronization shall use the current fine seed. If this fails, the system shall use a coarse seed for subsequent attempts.


Example Seed

Date=8 May Time=15:57:34 Word=0 Frequency=1755 kHz

a.
9
17
8
2
28
Date
PI
Word
0

0
Frequency
0101 01000
01110111101 100010
00000000
0

0
0000 0000 0001 0111 0101 01010000
1 910 26 27 3437 64


TOD

b. c.
4
5
11
6
Month
Day
Coarse Time
Fine Time
0101
01000
01110111101
100010
1 4
5 9
10 20
21 26
d.
4
4
4
4
4
4
4
100 MHz
10 MHz
1 MHz
100 kHz
10 kHz
1 kHz
100 Hz
0000
0000
0001
0111
0101
0101
0000
37 4041 44 45 4849 52 53 5657 60 61 64

FIGURE B-3. Seed formats.

B.5.3.1. Transmitting station.

Each word to be transmitted shall be encrypted by the scrambler using the current seed information. In the course of a transmission, the protocol described below may cause a discrepancy between the TOD fields in the seed and the real time. Such discrepancy shall be allowed to persist until the conclusion of each transmission, whereupon the TOD fields of the seed shall be corrected. The word number field ìwî shall be as follows:

a. During the scanning call phase (Tsc) of a call, or throughout a sound, the calling stations shall alternate transmission of words encrypted using w = 0 and w = 1. The first word of Tsc shall begin with w = 0 or w = 1, as required, such that the last word of Tsc is encrypted using w = 1. The TOD used during Tsc shall change as required to keep pace with real time, except that TOD shall only change when w = 0. Words encrypted with w = 1 shall use the same TOD as the preceding word.

b. At the beginning of the leading call phase (Tlc) of a call (which is the beginning of a single-channel), the first word shall be encrypted using w = 0 and the correct TOD for the time of transmission of that word.

c. All succeeding words of the call shall use succeeding word numbers up to and including

w = wmax. For the word following a word encrypted with w = wmax, the TOD shall be incremented and w shall be reset to 0.

(1) Wmax = 2 for a 1-second PI.

(2) Wmax = 5 for a 2-second PI.

(3) Wmax = 153 for a 60-second PI.

d. Responses and all succeeding transmissions shall start with w = 0 and the current (corrected) TOD, with these fields incremented as described in paragraph c above for each succeeding word.

Figure B-4 illustrates the permissible TOD with combinations for a transmitting station using a 60 second (wmax=153) and a 2-second PI (wmax = 5), and the permissible sequences of these combinations. Sounds are protected in the same fashion with Trs in place of Tlc.



FIGURE B-4. Transmitting and receiving stations state diagram.



FIGURE B-4. Transmitting and receiving stations state diagram (continued).

B.5.3.2 Receiving station.

Because of the possibility of acceptable decodes under multiple TOD/word number combinations, receivers shall attempt to decode received words under all allowed combinations (the current and adjacent PIs (future and past), and both w = 0 and w = 1) when attempting to achieve word synchronization with a calling station (six combinations). Stations prepared to accept time requests (see B.5.5.2.2) shall also attempt to decode received words using coarse TOD (fine time = all 1s, correct coarse time only) with both w = 0 and w = 1 (eight combinations total). All valid combinations shall be checked while seeking word sync. After achieving word sync, the number of valid combinations is greatly reduced by the link protection

protocol. Figure B-4 illustrates the permissible TOD/w sequences for a receiving station using a 60-second PI and a 2-second PI respectively, after word sync is achieved. Note that unlike the transmitter, the receiving station state machine may be non-deterministic. For example, when in Tsc and in state N/1, a received word may yield valid preambles and ASCII when decrypted using all of the valid combinations: N/0, (N + 1)/0, and N/2 (the latter implying that Tlc started two words previously), and will therefore, be in three states at once until the ambiguity is resolved by evaluating the decrypted words for compliance with the LP and ALE protocols under the valid successor states to these three states. Stations using a PI of 2 seconds or less shall not accept more than one transmission encrypted using a given TOD, and need not check combinations using that TOD. For example, if a call is decrypted using TOD = N, no TOD before N+1 is valid for the acknowledgment.

B.5.3.3 Message sections.

All ALE words shall be protected including message text.

B.5.3.4 Data block message (DBM) mode.

a. A DBM data block contains an integral number of 12-bit words, the last of which comprises the least significant 12 bits of a cyclic redundancy check (CRC). These 12-bit words shall be encrypted in pairs, with the first 12-bit word presented to the LPCM by the ALE protocol module as the more significant of the two. When a data block contains an odd number of 12-bit words (i.e., basic DBM data block and extended DBM data blocks with odd N), the final 12-bit word shall not be encrypted, but shall be passed directly to the FEC sublayer.

b. The word number field ìwî of the seed shall be incremented only after three pairs of
12-bit words have been encrypted (rather than after every 24-bit word as in normal operation), except that the word number ìwî shall be incremented exactly once after the last pair of 12-bit words in a DBM data block is encrypted, whether or not it was the third pair to use that word number. As usual, TOD shall be incremented whenever ìwî rolls over to 0.

B.5.4 Procedure for 3G ALE - not tested (NT).

Linking protection for 3G ALE shall employ the same algorithms, seed format, and procedures as for 2G, except as specified in the following paragraphs. For definitions of terms used here that are specific to 3G ALE, see Appendix C.

B.5.4.1 Encryption of 3G protocol data units (PDU).

The first 2 bits of each 26-bit thrid-generation ALE PDU shall be sent without encrypting. The remaining 24 bits shall be encrypted in the same manner as 24-bit 2G ALE words. AL-1 and AL-2 shall use the SoDark-3 Algorithm (see B.5.7.1 and B.5.7.2) for encrypting 3G ALE PDUs. 3G traffic manager, synchronization manager, and link maintenance PDUs shall be encrypted using the SoDark-6 algorithm (see B.5.7.3 and B.5.7.4).

B.5.4.2 Procedure for synchronous-mode 3G ALE.

When a network is operating in synchronous mode, stations are inherently synchronized to within 50 ms. The protection interval for synchronous mode 3G ALE is therefore the length of one slot (800 ms). The PI field in the seed shall be used as a 17­bit integer rather than as an 11­bit coarse time and a 6­bit fine time field. This 17­bit PI field shall contain the number of 800 ms slots that have elapsed since midnight (network time). The word number field in the seed shall always be 00000000. The date fields shall reflect the current network date. The frequency field shall indicate the frequency on which the protected PDU is sent. Synchronous­mode 3G ALE nodes shall ignore any synchronous­mode Probe PDU (i.e., a Probe PDU that is not preceded by Scanning Call PDUs) which is not encrypted using the current PI number.

B.5.4.3 Procedure for asynchronous-mode 3G ALE.

Asynchronous 3G handshakes shall be protected using the procedure in B.5.3 that has been modified as follows.

B.5.4.3.1 Protected 3G asynchronous-mode scanning call.

The probe PDU that concludes a 3G asynchronous-mode call shall be encrypted using word number = 2. Scanning call PDUs shall be encrypted using alternating word numbers 0 and 1. The word number used in encrypting the first scanning call PDU shall be selected so that the scanning call PDU sent immediately before the probe PDU is encrypted using word number = 1.

B.5.4.3.2 Protected 3G asynchronous-mode response.

The handshake PDU that follows an asynchronous­mode call shall be encrypted using the current TOD with word number = 3.

B.5.4.4 Protected 3G PI progression.

3G ALE nodes shall not accept PDU sequences in which the TOD used to encrypt a PDU is earlier than the TOD used to encrypt a preceding PDU of that sequence.

B.5.5 Time protocols.

The following shall be employed to synchronize LP time bases. The time service protocols for active time acquisition, both protected (B.5.5.2) and non-protected (B.5.5.3), are mandatory for all implementations of LP.

B.5.5.1 Time exchange word format.

See Appendix A, A.5.6.4.3.

B.5.5.2 Active time acquisition (protected).

A station that knows the correct date and time to within 1 minute may attempt to actively acquire time from any station with which it can communicate in protected mode by employing the protocol in the following paragraphs. The quality of time so acquired is necessarily at least one grade more uncertain than that of the selected time server. A station that does not know the correct date and time to within 1 minute may nevertheless employ this protected protocol by repeatedly guessing the time until it successfully communicates with a time server.

B.5.5.2.1 Time Request call (protected).

A station requiring fine time shall request the current value of the network time by transmitting a Time Request call, formatted as follows. (In principle, any station may be asked for the time, but some stations may not be programmed to respond, and others may have poor time quality. Thus, multiple servers may need to be tried before sufficient time quality is achieved.)

TO <time server> CMD Time Is <time> DATA <coarse time>

REP <authenticator> TIS <requester>.

The Time Is command shall be immediately followed by a coarse time word and an authentication word. The authenticator shall be generated by the exclusive-or of the command word and the coarse time word, as specified in Appendix A, A.5.6.4.4. The Time Request call transmission shall be protected using the procedure specified in B.5.3.1 and B.5.3.2. When acquiring time synchronization, the coarse seed (fine time field in the seed set to all 1s) current at the requesting station shall be used. When used to reduce the time uncertainty of a station already in time sync, the current fine seed shall be used.

B.5.5.2.2 Time Service response (protected).

A station which receives and accepts a Time Request call shall respond with a Time Service response formatted as follows:

TO <requester> CMD Time Is <time> DATA <coarse time>

REP <authenticator> TWAS <time server>.

The Time Is command shall be immediately followed by a coarse time word and an authentication word. The authenticator shall be generated by the three-way exclusive-or of the command word and the coarse time word from this transmission and the authentication word (including the REP preamble) from the requester, as specified in Appendix A, A.5.6.4.5. The entire Time Service response shall be protected as specified in B.5.3.1 and B.5.3.2 using the time serverís current coarse seed if the request used a coarse seed, or the current fine seed otherwise. The seed used in protecting a Time Service response may differ from that used in the request that caused the response. A time server shall respond only to the first Time Request call using each fine or coarse seed; i.e., one coarse request per minute and one fine request per fine PI. Acceptance of time request may be disabled by the operator. Stations prepared to accept coarse Time Request commands shall decrypt the initial words of incoming calls under eight (vs. six) possible seeds: w = 0 and w = 1 with the current coarse TOD, and with the current fine TOD ±1 PI. (Note that only one coarse TOD is checked vs. three fine TODs.)

B.5.5.2.3 Time Server request (protected).

A time server may request authenticated time from the original requestor by returning a Time Server request, which is identical to the Time Service response as given above except that the TWAS termination is replaced by TIS. The original requester shall then respond with a Time Service response, as above, with an authenticator generated by the three-way exclusive-or of the command word and the coarse time word from its Time Service response and the authentication word (including the REP preamble) from the Time Server request, as specified in Appendix A, A.5.6.4.5.

B.5.5.2.4 Authentication and adjustment (protected).

A station awaiting a Time Service response shall attempt to decrypt received words under the appropriate seeds. If the request used a coarse seed, the waiting station shall try the coarse seeds used to encrypt its request, with w = 0 and w = 1, and those corresponding to 1 minute later. If the request used a fine seed, the waiting station shall try the usual six seeds: w = 0 and w = 1, and those corresponding to 1 minute later. If the request used a fine seed, the waiting station shall try the usual six seeds: w = 0 and w = 1 with the current fine TOD ±1 PI. Upon successful decryption of a Time Service response, the requesting station shall exclusive-or the received command and coarse time words with the authentication word it sent in its request. If the 21 least significant bits of the result match the corresponding 21 bits of the received authentication word, the internal time shall be adjusted using the time received in the Time Is command and coarse time word, and the time uncertainty shall be set in accordance with Appendix A, A.5.6.4.6.

B.5.5.3 Active time acquisition (non-protected).

A station that does not know the correct date and time to within 1 minute may attempt to actively acquire time from any station with which it can communicate in non-protected mode by employing the protocol in the following paragraphs. Because time is not known in this case with sufficient accuracy to employ LP, the entire exchange takes place in the clear, with the authentication procedure as the only barrier against decryption.

B.5.5.3.1 Time Request call (non-protected).

A station requiring time shall request the current value of the network time by transmitting a non-protected Time Request call, formatted as follows:

TO <time server> CMD Time Request DATA <coarse time>

REP <random #> TIS <requestor>.

The Time Request command shall be immediately followed by a coarse time word, followed by an authentication word containing a 21-bit number, generated by the requesting station in such a fashion that future numbers are not predictable from recently used numbers from any net member. Encrypting a function of a radio-unique quantity and a sequence number that is incremented with each use (and is retained while the radio is powered off) may meet this requirement.

B.5.5.3.2 Time Service response (non-protected).

A station that receives and accepts a non-protected Time Request call shall respond with a non-protected Time Service response formatted as follows:

TO <requester> CMD Time Is <time> DATA <coarse time>

REP <authenticator> TWAS <time server>.

The Time Is command shall be immediately followed by a coarse time word and an authentication word. The 21-bit authenticator shall be generated by encrypting the 24-bit result of the three-way exclusive-or of the command word and the coarse time word from this transmission and the entire random number word (including the REP preamble) from the requester, as specified in Appendix A, A.5.6.4.5. The encryption shall employ the AL-1 and AL-2 algorithm and a seed containing the time sent and w = all 1s. The least-significant 21 bits of this encryption shall be used as the authenticator. A time server shall respond only to the first error-free non-protected Time Request call received each minute (according to its internal time). Acceptance of non-protected time requests may be disabled by the operator.

B.5.5.3.3 Authentication and adjustment (non-protected mode).

Upon receipt of a non-protected Time Service response, the requesting station shall exclusive-or the received coarse time word with the received Time Is command word. Then exclusive-or the result with the entire random number word it sent in its Time Request call, and encrypt this result using w = all 1s and the coarse time contained in the Time Service response. If the 21 least significant bits of the result match the corresponding 21 bits of the received authentication word, the internal time shall be adjusted using the received coarse and fine time, and the time uncertainty shall be set in accordance with Appendix A, A.5.6.4.6.

B.5.5.4 Passive time acquisition (optional).

As an alternative to the active time acquisition protocols specified above, stations may attempt to determine the correct network time passively by monitoring protected transmissions. Regardless of the technique used to otherwise accept or reject time so acquired, passive time acquisition shall include the following constraints:

a. Local time may only be adjusted to times within the local window of uncertainty. Received transmissions using times outside of the local uncertainty window shall be ignored.

b. Local time quality shall be adjusted only after receipt of transmissions from at least two stations, both of which include time quality values, and whose times are consistent with each other within the windows implied by those time qualities.

A passive time acquisition mechanism may also be used to maintain network synchronization once achieved. Passive time acquisition is optional, and if provided, the operator shall be able to disable it.

B.5.5.5 Time broadcast.

To maintain network synchronization, stations shall be capable of broadcasting unsolicited Time Is commands to the network, periodically or upon request by the operator:

TO <net> CMD Time Is <time> DATA <coarse time>

REP <authenticator> TWAS <time server>.

The Time Is command shall be immediately followed by a coarse time word and an authentication word. The authenticator shall be generated by the exclusive-or of the command word and the coarse time word from this transmission as specified in Appendix A, A.5.6.4.4. If the broadcast is made without LP (i.e., in the clear), the authenticator must be encrypted as described in Appendix A, A.5.6.4.5 to provide any authentication. The use of an authenticator that does not depend on a challenge from a requesting station provides no protection against playback of such broadcasts. A station receiving such broadcasts must verify that the time and the time uncertainty that the broadcasts contain are consistent with the local time and uncertainty before such received time is at all useful.

B.5.5.6 Advanced time distribution protocols.

Advanced time exchange protocols for application levels 3 and 4 will be addressed as required with future upgrades of MIL-STD-188-141.

B.5.6 The Lattice Algorithm.

The Lattice Algorithm is designed specifically for the encryption of 24-bit ALE words. It uses a 56-bit key (7 bytes), and the 8-byte seed described in B.5.2.3, Seed format.

NOTE: The author makes no claim of proprietary rights in this algorithm. All are free to implement it without royalty.

B.5.6.1 Encryption using the Lattice Algorithm.

A schematic representation of the algorithm is shown in figure B-5. The algorithm operates on each of the 3 bytes of the 24-bit word individually. At each step, here termed one ìroundî of processing, each byte is exclusive-ored with one or both of the other data bytes, a byte of key, and a byte of seed, and the result is then translated using the 256x8 bit substitution table ("S-box") listed in table B-I. Eight rounds shall be performed. Mathematically, the encryption algorithm works as follows:
1. Let f(ï) be an invertible function mapping {0..255} -> {0..255}.2. Let V be a vector of key variable bytes and S be a vector of TOD/frequency "seed" bytes. Starting with the first byte in each of V and S, perform eight "rounds" of the sequence in 4 below, using the next byte from V and S (modulo their lengths) each time a reference to V[ ] and S[ ] is made.3. Let A be the most significant of the three-byte input to each round of encryption, B be the middle byte, and C be the least significant byte, and A', B', and C' be the corresponding output bytes of each round.4. Then for each round, A' = f(A + B + V[ ] + S[ ]) C' = f(C + B + V[ ] + S[ ]) B' = f(A' + B + C' + V[ ] + S[ ])

The 24-bit output of the encryption algorithm consists of, in order of decreasing significance, the bytes Aí, Bí, and Cí resulting from the eighth round of encryption.

B.5.6.2 Decryption using the Lattice Algorithm.

The decryption algorithm simply inverts the encryption algorithm. Note that the starting point in the V and S vectors must be pre-computed, and that the V and S bytes are used in reverse order.
1. Let g(ï) be the inverse of the f(ï) used for encryption (see table B-II).2. Starting with the last elements of the V and S vectors used in encryption, perform eight rounds of the following decryption steps, working backward through the V and S vectors.3. Let Aí be the most significant of the 3-byte input to each round of decryption, Bí be the middle byte, and Cí be the least significant byte, and A, B, and C be the corresponding output bytes of each round.4. B = g(B') + A' + C' + V[ ] + S[ ] C = g(C') + B + V[ ] + S[ ] A = g(A') + B + V[ ] + S[ ]

The 24-bit output of the decryption algorithm consists of, in order of decreasing significance, the bytes A, B, and C resulting from the eighth round of decryption.

FIGURE B-5. Lattice Algorithm schematic diagram (encryption).

B.5.6.3 Encryption and decryption tables.

The 256 -> 256 mapping tables B-I and B-II for use in linking protection are given below. To use these tables, use the most significant 4 bits of the input byte to select a row in the table, and the least significant 4 bits to select a column. The output byte is contained at the selected location.

TABLE B-I. Encryption table f(ò).
9c f2 14 c1 8e cb b2 65 97 7a 60 17 92 F9 78 41
07 4c 67 6d 66 4a 30 7d 53 9d b5 bc c3 ca f1 04
03 ec d0 38 B0 ed ad c4 dd 56 42 bd a0 de 1b 81
55 44 5a e4 50 DC 43 63 09 5c 74 cf 0e ab 1d 3d
6b 02 5d 28 e7 c6 ee b4 d9 7c 19 3e 5e 6c d6 6e
2a 13 a5 08 b9 2d BB a2 d4 96 39 e0 ba d7 82 33
0d 5f 26 16 fe 22 af 00 11 c8 9e 88 8b a1 7b 87
27 E6 c7 94 d1 5b 9b f0 9f db e1 8d d2 1f 6a 90
f4 18 91 59 01 b1 FC 34 3c 37 47 29 e2 64 69 24
0a 2f 73 71 a9 84 8c a8 a3 3b E3 E9 58 80 a7 D3
b7 c2 1c 95 1e 4d 4f 4E fb 76 fd 99 c5 C9 e8 2e
8a df f5 49 f3 6f 8f e5 EB F6 25 d5 31 c0 57 72
aa 46 68 0b 93 89 83 70 ef a4 85 f8 0f b3 AC 10
62 cc 61 40 f7 fa 52 7f ff 32 45 20 79 ce ea be
cd 15 21 23 D8 b6 0c 3f 54 1A bf 98 48 3a 75 77
2b ae 36 da 7e 86 35 51 05 12 b8 a6 9a 2C 06 4b

TABLE B-II. Decryption table g(ò).
6784 4120 1ff8 fe10 5338 90c3 e660 3ccc
cf68 f951 02e1 630b 814a E92e a23e a47d
dbe2 65E3 8fba 6270 438b 50f0 Fd55 af91
16bc D95f 87F6 F289 235a ed99 883f 4be7
d30f 2a36 31da c18a ecb3 15ff 11a5 A7a6
34f7 d618 e830 29BE 9c83 3275 3942 4c61
0ad2 d037 8d07 1412 c28e 7e40 4d13 4fb5
c793 bf92 3aEE a9ef 0edc 096e 4917 f4d7
9d2f 5ec6 95ca F56f 6bc5 b06c 967b 04b6
7F82 0cc4 73a3 5908 EBab fc76 0019 6a78
2c6d 5798 c952 fb9e 9794 c03d CE26 f166
2485 06cd 471a e5a0 fa54 5c56 1b2b dfea
bd03 a11c 27ac 4572 69AD 1d05 d1e0 dd3b
2274 7c9F 58bb 4e5d E448 f379 3528 2db1
5b7a 8c9A 33b7 7144 ae9B deB8 2125 46c8
771e 01b4 80b2 B9d4 cb0D d5a8 86aa 64d8

B.5.6.4 Lattice Algorithm examples.

Key variable = c2284a1ce7be2f

seed = 543bd88000017550 (w=0)

Encrypt 54e0cd ( <TO> SAM )
Step A B C 0 54 E0 CD 1 D0 72 1D 2 1D 48 3C 3 41 DB 0C 4 98 7C 6D 5 39 10 3D 6 13 AA E4 7 FC 82 27 8 C0 D7 05
Result: C0D705

seed = 543bd88040017550 (w=1)Encrypt 54E0CD ( <TO> SAM )
Step A B C 0 54 E0 CD 1 D0 72 1D 2 1D 3D EF 3 E1 F8 6B 4 11 A0 A2 5 6E 32 A0 6 B0 B4 E2 7 CF CB 11 8 70 84 34
Result: 708434
seed = 543bd88080017550 (w=2)Encrypt b2a7c5 ( <TIS> JOE )
Step A B C 0 B2 A7 C5 1 59 47 E6 2 91 BF 83 3 D1 B8 E8 4 53 ED A9 5 F4 55 9E 6 32 25 FA 7 DD 5D 15 8 28 ED 4A
Result: 28ED4A
Decrypt C0D705
Step A B C 0 C0 D7 05 1 FC 82 27 2 13 AA E4 3 39 10 3D 4 98 7C 6D 5 41 DB 0C 6 1D 48 3C 7 D0 72 1D 8 54 E0 CD
Result: 54E0CD
Decrypt 708434
Step A B C 0 70 84 34 1 CF CB 11 2 B0 B4 E2 3 6E 32 A0 4 11 A0 A2 5 E1 F8 6B 6 1D 3D EF 7 D0 72 1D 8 54 E0 CD
Result: 54E0CD
Decrypt 28ED4A
Step A B C 0 28 ED 4A 1 DD 5D 15 2 32 25 FA 3 F4 55 9E 4 53 ED A9 5 D1 B8 E8 6 91 BF 83 7 59 47 E6 8 B2 A7 C5
Result: B2A7C5


B.5.7 The SoDark Algorithm (NT).The SoDark Algorithm is designed specifically for the encryption of 3G control PDUs. It uses a 56-bit key (7 bytes), and the 8-byte seed described in B.5.2.3 Seed format. The SoDark-3 variant is designed for 24-bit words, while the SoDark-6 variant is designed for 48-bit words.
NOTE: The author makes no claim of proprietary rights in this algorithm. All are free to implement it without royalty.

B.5.7.1 Encryption using the SoDark-3 Algorithm.The SoDark-3 Algorithm is designed specifically for the encryption of 3G ALE PDUs. It shall be applied to the 24 least-significant bits of each such PDU. A schematic representation of the SoDark-3 algorithm is shown in figure B-6. The algorithm operates on each of the 3 bytes of the 24-bit word individually. At each step, here termed one ìroundî of processing, each byte is exclusive-ored with one or both of the other data bytes, a byte of key, and a byte of seed, and the result is then translated using the 256x8 bit substitution table ("S-box") listed in table B-I. Sixteen rounds shall be performed.
Mathematically, the encryption algorithm works as follows:
1. Let f(ï) be an invertible function mapping {0..255} -> {0..255}.2. Let V be a vector of key variable bytes and S be a vector of TOD/frequency "seed" bytes. Starting with the first byte in each of V and S, perform sixteen "rounds" of the sequence in 4 below, using the next byte from V and S (modulo their lengths) each time a reference to V[ ] and S[ ] is made.3. Let A be the most significant of the 3-byte input to each round of encryption, B be the middle byte, and C be the least significant byte, and A', B', and C' be the corresponding output bytes of each round.4. Then for each round, A' = f(A + B + V[ ] + S[ ]) C' = f(C + B + V[ ] + S[ ]) B' = f(A' + B + C' + V[ ] + S[ ])
The 24-bit output of the encryption algorithm consists of, in order of decreasing significance, the bytes Aí, Bí, and Cí resulting from the sixteenth round of encryption.

B.5.7.2 Decryption using the SoDark-3 Algorithm.The decryption algorithm simply inverts the encryption algorithm. Note that the starting point in the V and S vectors must be pre-computed, and that the V and S bytes are used in reverse order.

1. Let g(ï) be the inverse of the f(ï) used for encryption (see table B-II).2. Starting with the last elements of the V and S vectors used in encryption, perform sixteen rounds of the following decryption steps, working backward through the V and S vectors.3. Let Aí be the most significant of the 3-byte input to each round of decryption, Bí be the middle byte, and Cí be the least significant byte, and A, B, and C be the corresponding output bytes of each round.4. B = g(B') + A' + C' + V[ ] + S[ ] C = g(C') + B + V[ ] + S[ ] A = g(A') + B + V[ ] + S[ ]
The 24-bit output of the decryption algorithm consists of, in order of decreasing significance, the bytes A, B, and C resulting from the sixteenth round of decryption.

B.5.7.3 Encryption using the SoDark-6 Algorithm.The SoDark-6 Algorithm is designed specifically for the encryption of 3G PDUs that use Burst Waveform 1 (BW1), including traffic setup, synchronization management, and link maintenance PDUs. It shall be applied to the 48 bits of each such PDU. A schematic representation of the SoDark-6 algorithm is shown in figure B-7. The algorithm operates on each of the 6 bytes of the 48-bit PDU individually. At each step, here termed one ìroundî of processing, each byte is exclusive-ored with two of the other data bytes, a byte of key, and a byte of seed, and the result is then translated using the 256x8 bit substitution table ("S-box") listed in table B-I. Sixteen rounds shall be performed.

FIGURE B-6. SoDark-3 Algorithm schematic diagram (encryption).
Mathematically, the encryption algorithm works as follows:
1. Let f(ï) be an invertible function mapping {0..255} -> {0..255}.2. Let V be a vector of key variable bytes and S be a vector of TOD/frequency "seed" bytes. Starting with the first byte in each of V and S, perform sixteen "rounds" of the sequence in 4 below, using the next byte from V and S (modulo their lengths) each time a reference to V[ ] and S[ ] is made.3. Let A be the most significant of the 6-byte input to each round of encryption, B, C, D, and E be the middle bytes in descending order of significance, and F be the least significant byte, and A', B', Cí, Dí, Eí and F' be the corresponding output bytes of each round.4. Then for each round, A' = f(A + B + F + V[ ] + S[ ]) C' = f(B + C + D + V[ ] + S[ ]) E' = f(E + D + F + V[ ] + S[ ]) B' = f(A' + B + C' + V[ ] + S[ ]) D' = f(C' + D + E' + V[ ] + S[ ]) F' = f(E' + F + A' + V[ ] + S[ ])
The 48-bit output of the encryption algorithm consists of, in order of decreasing significance, the bytes Aí, Bí, Cí, Dí, Eí and Fí resulting from the sixteenth round of encryption.

B.5.7.4 Decryption using the SoDark-6 Algorithm.The decryption algorithm simply inverts the encryption algorithm. Note that the starting point in the V and S vectors must be pre-computed, and that the V and S bytes are used in reverse order.
1. Let g(ï) be the inverse of the f(ï) used for encryption (see table B-II).2. Starting with the last elements of the V and S vectors used in encryption, perform sixteen rounds of the following decryption steps, working backward through the V and S vectors.3. Let Aí be the most significant of the 6-byte input to each round of decryption, Bí, Cí, Dí, and Eí be the middle bytes in descending order of significance, and Fí be the least significant byte, and A, B, C, D, E and F be the corresponding output bytes of each round.4. B = g(B') + A' + C' + V[ ] + S[ ] D = g(D') + C' + E' + V[ ] + S[ ] F = g(F') + E' + A' + V[ ] + S[ ] E = g(E') + D + F + V[ ] + S[ ] C = g(C') + B + D + V[ ] + S[ ] A = g(A') + F + B + V[ ] + S[ ]
The 48-bit output of the decryption algorithm consists of, in order of decreasing significance, the bytes A, B, C, D, E, and F resulting from the sixteenth round of decryption.

FIGURE B-7. SoDark-6 Algorithm schematic diagram (encryption).