# HG changeset patch # User Christian Urban # Date 1414413038 0 # Node ID e7a31a247e5a07c7a81175427d7fba787307d070 # Parent 42bf66f0a903f971fef957ca493422a53cd8ae48 updated diff -r 42bf66f0a903 -r e7a31a247e5a handouts/ho04.pdf Binary file handouts/ho04.pdf has changed diff -r 42bf66f0a903 -r e7a31a247e5a handouts/ho04.tex --- 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}