Binary file handouts/ho04.pdf has changed

--- a/handouts/ho04.tex	Mon Oct 27 00:35:12 2014 +0000
+++ b/handouts/ho04.tex	Mon Oct 27 12:30:38 2014 +0000
@@ -14,7 +14,9 @@
 glance. Let us first look, as a case-study, at how access
 control is organised in Unix-like systems (Windows systems
 have similar access controls, although the details might be
-quite different).
+quite different). Then we have a look at how secrecy and
+integrity can be ensured in a system, and finally have a look
+at shared access control in multi-agent systems.
 
 
 \subsubsection*{Unix-Style Access Control}
@@ -200,6 +202,15 @@
 users can decide how to restrict or grant access to resources.
 With mandatory access control, the access to resources is
 enforced ``system-wide'' and cannot be controlled by the user.
+There would be no point to let users set the secrecy level,
+because if they want to leak information they would set it to
+the lowest. Even if there is no malicious intent, it could
+happen that somebody by accident sets the secrecy level too
+low for a document. Note also that the secrecy levels are in
+tension with the Unix-style access controls. There root is
+allowed to do everything, but in a system enforcing secrecy,
+you might not like to give root such powers. 
+
 There are also some interesting rules for reading and writing
 a resource that need to be enforced: 
 
@@ -265,52 +276,72 @@
 \emph{Biba} model, named after Kenneth Biba. Its purpose is to
 prevent data modification by unauthorised principals.
 
-The paradoxical result of the different reading and writing 
-rules in the \emph{Bell/LaPadula} and \emph{Biba} models is
-that we cannot have secrecy and integrity at the same time
-in a system, or they need to be enforced by different means.
+The somewhat paradoxical result of the different reading and
+writing rules in the \emph{\mbox{Bell}/LaPadula} and
+\emph{Biba} models is that we cannot have secrecy and
+integrity at the same time in a system, or they need to be
+enforced by different means.
 
 \subsubsection*{Multi-Agent Access Control}
 
 In military or banking, for example, very critical decisions
-need to be made using a \emph{two-man rule}. This means such
-decisions need to be taken by two people together, so that
-no single person can defraud a bank or start a nuclear war
-(you will know what I mean if you have seen the classic movie
-``Dr Strangelove or: How I Learned to Stop Worrying and Love
-the
+need to be made using a \emph{two-men rule}. This means such
+decisions need to be taken by two people together, so that no
+single person can defraud a bank or start a nuclear war (you
+will know what I mean if you have seen the classic movie ``Dr
+Strangelove or: How I Learned to Stop Worrying and Love the
 Bomb''\footnote{\url{http://en.wikipedia.org/wiki/Dr._Strangelove}}).
+Translating the two-men rule into a software system seems not
+as straightforward as one might think.
 
-Let us assume we want to implement a system where a CEOs can
-fell decisions on their own, but two managing directors (MDs)
-need to come together to fell the same decision. If ``lowly''
-directors (Ds) want to take the decision, three need to come
-together. An obvious solution to such a problem is to split
-the necessary key into $n$ parts according to the ``level''
-where the decision is taken. For example one key for a CEO,
-two halves for the MDs and three thirds for the Ds. The 
-problem with this kind of sharing a key is that there might 
-be many hundreds MDs and Ds in your organisations. Simple-minded
-halving or devision by three of the keey just does not work.
+Let us assume we want to implement a system where CEOs can
+make decisions on their own, for example whether or not to
+sell assets, but two managing directors (MDs) need to come
+together to make the same decision. If ``lowly'' directors
+(Ds) want to take this decision, three need to come together.
+Remember cryptographic keys are just sequences of bits. A
+naive solution to the problem above is to split the necessary
+key into $n$ parts according to the ``level'' where the
+decision is taken. For example one complete key for a CEO, 
+halves of the key for the MDs and thirds for the Ds. The
+problem with this kind of sharing a key is that there might be
+many hundreds MDs and Ds in your organisations. Simple-minded
+halving or devision by three of the key just does not work.
 
-A much more clever solution was Blakley and Shamir in 1979. 
-This solution is inspired by some simple geometric facts.
-Given a three-dimentional axis system, we can specify a
-point on the $z$-axis, say, by specifying its coordinates.
-But we could equally specify this point by a line that 
-intersects the $z$-axis in this point. How can a line be
-specified? Well, by giving two spaces in space. But as you
-might remember from school days, we can specify the point
-also by a plane and a plane can be specified by three points
-in space. This could be pictured as follows:
+A much more clever solution was proposed by Blakley and Shamir
+in 1979. This solution is inspired by some simple geometric
+laws. Suppose a three-dimentional axis system. We can, clearly,
+specify a point on the $z$-axis, say, by specifying its
+coordinates. But we could equally specify this point by a line
+that intersects the $z$-axis in this point. How can a line be
+specified? Well, by giving two points in space. But as you
+might remember from school days, we can specify the point also
+by a plane intersecting the $z$-axis and a plane can be
+specified by three points in space. This could be pictured as
+follows:
 
 \begin{center}
 \includegraphics[scale=0.45]{../pics/pointsplane.jpg}
 \end{center}
 
-\noindent 
-Scaling this idea to more dimensions allows for even more 
-levels of access control.
+\noindent The idea is to use the points as keys for each level
+of shared access. The CEO gets the point directly. The MDs get
+keys lying on a line and the Ds get keys lying on the plane.
+Clever, no? Scaling this idea to more dimensions allows for
+even more levels of access control and more interesting access
+rules, like one MD and 2 Ds can take a decision together.
+
+Is such a shared access control used in practice? Well
+military command-chains are obviously organised like this.
+But in software systems often need to rely on data that might
+not be entirely accurate. So the CEO-level would correspond
+to the in-house data-source that you can trust completely.
+The MD-level would correspond to simple errors where you need
+three inputs and you decide on what to do next according to
+what at least two data-sources agree (the third source 
+is then disregarded, because it is assumed it contains an 
+error). If your data contains not just simple errors, you
+need levels corresponding to Ds.
 
 
 \subsubsection*{Further Information}
@@ -324,6 +355,10 @@
 \url{http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf}
 \end{center}
 
+\noindent About secrecy and integrity, and shared access
+control I recommend to read the chapters on ``Nuclear Command
+and Control'' and ``Multi-Level Security'' in Ross Anderson's
+Security Engineering book (whose first edition is free).
 
 \end{document}