sen-material: comparison handouts/ho01.tex

equal deleted inserted replaced

-:1cacbe5c67cf
+:a95782c2f046
 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
+\subsubsection*{Chip-and-PIN is Surely More Secure?}
-cards is more secure than the older method of signing receipts
-at the till. On first glance Chip-and-PIN seems obviously more
+The questions is whether the Chip-and-PIN system used with
-secure and improved security was also the central plank in the
+modern credit cards is more secure than the older method of
-``marketing speak'' of the banks behind Chip-and-PIN. The
+signing receipts at the till. On first glance the answer seems
-earlier system was based on a magnetic stripe or a mechanical
+obvious: Chip-and-PIN must be more secure and indeed improved
-imprint on the card and required customers to sign receipts at
+security was the central plank in the ``marketing speak'' of
-the till whenever they bought something. This signature
+the banks behind Chip-and-PIN. The earlier system was based on
-authorised the transactions. Although in use for a long time,
+a magnetic stripe or a mechanical imprint on the cards and
-this system had some crucial security flaws, including making
+required customers to sign receipts at the till whenever they
-clones of credit cards and forging signatures.
+bought something. This signature authorised 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. Even though the banks involved trumpeted their
 system as being absolutely 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. It was claimed that these terminals are
+manufacturers. It was claimed that these terminals were
 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 skimmed PIN numbers via built-in mobile phone
 connections. To mitigate this flaw in the security of
 Chip-and-PIN, you need to vet quite closely the supply chain
 of such terminals.
-Later on Ross Anderson and his group managed to launch a
+Later on Ross Anderson and his group were able to perform
 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 was a more
+the card think that a signature was used. This is a kind of
-serious security problem. The flaw was mitigated by requiring
+\emph{protocol failure}. After discovery, the flaw was
-that a link between the card and the bank is established at
+mitigated by requiring that a link between the card and the
-every time the card is used. Even later this group found
+bank is established at every time the card is used. Even later
-another problem with Chip-and-PIN and ATMs which do not
+this group found another problem with Chip-and-PIN and ATMs
-generate random enough numbers (nonces) on which the security
+which did not generate random enough numbers (nonces) on which
-of the underlying protocols relies.
+the security of the underlying protocols relies.
 The problem with all this is that the banks who introduced
 Chip-and-PIN managed with the new system to shift the
 liability for any fraud and the burden of proof onto the
 customer. In the old system, the banks had to prove that the
 profits too much.
 Since banks managed to successfully claim that their
 Chip-and-PIN system is secure, they were under the new system
 able to point the finger at the customer when fraud occurred:
-they must have been negligent loosing their PIN. The customer
+customers must have been negligent loosing their PIN and they
-had almost no means to defend themselves in such situations.
+had almost no way of defending 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 that their system is secure
 and it must have been the customer's fault, was bogus. In 2009
 for example the law changed and the burden of proof went back
 This is a classic example where a security design principle
 was violated: Namely, 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 claim that it is secure beyond reproach: the
+engineer would dare claim that it is secure beyond reproach:
-specification of the EMV protocol (underlying Chip-and-PIN) is
+the specification of the EMV protocol (underlying
-some 700 pages long, but still leaves out many things (like
+Chip-and-PIN) is some 700 pages long, but still leaves out
-how to implement a good random number generator). No human
+many things (like how to implement a good random number
-being is able to scrutinise such a specification and ensure it
+generator). No human being is able to scrutinise such a
-contains no flaws. Moreover, banks can add their own
+specification and ensure it contains no flaws. Moreover, banks
-sub-protocols to EMV. With all the experience we already have,
+can add their own sub-protocols to EMV. With all the
-it is as clear as day that criminals were eventually able to
+experience we already have, it is as clear as day that
-poke holes into it and measures need to be taken to address
+criminals were eventually able to poke holes into it and
-them. However, with how the system was set up, the banks had
+measures need to be taken to address them. However, with how
-no real incentive to come up with a system that is really
+the system was set up, the banks had no real incentive to come
-secure. Getting the incentives right in favour of security is
+up with a system that is really secure. Getting the incentives
-often a tricky business.
+right in favour of security is often a tricky business. From a
+customer point of view the system was much less secure than
+the old signature-based method.
 \subsection*{Of Cookies and Salts}
-Lets look at another example which should helps with
+Lets look at another example which will help with
 understanding 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
+For example in order to give a discount whenever the customer
-webpage some $x$ number of times (say $x$ equal $5$). There is
+visited a webpage some $x$ number of times (say $x$ equal
-one more constraint: we want to store the information about
+$5$). There is one more constraint: we want to store the
-the number of times a customer has visited inside a cookie. I
+information about the number of visits as a cookie on the
-think, for a number of years the webpage of the New York Times
+browser. I think, for a number of years the webpage of the New
-operated in this way: it allowed you to read ten articles per
+York Times operated in this way: it allowed you to read ten
-months for free; if you wanted to read more, you had to pay.
+articles per month for free; if you wanted to read more, you
-My guess is it used cookies for recording how many times their
+had to pay. My best guess is that it used cookies for
-pages was visited, because if you switched browsers you could
+recording how many times their pages was visited, because if I
-easily circumvent the restriction about ten articles.
+switched browsers I could easily circumvent the restriction
+about ten articles.
 To implement our web-application it is good to look under the
