--- a/handouts/ho01.tex	Tue Sep 23 17:05:33 2014 +0100
+++ b/handouts/ho01.tex	Wed Sep 24 23:35:47 2014 +0100
@@ -1,6 +1,8 @@
- \documentclass{article}
+\documentclass{article}
 \usepackage{../style}
+\usepackage{../langs}
 
+\lstset{language=JavaScript}
 
 \begin{document}
 
@@ -35,17 +37,19 @@
 \end{quote}
 
 \noindent In this module I like to teach you this security
-mindset. This might be a mindset that you think is very foreign to you
-(after all we are all good citizens and not ahck into things). I beg
-to differ: You have this mindset already when in school you were
-thinking, at least hypothetically, about in which ways you can cheat in an
-exam (whether it is about hiding notes or looking over the shoulders
-of your fellow pupils). Right? To defend a system, you need to have
-this kind mindset and be able to think like an attacker. This will
-include understanding techniques that can be used to compromise
-security and privacy in systems. This will many times result in
-insights where well-intended security mechanisms made a system actually
-less secure.\smallskip
+mindset. This might be a mindset that you think is very
+foreign to you---after all we are all good citizens and not
+hack into things. I beg to differ: You have this mindset
+already when in school you were thinking, at least
+hypothetically, about ways in which you can cheat in an exam
+(whether it is about hiding notes or looking over the
+shoulders of your fellow pupils). Right? To defend a system,
+you need to have this kind mindset and be able to think like
+an attacker. This will include understanding techniques that
+can be used to compromise security and privacy in systems.
+This will many times result in insights where well-intended
+security mechanisms made a system actually less
+secure.\smallskip
 
 {\Large\bf Warning!} However, don’t be evil! Using those
 techniques in the real world may violate the law or King’s
@@ -58,9 +62,9 @@
 tamper with any of King's systems. If you try out a technique,
 always make doubly sure you are working in a safe environment
 so that you cannot cause any harm, not even accidentally.
-Don't be evil. Be an ethical hacker.\smallskip
+Don't be evil. Be an ethical hacker.\medskip
 
