physicalsystems.tex

% Discuss the nature of physical system and some of the unique problems associated with them

\chapter{Physical Systems}
\label{chapter:physicalsystems}

Physical systems present an interesting problem domain for study. In contrast to software systems,
they are subjected to multiple different factors that all require consideration during design. Physical
systems frequently must be able to cope with environmental factors such as temperature change, moisture,
or questionable power systems. 

A purely software system may be able to assume it will only receive input from a standard input and output
channel. In contrast, a physical system must be able
to account for multiple different input sources, especially input types that might not have been intended. 
A physical system might receive input directly from end users, networking devices, sensors. A physical
system could also consider environment changes as a sort of secondary, unintended input. For example,
the device's power may fluctuate, potentially changing the behavior of internal circuits. A temperature change
could cause the sensitivity of a certain component to increase or decrease, which will in turn alter the behavior
of the system. These are but a few examples of the various factors that a physical system must be properly
designed to handle and account for.

% Describe some of the typical use cases of physical systems
\section{Typical Organization and Use Case of Physical Systems}
Physical systems are a very broad category that covers a large set of devices, applications, and use cases.
Because of this, it is difficult to discuss physical systems generically. Rather, this section details some
of the common configurations that physical systems take. The rest of the work will regard physical systems as
belonging to one of the configurations discussed.

Despite it being difficult to characterize physical systems in general terms, their operation can be viewed using the mathematical
relation below. Physical inputs are inputs from physical interfaces, such as buttons, control terminals, or radio signals. Other
inputs might be information received over the network or from some sort of attached peripheral.

\vspace*{-20pt}
\begin{align*}
Output = System_{Physical}(Physical Inputs, Other Inputs, Environment)
\end{align*}

The three configurations of physical systems that will be considered are that of the standalone, deployed, or peripheral physical
systems. Each is distinct based upon how much interaction it has, not only with the physical world, but also with other physical
systems or remote devices. Peripheral systems have the most interaction with remote parties and other systems while standalone
systems have the least. In terms of the equation above, the three categories vary based on what sort of 'Other Inputs' are passed
to them.

% Standalone device (in the field)
\subsection{Standalone Physical Systems}
One common configuration of a physical system is that of a standalone physical system. This means that the
physical system is not reliant on communicating with another physical system; it is deployed and functions
independently. An example of this could be a garage door opener. There might be a control pad on the side of the
garage which can open or close the garage door. Additionally, there could be an option to open the door remotely
using some sort of radio frequency device.

Standalone physical systems are more straightforward to deal with in a lot of cases. The garage opener example has
a very specific use case, defined inputs (control pad and remote control) and defined outputs (open or close the garage
door). These qualities typically do not change nor are updated often, if ever. As such, it is typically easy to create a sort
of state diagram to model the behavior of standalone physical systems.

% Device in the field that communicates back
\subsection{Deployed Physical Systems}
Another category of physical systems is that of the 'deployed physical system'. This is a type of physical system that not only
interacts with the environment it is in, but may also communicate with another physical system or some sort of remote
server. A cash register is a good example of a deployed physical system. It takes input from cashiers, who can record transactions,
print receipts, and insert or remove currency from it. However, it also communicates with remote servers in certain cases, such
as when a credit card is used. It must interact with the physical environment, but also must interact with remote servers to verify
the credit card transactions.

Because a deployed physical system must potentially interact with a remote party, it is more complex than a standalone physical
system. It must contend with the same sorts of issues that standalone systems do, but also has to deal with issues that could
relate to the remote communication or other physical system.  As such, it is more complex and difficult to model a deployed
physical system than a standalone physical system.

% Physical peripheral
\subsection{Peripheral Physical Systems}
Peripheral physical systems are the most complex type of physical system. These are normally called 'peripherals'. That
is, they do not provide the main functionality of a system, but augment its ability in some way. An example could be a 
programmable sensor array. The sensor array could be connected to a network through which it receives commands. The array
would then take sensor readings and communicate them back over the network. Not only does the array have to 
interact with the physical environment to take readings, but there is also the component of dealing with the
command and control element from the network connection.

Peripheral physical systems are characterized by the fact that they not only require interaction with the physical world, but
also with other physical systems or with a remote connection. Because of this, it is very difficult to model the system, since
there are a very large number of ways that the other communicating party could potentially behave, in addition to any difficulties
involved with modeling the physical inputs themselves. 

% Describe the coming sections of the paper

\section{Failure Considerations}
There are multiple ways that a physical system or device could fail. There are multiple benign ways that a system could
fail. That is, the system is not attacked in any way, but some circumstances cause the system to fail or degrade in some
way. There any many different ways to reduce these risks, as discussed below.

