Using ionosounders to relay
encrypted
and sensitive information in politically sensitive regions
A modern approach to
supplying
intelligence information with 99.996% uptime
Abstract
Ionsounders and Ionosounder networks have long been used to observe the
height-vs-frequency of the Ionsphere's 3 primary layers along a given
path.
Ionosounders provide near real time information along a fixed
ionospheric path
like
- Maximum Usable Frequency (MUF)
- Lowest Usable Frequency (LUF)
- Optimum Point-to-Point Frequency
- Electron Density
To most ordinary people, and suspicious governments these scientific
instruments are not at all
interesting. Yet, Ionosondes provide a of near optimal way of
transmitting up to {64 KB / day} of secure traffic for a single
dedicated
Point-to-Point Ionsounde link. Evidence suggests that a chain of 64
ionosoundes could send 1 KB of traffic each day. This strategic
capability has historically never been significantly used, as few
modern (5th and 6th generation) ionosoundes have the ability to send
data.
The data transfer capability of Ionosounders is little known and little
exploited, as only 2 or 3 modern (5th and 6th generation) Ionosuonders
have
ever offered the capability. This data transmitting capability (binary,
not Morse Code) is becoming more popular as it allows each frequency to
be checked for its error correction rates, not just is analog
propagation characteristics.
History of the ionosounder
The basic ionosonde technology was invented in 1925 by G. Breit and M.
A. Tuve. The technology was further developed in the late 1920s by a
number of prominent physicists, including Edward Victor Appleton. The
term "ionosphere" and hence "ionosounde" were proposed by Robert
Watson-Watt. An ionosonde is used for finding the optimum operation
frequencies for broadcasts or two-way communications in the high
frequency range, but in doing so reveals the height of the various
ionosphere layers (and their electron densities) in near real time.
Ionosounders are classifiable as RADAR systems, as they have many
operational similarities to Atmospheric Doppler Radar systems.
How could an ionosunder
network be implimented
Well, lets assume a target region (Indonesia)
Academic cover and other
issues
Data transfer mechanisms or
"Minimizing intercept probability"
Essential principals
- The ionosounder should synchronize to UTC every hour either
externally or via the ionosounder network, and this synchronization
should be within 10 ms to 50 ms.
- The Ionosounde should be avoided as a primary, high data rate
information transfer mechanism. The software must refuse to send large
messages.
- When there is no data to transmit, the unit must behave like a
normal
ionosonde.
- Internal network traffic should be under 4 KB per day for 16
nodes, ignoring time synchronization events.
- Even highly important messages should be trickled with great
care.
- Never use the same frequency twice for sending secure messages in
a single UTC day -- there are theoretically 120,000 usable HF
frequencies!
- HF band sweeps should be 10 minutes in duration, but high
priority abbreviated 5 minute sweeps should exist as an option.
- The less obvious the methods of transferring bits from Nodes to
HQ, the better.
- Ideally high speed RTTY should be used as a primary data exchange
medium. Care must be chosen to use under 500 Hz of bandwidth and to
provide a brief tuning signal. RTTY data bursts should preferably be
under 5 seconds with 3 seconds being ideal.
Messaging protocol
(generalized)
When message is already compiled for transmission (encrypted, with some
error correction) ...
Alert HQ in next available sweep at predetermined (frequencies,
emission mode, message mode);
- Sample : 11262 kHz, CW, Assert-message-to-transmit-at-my-node;
CW("HQ-MSG-0099-AA-79806067785959")
- Format should send message to HQ that message is ready to
transmit in less than 20 seconds (~19.8s), this is a huge time window
(relatively speaking) but it allows for bad propagation conditions.
- If Morse Code is used this means 40 WPM to 60 WPM baseline
transmission rate.
- For RTTY, 10 seconds (~9.8s) should be the baseline.
- Format must call HQ either via call letters or by some method.
- Format must specify message mode (short, long, file).
- Format should specify originating party number sign, changed each
UTC day.
- Format should specify starting sequence letters or number or
mixed.
- Format should specify an abbreviated message checksum or hashsum.
Wait for HQ to acknowledge it is in Sweep-mode-accept-message mode...
- Change frequency, keeping sweep pattern until next
Contact-Point-Frequency is reached
- Send acknowledgment to node in pre-determined (frequency,
emission mode, message mode).
- Sample : 12094 kHz, CW("ACK-HQ-ZZ-8790960")
- HQ is now ready to accept chunks of message data, node is now
ready to send them in a modifiable pre-determined pattern.
On predetermined sweep mode for data transfer
{
Run sweep until Contact-Point-Frequency[1 ... N] is reached
- Assert-contact-point-frequency-unusable-36hrs (HQ and node do
this in unison)
- Do some housekeeping...
{
Send Chunk [1 of N]
- Sample : 15261 kHz, CW("AA RUZFK PWMSI WUEOV 74X")
- Pattern should use Alpha ("AA" ... "ZZ", [400 x 5 x 3 = 6000
chars]) chunk indicator where appropriate.
- Pattern should use Numeric ("000"..."999", [999 x 5 x 3 = 14985
chars]) chunk indicator where appropriate.
- Use 5 letter or number groups, it is the ITU standard...
- The final digits of a chunk should be : 2 separate check digits,
based on the Luhn (mod10; mod11) or 2 digit Verhoeff algorithm.
- The final digits of a chunk should be : Modulus10(chunk);
Modulus11(chunk); final-char; where ";" appends.
- There should be a terminating letter, like "X" or "Z"
- The sweep should resume.
}
}
Alert HQ message terminates;
Resume normal sweep mode;
This method could be implemented as a
bit transfer protocol instead of a symbol transfer protocol, but the
protocol mechanisms would be substantially different.
While Node-to-HQ-sweep (node is
master, HQ is slave; done every other sweep for example)
- At each frequency where
Local_error_rate is Low, and where Optimal_frequency_neighborhood is
True
- Send Message_bits_fragment {Clock; Fragment_counter;
Bit_counter; Fragment; Parity-check}
- Sample "1010 01100011 11101000 1111 1111 1111 1111 1111 1111 11"
- This could be done at fixed or variable sweep points in the
sweep spectrum.
- There are a lot of bit level protocol issues that would need to
be worked out, albeit true that bit level protocols may be less obvious
for HF-DF units.
- Some merging bits would be needed, with 4 to 6 being
recommended depending on propagation conditions.
- The slave Node should send an ECC
reply, with a short status field bitmap
- Ideally, each node could send
as few as 12 bits, making HFDF message intercept very hard
Network issues and benefits
Such an ionosunde network must be syncronizable to UTC with a tolerance
of 10ms to 50ms depending on sweep speed. This can be done within the
network -- the HQ node can transmit time signals -- or outside : as in
Europe and the Americas time signal stations are readily available.
In order for an ionosounder network to be able to provide data, it must
be part of a network.
- Some network models and configurations are more applicable than
others.
- However, necessity would dictate for some network functions that
HQ-Node relationship must exist.
- Yet, for most network functions statelessness or near
statelessness is preferred.
Networking function, and network relationship
- Software updates : HQ-Node, minor parametric data only -- like
transmission modes (CW, MT63, RTTY) etc ...
- Schedule updates : HQ-Node, including priority update level;
- Schedule updates : Node-HQ, if message needs urgent delivery or
priority handling
- Frequency updates : HQ-Node, for determining optimal channels to
send data;
- Node-HQ message updates : Node-Node, stateless for
"point-to-point"
but stateful if data needs to be relayed along a chain of nodes
Cost and design issues
Ideally all the nodes involved should be powered by PCs of a type
similar to "One Laptop Per Child" or a computer not much more complex
than that. The cost for such a unit is under (250 USD, 200 EUR, 300
AUD) in 2010.
- Ideally the PC will have a sound card and a USB controller.
- Ideally the PC would have the ionosounder as a USB device.
The ionosounder would be assumed to have a good transmitter and
receiver, but could be able to pass on digitized audio to the PC for
further processing. The cost of the ionosounder would be assumed to be
under (2000 USD, 1000 EUR, 3000 AUD), where the ionosounder would have
no more than 200 w of output power.
Probably it is best to have 3 frequencies set aside for the individual
ionsounder nodes to listen to, so that they can be updated with the
most up to date network configuration (frequencies, operating modes,
reporting schedules, node-priority-lists)
- This implies that 3 frequencies would need to be used for 3 x 30
minutes per day, about 8 hours apart (01 h, 10 h, 18 h).
- The frequencies should originate from the HQ location.
- The modulation format must be robust, like MT63 or Polytone.
Ionsounding stations can be powered by solar power, and this should be
considered as a viable solution in remote regions. The typical load
that should be assumed is 2 kw for all equipment, so 5 kw in solar
power would be required to run the systems and charge the batteries for
night operation. One can assume an ionosounder power of 500 watts, but
for single hop paths 150 watts will be more optimal.
Technical references
Physics
Cryptography & Intelligence Gathering
Telecom
|
Created by
Max Power |
|
Original idea
|
|
Created
10 March 2010 |
|
Last revised
11 August 2010
Appearance, protocol
|
|
|
|
|
|
|
|
|
|
|