-hood what happens when a webpage is requested. A typical
+hood what happens when a webpage is displayed in a browser. A
-web-application works as follows: The browser sends a GET
+typical web-application works as follows: The browser sends a
-request for a particular page to a server. The server answers
+GET request for a particular page to a server. The server
-this request. A simple JavaScript program that realises a
+answers this request with a webpage in HTML (we can here
-``hello world'' webpage is as follows:
+ignore these details). 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
-executed whenever a browser initiates such a GET request.
+executed whenever a browser initiates such a GET request. You
+can run this program on your computer and then direct a
+browser to the address \pcode{localhost:8000} in order to
+simulate a request over the internet.
 For our web-application of interest is the feature that the
 server when answering the request can store some information
-at the client's side. This information is called a
+on the client's side. 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
+request to the same webpage, this cookie can be read again by
-server. We can use cookies in order to store a counter that
+the server. We can use cookies in order to store a counter
-records the number of times our webpage has been visited. This
+that records the number of times our webpage has been visited.
-can be realised with the following small program
+This can be realised with the following small program
 \begin{center}
 \lstinputlisting{../progs/ap2.js}
 \end{center}
 client's browser (which is not under our control). 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 not be
-granted. In this way we do not lose us any (hypothetical)
+granted. In this way we do not lose any (hypothetical) money.
-money. What we need to be concerned about is, however, when a
+What we need to be concerned about is, however, when a client
-client artificially increases this counter without having
+artificially increases this counter without having visited our
-visited our web-page. This is actually a trivial task for a
+web-page. This is actually a trivial task for a knowledgeable
-knowledgeable person, since there are convenient tools that
+person, since there are convenient tools that allow one to set
-allow one to set a cookie to an arbitrary value, for example
+a cookie to an arbitrary value, for example above our
-above our threshold for the discount.
+threshold for the discount.
 There seems to be 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 a potentially hostile environment.
 encryption seems to not solve the problem we face with the
 integrity of our counter.
 Fortunately, \emph{hash functions} seem to be more suitable
 for our purpose. Like encryption, hash functions scramble data
-in such a way that it is easy to calculate the output of a has
+in such a way that it is easy to calculate the output of a
-function from the input. But it is hard (i.e.~practically
+hash function from the input. But it is hard (i.e.~practically
 impossible) to calculate the input from knowing the output.
 Therefore hash functions are often called \emph{one-way
 functions}. There are several such hashing function. For
 example SHA-1 would hash the string \pcode{"hello world"} to
-produce
+produce the hash-value
 \begin{center}
 \pcode{2aae6c35c94fcfb415dbe95f408b9ce91ee846ed}
 \end{center}
 \noindent That means it is not predictable what the output
 will be from just looking at input that is ``close by''.
 We can use hashes in our web-application and store in the
 cookie the value of the counter in plain text but together
-with its hash. We need to store both pieces of data such we
+with its hash. We need to store both pieces of data in such a
-can extract both components (below I will just separate them
+way that we can extract both components (below I will just
-using a \pcode{"-"}). If we now read back the cookie when the
+separate them using a \pcode{"-"}). If we now read back the
-client visits our webpage, we can extract the counter, hash it
+cookie when the client visits our webpage, we can extract the
-again and compare the result to the stored hash value inside
+counter, hash it again and compare the result to the stored
-the cookie. If these hashes disagree, then we can deduce that
+hash value inside the cookie. If these hashes disagree, then
-the cookie has been tampered with. Unfortunately, if they
+we can deduce that the cookie has been tampered with.
-agree, we can still not be entirely sure that not a clever
+Unfortunately, if they agree, we can still not be entirely
-hacker has tampered with the cookie. The reason is that the
+sure that not a clever hacker has tampered with the cookie.
-hacker can see the clear text part of the cookie, say
+The reason is that the hacker can see the clear text part of
-\pcode{3}, and also its hash. It does not take much trial and
+the cookie, say \pcode{3}, and also its hash. It does not take
-error to find out that we used the SHA-1 hashing functions and
+much trial and error to find out that we used the SHA-1
-then graft a cookie accordingly. This is eased by the fact
+hashing functions and then the hacker can graft a cookie
-that for SHA-1 many strings and corresponding hashvalues are
+accordingly. This is eased by the fact that for SHA-1 many
-precalculated. Type, for example, into Google the hash value
+strings and corresponding hash-values are precalculated. Type,
-for \pcode{"hello world"} and you will actually pretty quickly
+for example, into Google the hash value for \pcode{"hello
-find that it was generated by input string \pcode{"hello
+world"} and you will actually pretty quickly find that it was
-wolrd"}. This defeats the purpose of a hashing functions and
+generated by input string \pcode{"hello wolrd"}. This defeats
-thus would not help us for our web-applications.
+the purpose of a hashing functions and thus would not help us
+for our web-applications.
 There is one ingredient missing, which happens to be called
 \emph{salts}. Salts are random keys, which are added to the

changeset 180	a95782c2f046
parent 179	1cacbe5c67cf
child 181	a736a0c324a3