xuebaunion@vip.163.com
3551 Trousdale Rkwy, University Park, Los Angeles, CA
留学生论文指导和课程辅导
无忧GPA:https://www.essaygpa.com
工作时间:全年无休-早上8点到凌晨3点
微信客服:xiaoxionga100
微信客服:ITCS521
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
measurements.
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
should
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.
The Project
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.
Grading Criteria:
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
graphs.