% Discuss the benign difficulties associated with physical systems

\subsection{Device Failure}
% Device failure
One failure model is for a complete device failure. In this instance, the device has failed to such a point that it is no
longer able to perform any of its intended function. This typically occurs to some catastrophic component failure or a 
lack of preventative maintenance as a system's performance degrades over time.

To mitigate the danger of a complete system failure, it is necessary to impose a schedule for periodic maintenance and
monitoring of the operating environment for dangerous conditions. An example of this would be inspecting all the moving
parts and springs on a garage door opener to ensure they are not cracking or otherwise at risk of failing. 
Monitoring the environment is critical to ensure that a system is not operating in conditions it was not designed for. If a sensor
array was designed for operating indoors and it is placed outside and subjected to weather, of course it will fail.


\subsection{Device Degradation}
% Device degradation 
One of the few ``good" aspects about a complete device failure is that it is readily noticeable. If the system fails completely,
it is not possible to interact with it any more. In contrast, if a device \textit{degrades}, the degradation may not be noticed
for a long time, while in the interim, the degraded system will be used under the assumption it is properly functioning.

An example of this is if a sensor array were to be degraded in some way, its readings might be skewed. The skewed readings
would then be recorded and fed into a processing program or used by some other party. Depending on the application, this
could cause the intended application to then function improperly. In certain instances, this degradation can even prove to be
life threatening, such as when temperature sensors in the Fukishima nuclear plant were incorrectly reporting the internal
temperature of nuclear reactors.~\cite{fukushima}

\section{Attacks}
% Discuss different malicious problems with physical systems
In addition to the problems that are inherently present in physical systems, it is necessary to consider problems that may
occur from attackers maliciously using the system. They may be attempting to gain unauthorized access to the system,
prevent legitimate users from using the system, disable the system entirely, or any number of other motivations.

\subsection{Denial of Services Attacks}
% DOS
It is entirely possible that a malicious entity wants to simply disable and disrupt access to a physical system, preventing legitimate access
to the system. If the physical system is unable to deliver valid services to its intended users, it is essentially worthless. 

Denial of service attacks against physical systems are unique with regards to the denial of service attacks against software. Some are very complex,
while others are very simple. In the simplest case, an attacker can simply use a hammer to smash the system. More complex denial of
service attacks may include inputting erroneous data, which may crash or slow the system. Attackers might also disrupt the environment
that the physical system resides in, such that it is not useful. For instance, an attacker might put a heating element near a thermometer,
which would essentially mean the system is unusable for its intended purpose.

As far as defenses against these types of attacks go, a first step is usually to ensure that the system is protected against a reasonable
amount of tampering. This could include protective cases, placing the system behind a fence, or having a guard present. As mentioned
previously, proper maintenance can also be helpful, to prevent an attacker from manipulating and disturbing the surrounding
environment.

\subsection{Man in the Middle Attacks}

% MITM
There is a class of attack known as Man in the Middle (MITM) attacks. This is when an attacker sits between two parties and eavesdrops
on their communications. The attacker is then able to learn sensitive data that the two parties are transmitting.

This type of attack is especially relevant for physical systems. Physical systems frequently transmit data over cables, infrared, radio, or
other wireless communication methods. If an attacker was able to splice a listening device into a cable or construct the appropriate type
of receiver, it is plausible he would be able to easily recover the communications between the two parties. 

Depending on the type of data
being sent, this could compromise the security and integrity of the system. For instance, maybe an attacker would be able to recover the
command sequence to reset a sensor array. He could then reset the sensor array at will.

To combat this type of threat, it is important to assume that any communication being done is being eavesdropped on. This then
necessitates \textit{encrypting} the data being transmitted. In this way, even if an adversary was to recover the data, he would not be
able to make sense of it. Chapter~\ref{chapter:cryptographyoverview} goes into more detail on encryption techniques.

As a final note, it is important to note that MITM are not relevant for only signals being transmitted over wireless and wires, but also on
the internal buses of the circuits themselves. An attacker might be able to attach logic probes to bus lines between the processor and memory
of the system and deduce sensitive data. In this case, it is important to take measures to prevent these bus lines from being exposed,
through the use of potting and other tamper-proofing methods. Another option is to incorporate the entire design (or at least the sensitive
bus lines) on a single chip, such as a Field Programmable Gate Array (FPGA) or a System on a Chip (SOC).

