3551 Trousdale Rkwy, University Park, Los Angeles, CA
Covert Timing Channels
Given a source principal that is purportedly isolated from a destination principal, a covert timing channel is a means by which the source principal conveys information to the destination principal by using
mechanisms in ways not intended for performing communications:
The source principal signals a value by controlling the timing of one or more events.
The destination principal detects a value by measuring the timing of one or more events.
Note, the events used by the source principal to signal a value might be different from the events used by the destination to detect that value.
Example. A TCP connection between processes P1 and P2 can be used as a covert timing channel if it is carrying a steady stream of messages, so the TCP connection is already being used by P1 as an overt channel
for communicating with P2.
For signalling on the covert channel, process P1 signals a 0 or a 1 by controlling the time that elapses between successive messages sent using the TCP connection to P2:
a 0 is signalled by P1 not delaying before sending the next message using the TCP connection, and
a 1 is signalled by P1 delaying at least 30 seconds before sending the next message using the TCP connection.
Process P2 measures the times when messages become available for receipt on this TCP connection, and P2 recovers the signalled bits P1 sent on the convert timing channel by using the differences between these
For this covert timing channel, the events involved in signalling (i.e., two successive send operations on the TCP channel) are different from the events involved in detecting (i.e., two successive receive operations on
the TCP channel). Also, P1 and P2 in this example might both have access to the same clock (i.e., the clock on the processor that they share). But access by P1 and P2 to a common clock is not required---a known
upper-bound on the difference in the clock rates suffices.
Performance Measurement. The utility of a covert timing channel can be described by giving two performance measures. We define raw channel bandwidth to be the number of bits that, on average, are signalled
per second using the covert timing channel; and we define channel fidelity rate to be Rgood/Rtotal, where Rgood is the number of correct bits that are detected and Rtotal is the total number of bits that are detected on
the covert timing channel.
For the TCP-based covert timing channel sketched above, raw channel bandwidth can be increased by decreasing the elapsed time between the sending of successive messages using the TCP connection. But elapsed
time until delivery at P2 will vary for different messages sent using a given TCP connection, due to variations in local execution speed for P2 and due to queuing delays in TCP implementation and (possibly) the
network. Therefore, as the time used to signal a value is decreased from 30 seconds, the chances of detection errors increase (because detection error is affected by variations in message-delivery delay).
The trade-off between raw channel bandwidth and channel fidelity rate can be depicted using a graph. The X axis gives raw channel bandwidth; the Y axis gives channel fidelity rate. To be credible, such a graph
depict the results of many experiments for each value of X. So for a given value of X, the value for Y given on the graph would be (i) a point that corresponds to the average of multiple experiments and (ii) a
vertical bar depicting the standard deviation or the range of Y values associated with that point.
give experiments for enough different values of X that interpolating between these values will give a credible value for Y.
To be interesting, the X axis would span a large enough range values for X so that any interesting behavior in Y is depicted on the graph. Thus, the graph would be flat only if there is no region where changes to X
cause changes to Y.
This project is an opportunity to build and experiment with a covert timing channel.
What to do:
1. Write a pair of processes P1 and P2 that execute on the same computer. P1 should read a sequence of 0's and 1' from standard input and use a covert timing channel to signal that input to P2; P2 should write to
standard output the sequence of 0's and 1's that are the values it detects using the covert timing channel.
You may implement the covert timing channel by using a TCP-connection, as sketched above. You would start by writing processes P1 and P2 that communicate something innocuous in a sequence of messages
over TCP. You would then add (clearly identified) code to create the covert timing channel: add code to P1 for signalling and add code to P2 for detection. But ambitious groups will devise their own covert
timing channel. Some might use another shared system service and employ contention for that resource to cause delays that are the basis for the covert timing channel.
2. Construct a credible and interesting (these characteristics are defined above) graph that depicts raw channel bandwidth vesus channel fidelity rate for the covert timing channel implemented for (1). You should
have justifications for
the number of X points the graph depicts,
the range of X points the graph depicts, and
the number of values that were measured to obtain the Y value reported for each X point.
If it would be helpful, then disable or limit other activity on the computer while you are running and measuring your covert timing channel.
3. Extra Credit. Write a third process P3 that, when run on the same computer as P1 and P2, reduces the bandwidth of the covert timing channel and/or reduces the channel fidelity rate. P1 and P2 must not be
altered in any way. To document the effectiveness of your P3 design, construct a graph that includes two curves: (i) an exact copy of curve depicted in the graph for (2) and (ii) a new curve that depicts raw
channel bandwidth vesus channel fidelity rate when P3 is running.
What to submit:
report.pdf documenting the covert timing channel and its performance. Use 10 point font (or larger) with standard margins. The report should be structured as follows.
Section 1 [3 single-sided pages max] should explain your covert timing channel, giving English descriptions (and informal code sketches if needed) to depict (i) how P1 signals a 1 or 0 and (ii) how P2
detects a bit.
Section 2 [2 single-sided pages max] should give a credible and interesting graph of raw channel bandwidth vesus channel fidelity rate for executions of P1 and P2 on a shared computer. Section 2 should
also give the justification for the number and range of X values and for the number of measurements in constructing a Y point.
Extra Credit. Section 3 [2 single-sided pages max] should explain what P3 does and why that disrupts the covert timing channel, giving English descriptions (and an informal code sketch if useful).
Section 3 should also give the graph described above in (3) for comparing channel performance with and without P3 execution.
There will be a 10% deduction if any section exceeds the page limit or violates the formatting requirements.
exampleRun.txt A listing that shows P1 and P2 being compiled and then run together on some input. The listing should depict the input to P1 and what P2 detected.
code.zip gives the source files for P1, P2, and (if built) P3.
Quality of the write-up in report.pdf. English usage and clarity of exposition count.
Novelty / difficulty / subtlety / performance of the covert timing channel that was implemented. Cite sources if you implemented a scheme that you read about.
Soundness of the arguments used to justify that the graph in (2) is credible and interesting. Feel free to read the web to learn about standard statistical justifications for replicating measurements when
performing an experiment. Cite sources if you are using a scheme you read about.
Readability of the code.
Extra Credit. Novelty / difficulty / subtlety / effectiveness of disruption implemented by P3.
You may implement this project to run on any computer / operating system / programming language---provided that computer will also run a browser that supports Zoom. We reserve the right to request a
demo of your system over Zoom. During that Zoom demo, you will use the files in code.zip to build an instance of your system, run the resulting system, and reproduce exampleRun.txt as well as the data in the