-
+\noindent
 In this lecture I want to make you familiar with the security mindset
 and dispel the myth that encryption is the answer to all security
 problems (it is certainly often part of an answer, but almost always
@@ -69,24 +73,195 @@
 perfectly, but still attack ``things''. By ``works perfectly'' we mean
 that we will assume encryption is a black box and, for example, will
 not look at the underlying mathematics and break the 
-algorithms.\footnote{Though fascinating it might be.}
+algorithms.\footnote{Though fascinating this might be.}
  
-For a secure system it seems four requirements need to come together:
-First a security policy (what is supposed to be achieved?); second a
-mechanism (cipher, access controls, tamper resistance etc); third the
-assurance we obtain from the mechanism (the amount of reliance we can
-put on the mechanism) and finally the incentives (the motive that the
-people guarding and maintaining the system have to do their job
-properly, and also the motive that the attackers have to try to defeat
-your policy). The last point is often overlooked, but plays an
-important role. 
+For a secure system, it seems, four requirements need to come
+together: First a security policy (what is supposed to be
+achieved?); second a mechanism (cipher, access controls,
+tamper resistance etc); third the assurance we obtain from the
+mechanism (the amount of reliance we can put on the mechanism)
+and finally the incentives (the motive that the people
+guarding and maintaining the system have to do their job
+properly, and also the motive that the attackers have to try
+to defeat your policy). The last point is often overlooked,
+but plays an important role. To illustrate this lets look at
+an example. 
+
+The questions is whether the Chip-and-PIN system with credit
+cards is more secure than the older method of signing receipts
+at the till. On first glance, Chip-and PIN seems obviously
+more secure and this was also the central plank in the
+``marketing speak'' of the banks behind Chip-and-PIN. The
+earlier system was based on a magnetic stripe or a mechanical
+imprint on the card and required customers to sign receipts at
+the till whenever they bought something. This signature
+authorises the transactions. Although in use for a long time,
+this system had some crucial security flaws, including making
+clones of credit cards and forging signatures. Chip-and-PIN,
+as the name suggests, relies on data being stored on 
+a chip on the card and a PIN number for authorisation. 
+
+
+Although the banks involved trumpeted their system as being
+secure and indeed fraud rates initially went down, security
+researchers were not convinced (especially the group around
+Ross Anderson). To begin with, the Chip-and-PIN system
+introduced a ``new player'' that needed to be trusted: the PIN
+terminals and their manufacturers. Of course it was claimed
+that these terminals are tamper-resistant, but needless to say
+this was a weak link in the system, which criminals
+successfully attacked. Some terminals were even so skilfully  
+manipulated that they transmitted PIN numbers via a built-in
+mobile phone connection. To mitigate this security flaw, you 
+need to vet quite closely the supply chain of such 
+terminals---something that also needs to be done in other 
+industries. 
+
+Later on, Ross Anderson and his group managed to launch
+man-in-the-middle attacks against Chip-and-PIN. Essentially
+they made the terminal think the correct PIN was entered and
+the card think that a signature was used. This flaw was
+mitigated by requiring that a link between the card and the
+bank is established at every time the card is used. Even
+later this group found another problem with Chip-and-PIN and
+ATMs which do not generate random enough numbers (nonces) 
+on which the security of the underlying protocols relies. 
+
+The problem with all this is that the banks who introduced
+Chip-and-PIN managed to shift the liability for any fraud and
+the burden of proof onto the customer with the new system. In
+the old system, the banks had to prove that the customer used
+the card, which they often did not bother about. In effect if
+fraud occurred the customers were either refunded fully or
+lost only a small amount of money. This
+taking-responsibility-of-potential-fraud was part of the
+``business plan'' of the banks and did not reduce their
+profits too much. Since they successfully claimed that their
+Chip-and-PIN system is secure, banks were able to point the
+finger at the customer when fraud occurred: it must have been
+the fault of the customer, who must have been negligent
+loosing the PIN. The customer had almost no means to defend
+themselves in such situations. That is why the work of
+\emph{ethical} hackers like Ross Anderson's group was so
+important, because they and others established that the bank's
+claim, their system is secure and it must have been the
+customer's fault, was bogus. In 2009 for example the law 
+changed the burden of proof back to the banks whether
+it was really the customer who used a card or not.
+
+It is a classic example where a security design principle was
+violated: The one who is in the position to improve security,
+also needs to bear the financial losses if things go wrong.
+Otherwise, you end up with an insecure system. In case of the
+Chip-and-PIN system, no good security engineer would actually
+think that it is secure: the specification of the EMV protocol
+(underlying Chip-and-PIN) is some 700 pages long, but still
+leaves out many things (like how to implement a good random
+number generator). Moreover, banks can add their own
+sub-protocols to it. With all the experience we already have,
+it is as clear as day that criminals were able to poke holes
+into it. With how the system was set up, the banks had no
+incentive to come up with a system that is really secure.
+Getting the incentives right in favour of security is often a
+tricky business.
 
-Lets look at an example. The questions is whether the Chip-and-PIN
-system with credit cards is more secure than the older method of
-signing receipts at the till. 
+\subsection*{Of Cookies and Salts}
+
+Lets look at another example which helps us to understand how
+passwords should be verified and stored. Imagine you need to
+develop a web-application that has the feature of recording
+how many times a customer visits a page. For example to 
+give a discount whenever the customer visited a webpage some 
+$x$ number of times (say $x$ equal $5$). For a number of years
+the webpage of the New York Times operated in this way: it 
+allowed you to read ten articles per months for free; if
+you wanted to read more you had to pay. There is one more
+constraint: we want to store the information about the number
+of times a customer has visited inside a cookie. 
+
+A typical web-application works as follows: The browser sends
+a GET request for a particular page to a server. The server 
+answers is request. A simple JavaScript program that realises
+a ``hello world'' webpage is as follows:
+
+\begin{center}
+\lstinputlisting{../progs/ap0.js}
+\end{center}
+
+\noindent The interesting lines are 4 to 7 where the answer
+to the GET request is generated\ldots in this case it is just
+a simple string. This program is run on the server and will
+be run whenever a browser initiates such a GET request.
+
+For our web-application of interest is the feature that the
+server when answering the request can store some information
+on the client. This information is called a \emph{cookie}.
+The next time the browser makes another GET request to the 
+same webpage, this cookie can be read by the browser. 
+Therefore we can use a cookie in order to store a counter
+recording the number of times a webpage has been visited. 
+This can be realised with the following small program
+
+\begin{center}
+\lstinputlisting{../progs/ap2.js}
+\end{center}
+
+\noindent The overall structure of this code is the same as
+the earlier program: Lines 7 to 17 generate the answer to a
+GET-request. The new part is in Line 8 where we read the
+cookie called \pcode{counter}. If present, this cookie will be
+send together with the GET-request from the client. The value
+of this counter will come in form of a string, therefore we
+use the function \pcode{parseInt} in order to transform it
+into a string. In case the cookie is not present, or has been
+deleted, we default the counter to zero. The odd looking
+construction \code{...|| 0} is realising this in JavaScript.
+In Line 9 we increase the counter by one and store it back
+to the client (under the name \pcode{counter}, since potentially 
+more than one value could be stored). In Lines 10 to 15 we
+test whether this counter is greater or equal than 5 and
+send accordingly a message back to the client.
+
+Let us step back and analyse this program from a security
+perspective. We store a counter in plain text on the client's
+browser (which is not under our control at all). Depending on
+this value we want to unlock a resource (like a discount) when
+it reaches a threshold. If the client deletes the cookie, then
+the counter will just be reset to zero. This does not bother
+us, because the purported discount will just be granted later.
+This does not lose us any (hypothetical) money. What we need
+to be concerned about is when a client artificially increases
+this counter without having visited our web-page. This is
+actually a trivial task for a knowledgeable person, since
+there are convenient tools that allow us to set a cookie to an
+arbitrary value, for example above our threshold for the
+discount. 
+
+There is no real way to prevent this kind of tampering with
+cookies, because the whole purpose of cookies is that they are
+stored on the client's side, which from the the server's
+perspective is in a potentially hostile environment. What we
+need to ensure is the integrity of this counter in this
+hostile environment. We could think of encrypting the counter.
+But this has two drawbacks to do with the key for encryption.
+If you use a `global' key for all our client's that visit our
+site, then we risk that our whole ``business'' might colapse
+when this key gets known to the outside world. Suddenly all
+cookies we might have set in the past, can now be manipulated.
+If on the other hand, we use a ``private'' key for every
+client, then we have to solve the problem of having to
+securely store this key on our server side (obviously we
+cannot store the key with the client because then the client
+again has all data to tamper with the counter; and obviously
+we also cannot encrypt the key, lest we can solve a
+chicken-and-egg problem). So encryption seems to not solve the
+problem we face with the integrity of our counter.
 
 
 
+
+
+Note ....NYT 
 \end{document}
 
 %%% Local Variables: