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
TABLE B-I. Encryption table f(Ú). 260TABLE B-II. Decryption table g(Ú). 261
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
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.
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.
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.
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 |
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.
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.
2G | second generation | |
3G | third generation |
2G ALE | second generation automatic link establishment |
3G ALE | third generation automatic link establishment |
AL-0 | unprotected application level |
AL-1 | unclassified application level |
AL-2 | unclassified enhanced application level |
AL-3 | unclassified but sensitive application level |
AL-4 | classified application level |
ALE | automatic link establishment |
AMD | automatic message display |
ASCII | American Standard Code for Information Interchange |
BW1 |
CMD | ALE preamble word COMMAND |
CRC | cyclic redundancy check |
DBM | data block message |
DO |
DODISS | Department of Defense Index of Specifications and Standards |
DTM | data text message |
FEC | forward error correction |
HF | high frequency |
ICD | interface control document |
LP | linking protection |
LPCM | linking protection control module |
ms | millisecond |
NSA | National Security Agency |
NT | Not Tested |
PDU |
PI | protection interval |
REP | ||
TOD | time of day |
The abbreviations and acronyms used for timing symbols are contained
in Annex A to Appendix A.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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).
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.î
The following requirements apply to both second generation automatic
link establishment (2G ALE) and third generation automatic link
establishment (3G ALE) unless otherwise stated.
The LPCM shall execute the LP procedure specified in B.5.3 and
control the attached scrambler(s) as specified below.
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.
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.
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.
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.
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.
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.
a. | ||||
| ||||
| ||||
1 9 | 10 26 | 27 34 | 37 64 |
TOD
b. | c. | |||
d. | ||||||
37 40 | 41 44 | 45 48 | 49 52 | 53 56 | 57 60 | 61 64 |
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.
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.
All ALE words shall be protected including message text.
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.
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.
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).
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 17bit
integer rather than as an 11bit coarse time and a 6bit
fine time field. This 17bit 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. Synchronousmode 3G ALE nodes shall ignore
any synchronousmode Probe PDU (i.e., a Probe PDU that is
not preceded by Scanning Call PDUs) which is not encrypted using
the current PI number.
Asynchronous 3G handshakes shall be protected using the procedure
in B.5.3 that has been modified as follows.
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.
The handshake PDU that follows an asynchronousmode call
shall be encrypted using the current TOD with word number = 3.
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.
See Appendix A, A.5.6.4.3.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
Advanced time exchange protocols for application levels 3 and
4 will be addressed as required with future upgrades of MIL-STD-188-141.
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.
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.
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.
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.
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 |
67 | 84 | 41 | 20 | 1f | f8 | fe | 10 | 53 | 38 | 90 | c3 | e6 | 60 | 3c | cc |
cf | 68 | f9 | 51 | 02 | e1 | 63 | 0b | 81 | 4a | E9 | 2e | a2 | 3e | a4 | 7d |
db | e2 | 65 | E3 | 8f | ba | 62 | 70 | 43 | 8b | 50 | f0 | Fd | 55 | af | 91 |
16 | bc | D9 | 5f | 87 | F6 | F2 | 89 | 23 | 5a | ed | 99 | 88 | 3f | 4b | e7 |
d3 | 0f | 2a | 36 | 31 | da | c1 | 8a | ec | b3 | 15 | ff | 11 | a5 | A7 | a6 |
34 | f7 | d6 | 18 | e8 | 30 | 29 | BE | 9c | 83 | 32 | 75 | 39 | 42 | 4c | 61 |
0a | d2 | d0 | 37 | 8d | 07 | 14 | 12 | c2 | 8e | 7e | 40 | 4d | 13 | 4f | b5 |
c7 | 93 | bf | 92 | 3a | EE | a9 | ef | 0e | dc | 09 | 6e | 49 | 17 | f4 | d7 |
9d | 2f | 5e | c6 | 95 | ca | F5 | 6f | 6b | c5 | b0 | 6c | 96 | 7b | 04 | b6 |
7F | 82 | 0c | c4 | 73 | a3 | 59 | 08 | EB | ab | fc | 76 | 00 | 19 | 6a | 78 |
2c | 6d | 57 | 98 | c9 | 52 | fb | 9e | 97 | 94 | c0 | 3d | CE | 26 | f1 | 66 |
24 | 85 | 06 | cd | 47 | 1a | e5 | a0 | fa | 54 | 5c | 56 | 1b | 2b | df | ea |
bd | 03 | a1 | 1c | 27 | ac | 45 | 72 | 69 | AD | 1d | 05 | d1 | e0 | dd | 3b |
22 | 74 | 7c | 9F | 58 | bb | 4e | 5d | E4 | 48 | f3 | 79 | 35 | 28 | 2d | b1 |
5b | 7a | 8c | 9A | 33 | b7 | 71 | 44 | ae | 9B | de | B8 | 21 | 25 | 46 | c8 |
77 | 1e | 01 | b4 | 80 | b2 | B9 | d4 | cb | 0D | d5 | a8 | 86 | aa | 64 | d8 |
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