\subsection{Impersonation}
% Impersonation
Another issue for physical system designers to be aware of is that any party they are communicating with is actually an authorized party.
This is especially relevant for deployed physical systems and peripheral physical systems. Since they require external communication as a
major component of their proper operation, they are especially sensitive to these attacks.

It is plausible that an attacker could disconnect the cables used to communicate and re-attach them to his own machine. He could then
issue commands and communicate with the physical system. Unless protective measures are in place, the system would then interact
back with the attacker. The attacker could then issue any sorts of commands that he wished of the system.

The issue of impersonation harkens to the need for \textit{authentication}. Chapter~\ref{chapter:cryptographyoverview} goes into more
details on authentication protocols, but essentially, all communications between the system and the other party would have to be
\textit{signed}. If the signatures do not match the expected values, the communication is rejected and dropped. In this way, an attacker
would have to be able to forge the signature of the valid party, which is considered computationally difficult if a proper signature scheme
is used.

% Replay attacks
\subsection{Replay Attacks}
There is a class of attacks that is related to MITM attacks. Replay attacks leverage the fact that certain protocols
might consistently send the same data every execution of the protocol. For instance, consider a system that requires the sender to 
send an encrypted version of an ID number
before every message to identify itself. If that ID is always the same, an attacker could simply capture the encrypted text and send
that; he does not need to actually know the plaintext version of the ID to impersonate the sending party.

This type of attack can be remedied by ensuring that every execution of a protocol is unique. This is done through the use of
time stamps or ``nonce" values, which are randomly chosen, one time use values. Then, if an attacker tried to replay previous
communications, the attack would fail since the time stamp or the nonce value would not match. So in the example above, the
sender might encrypt his ID number concatenated with the current time. Then, an attacker would not be able to re-use any
communications he captures in the future.

% Signals
\subsection{Signals Injection}
Due to the nature of electronics, physical systems are susceptible to external signals being directed at them. If an electric or 
magnetic field is directed at certain elements of internal circuitry, it is possible to alter the behavior of those circuits. An attacker
can potentially bombard a physical system in some way to elicit a response from the device.

An example of this type of signal injection was shown in the Cold War with 'The Thing'.~\cite{thing} In 1945, a Soviet made Seal of the 
Republic was given as a gesture of friendship and installed in a sensitive office. When bombarded with radio waves, the device internals
would resonate, modulate the radio waves, and it was possible to listen to conversations in the room where it was installed. This is a
classical example of how physical systems can be manipulated through signal injection. In this case, the signal injection was a desired
feature, but it is important to be aware of this danger when designing physical systems.

Another example is disruption of GPS signals. This typically occurs because radio frequency signals are using the same wavelengths as
GPS signals. GPS signals are usually weaker than RF signals, so the RF signals dominate and drown out the GPS signals. A report~\cite{gpsdisruption} 
was delivered in 2001 and details some of these risks and defenses associated with GPS interference, both unintentional and intentional.

To mitigate signal injection, it is important that system designers consider and plan for signal injection attacks. Defenses against this could
include shielding equipment against magnetic and electrical fields or using multiple frequencies and receivers when possible~\cite{gpsdisruption}.
These are just some techniques to defend against the signal injection threat which must be considered.

\subsection{Signal Emissions}
Adversaries may also attempt to harvest a physical systems signal emissions in an attempt to gather information. This is because during
normal operation, many devices give off electromagnetic and radio signals, at least to some extent, even if unintended. There have been
examples showing that it is possible to recreate what is on a user's CRT or LCD computer monitor by recording the emissions of the monitor
from a far, using a process known as ``Van Eck phreaking".~\cite{monitor}~\cite{lcds}

NATO created a program called TEMPEST to investigate and report on the risks associated with signal emissions and defenses
against these threats.~\cite{tempest} Some of the easily implementable changes they suggest are to put electromagnetic shielding
around devices. Suggestions presented also include signal filtering such that certain frequencies are attenuated or completely removed
from emission.

\subsection{Tampering}
If a system is not protected, tampering with the system itself is one of the easiest attacks for an adversary to execute.
He can attach logic probes or some device to record traffic being sent over signal buses to learn sensitive information.
He could also tamper with certain portions of the system so that error handling and recovery routines were triggered,
which might be easier to exploit in some way.

There are many different techniques to deal with physical tampering of a system. One of these includes potting, which 
involves sealing all components in a type of epoxy, so that no wires are exposed. Another technique would be to
put the sensitive components in an enclosure that had some sort of alarm on it. When the enclosure was opened, an
authority would be notified, who could then deal with the tampering. Physical tampering is a very large problem
and these are just a few techniques to address it, but every system designer should consider how to protect his
system from tampering.