4.6 Satellite Encryption
4.6 Satellite Encryption
Counter (CTR) Mode - It can be considered as a counter-based version of CFB mode without
the feedback. In this mode, both the sender and receiver need to access to a reliable counter,
which computes a new shared value each time a ciphertext block is exchanged. This shared
counter is not necessarily a secret value, but challenge is that both sides must keep the counter
synchronized.
Figure 4.11 Effect of altitude and focal precision on satellite signal dispersion
Figure 4.12 Satellite communications categories as a function of data value and type of link.
An asymmetrically keyed encryption algorithm may be adopted, wherein the key used to
encrypt a message is different from the key used to decrypt the message. Such an approach
requires each party to maintain only two keys, one of which is kept private, and the other of
which is made publicly-available. If party A wants to send party B a secure transmission, A first
asks B for her public key, which can be transmitted over an unsecured connection. Party A then
encodes a secret message using B‘s public key. The message is secure because only B‘s private
key can decode the message.
To authenticate herself to B, party A needs only to re-encode the entire message using her
own private key before transmitting the message to B. Upon receiving the message, B can
establish whether it was sent by A, because only A‘s private key could have encoded a message
that can be decoded with A‘s public key. This process is depicted in Figure 4.13 below.
Figure 4.13 Ensuring sender identity and message security with asynchronously keyed
encryption
Uplink Encryption
The reason for this is that the actual transmission of the encrypted message to the satellite
is but the final step in a long chain of custody that begins when the message is created and ends
when the message is successfully received by the satellite.
If one assumes that the confidentiality and integrity of the message have not been
compromised as the message has passed through all of these intermediaries, then but two
primary security concerns remain:
the directional accuracy of the transmitting antenna, and
the method used to encrypt the message.
In the case of the former, the transmitting antenna must be sufficiently well-focused to
allow the signal to be received by _ and ideally only by _ the target satellite.
When deciding upon which encryption method to use, the sender must simultaneously
consider the value of the data being transmitted, the purpose of the transmission, and the
technological and computational limitations of the target satellite. A satellite‘s computational and
technological capabilities are a function of its design specifications, its current workload, and
any degradation that has occurred since the satellite was placed into orbit. These properties of the
satellite can therefore be considered constraints _ any encrypted uplink communications must
work within the boundaries of these limitations.
Downlink Encryption
As with uplink encryption, the technological and computational capabilities of the
spacecraft may constrain the extent to which a particular message can be protected. Similarly, if
the utilization of a particular encryption scheme would reduce the efficiency or message-
handling capacity of a satellite to a level that is deemed unacceptable, then the satellite‘s
operators may choose to prioritize capacity over downlink security.
Unlike uplink signals, which can only originate from the surface of the planet, messages
to be transmitted over a downlink channel can come from one of three different sources: the
terrestrial surface, from another spacecraft, or from the satellite itself. The source of the message
to be broadcast to the planet‘s surface plays a critical role in determining the method of
protection for that message.
For example, a message that originates from the surface or from another spacecraft, there
exist two scenarios: First, the satellite transmitting the message to Earth may be serving only as a
simple signal repeater or amplifying transmitter; that is to say, the message is already encrypted
upon receipt, and the satellite is simply relaying the previously encrypted message to the surface.
In the second scenario, a satellite may need to filter a message or alter its encryption method
prior to downlink transmission.
of algorithms or keys. Decoding the encrypted message, however, required that a proprietary
security card be inserted into the receiver.
One could argue that this information could be embedded in security tokens that users could
carry such as smartcards, USB security tokens, and so on. However, this requires additional
hardware that will certainly have a cost.
It may also introduce compatibility issues in cases when the tokens need to be plugged into
another device. Finally, such tokens can always be compromised through loss or theft.
Nowadays, the most common form of authentication in use is via knowledge of
passwords. Passwords are cheap and convenient. They are easy to choose, use, and change when
needed, and they are typically human memorable.
The pervasiveness of this method of authentication is the main motivation behind
research in Password-Authenticated Key Exchange (PAKE) However, convenience is often
accompanied by security degradation in cryptography; using passwords instead of strong
cryptographic keys is no exception and brings forth some important issues that we try to explain
in the following sections
Dictionary Attacks
In classical key exchange, exhaustively searching for the correct long-term key can
simply not be done feasibly by construction: It is completely random and very long.
A password on the other hand is likely to be short and produced with less-than-ideal
randomness from a small set of values, making exhaustive search possible. We illustrate the
effects of this phenomenon with a ―dummy‖ protocol
This kind of attack is arguably the most important one to prevent in PAKE design because an
attacker need not be online to perform it.
Offline attackers Offline attackers have more time and computational power for the simple
reason that they may be impossible to interrupt. Indeed, in the above example it was only
necessary for the adversary to record an exchange.
From then on, there is no way to interfere with the adversary‘s behavior. We call such attacks
offline dictionary attacks
Other Security Properties Dictionary attacks are specific to PAKE protocols. However, the
forward secrecy and known-session key security were actually first considered in classical key
exchange and subsequently carried over to the password based case.
It may be tempting to do this with all security properties that can be defined for key exchange in
general, but this is not always possible.
For instance, resistance to key compromise impersonation in which an adversary who
compromised a user‘s long-term key can then impersonate other parties to that user is not
satisfied by a PAKE: The other holder of the password can always be impersonated to the
attacked user
Security in Theory
It should also be mentioned that the security of EKE‘s main protocol flows has been studied
from a purely theoretical point of view.
In this work, the protocol and several of its variants have been proven secure; that is, a very
precise mathematical proof of security was given assuming that the encryption function satisfies
some idealized properties
Flaws The protocol, as it is defined, can be made vulnerable to dictionary attacks. The main
issue is that even if it is a strictly random element of G, gx is not randomly distributed in E‘s
plaintext space. Concretely, this means that we cannot expect that for every possible candidate
passwordpw0, the decryption will fall into Zp* therefore, every time such a test fails, a password
can be ruled out.
Proposed Standardization
In 2000, Bellare and Rogaway proposed a PAKE protocol based essentially on EKE for IEEE
standardization: AuthA . One of the main concerns the authors raise in their work involves
instantiating the encryption function.
The security flaws discussed above clearly show that this needs to be done very carefully. In
particular, there is no straightforward way to directly replace the ideal cipher with a concrete
symmetric encryption algorithm. The authors propose to replace the encrypting operation with
multiplying the group element by a hash of the password, allowing them to rely on idealizing a
hash function rather than an encryption function.