# HG changeset patch # User Christian Urban # Date 1411641225 -3600 # Node ID a95782c2f046eab865d90f1af742daad28e2e923 # Parent 1cacbe5c67cffac079445cb9e4d47999165ba98b updated diff -r 1cacbe5c67cf -r a95782c2f046 handouts/ho01.pdf Binary file handouts/ho01.pdf has changed diff -r 1cacbe5c67cf -r a95782c2f046 handouts/ho01.tex --- a/handouts/ho01.tex Thu Sep 25 07:49:22 2014 +0100 +++ b/handouts/ho01.tex Thu Sep 25 11:33:45 2014 +0100 @@ -87,17 +87,20 @@ 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 improved security 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 -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. +\subsubsection*{Chip-and-PIN is Surely More Secure?} + +The questions is whether the Chip-and-PIN system used with +modern credit cards is more secure than the older method of +signing receipts at the till. On first glance the answer seems +obvious: Chip-and-PIN must be more secure and indeed improved +security was 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 cards and +required customers to sign receipts at the till whenever they +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 @@ -107,7 +110,7 @@ (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 @@ -116,16 +119,16 @@ 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 -serious security problem. The 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 card think that a signature was used. This is a kind of +\emph{protocol failure}. After discovery, the 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 did 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 with the new system to shift the @@ -141,8 +144,8 @@ 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 -had almost no means to defend themselves in such situations. +customers must have been negligent loosing their PIN and they +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 @@ -156,43 +159,47 @@ 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 -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). No human -being is able to scrutinise such a specification and ensure it -contains no flaws. Moreover, banks can add their own -sub-protocols to EMV. With all the experience we already have, -it is as clear as day that criminals were eventually able to -poke holes into it and measures need to be taken to address -them. However, with how the system was set up, the banks had -no real incentive to come up with a system that is really -secure. Getting the incentives right in favour of security is -often a tricky business. +engineer would dare claim that it is secure beyond reproach: +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). No human being is able to scrutinise such a +specification and ensure it contains no flaws. Moreover, banks +can add their own sub-protocols to EMV. With all the +experience we already have, it is as clear as day that +criminals were eventually able to poke holes into it and +measures need to be taken to address them. However, with how +the system was set up, the banks had no real incentive to come +up with a system that is really secure. Getting the incentives +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 -webpage some $x$ number of times (say $x$ equal $5$). There is -one more constraint: we want to store the information about -the number of times a customer has visited inside a cookie. I -think, 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. -My guess is it used cookies for recording how many times their -pages was visited, because if you switched browsers you could -easily circumvent the restriction about ten articles. +For example in order to give a discount whenever the customer +visited a webpage some $x$ number of times (say $x$ equal +$5$). There is one more constraint: we want to store the +information about the number of visits as a cookie on the +browser. I think, for a number of years the webpage of the New +York Times operated in this way: it allowed you to read ten +articles per month for free; if you wanted to read more, you +had to pay. My best guess is that it used cookies for +recording how many times their pages was visited, because if I +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 -web-application works as follows: The browser sends a GET -request for a particular page to a server. The server answers -this request. A simple JavaScript program that realises a -``hello world'' webpage is as follows: +hood what happens when a webpage is displayed in a browser. A +typical web-application works as follows: The browser sends a +GET request for a particular page to a server. The server +answers this request with a webpage in HTML (we can here +ignore these details). A simple JavaScript program that +realises a ``hello world'' webpage is as follows: \begin{center} \lstinputlisting{../progs/ap0.js} @@ -201,16 +208,20 @@ \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 -server. We can use cookies in order to store a counter that -records the number of times our webpage has been visited. This -can be realised with the following small program +request to the same webpage, this cookie can be read again by +the server. We can use cookies in order to store a counter +that records the number of times our webpage has been visited. +This can be realised with the following small program \begin{center} \lstinputlisting{../progs/ap2.js} @@ -239,13 +250,13 @@ 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) -money. What we need to be concerned about is, however, 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 one to set a cookie to an arbitrary value, for example -above our threshold for the discount. +granted. In this way we do not lose any (hypothetical) money. +What we need to be concerned about is, however, 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 one to set +a cookie to an arbitrary value, for example above our +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 @@ -270,13 +281,13 @@ 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 -function from the input. But it is hard (i.e.~practically +in such a way that it is easy to calculate the output of a +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} @@ -296,25 +307,26 @@ 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 -can extract both components (below I will just separate them -using a \pcode{"-"}). If we now read back the cookie when the -client visits our webpage, we can extract the counter, hash it -again and compare the result to the stored hash value inside -the cookie. If these hashes disagree, then we can deduce that -the cookie has been tampered with. Unfortunately, if they -agree, we can still not be entirely sure that not a clever -hacker has tampered with the cookie. The reason is that the -hacker can see the clear text part of the cookie, say -\pcode{3}, and also its hash. It does not take much trial and -error to find out that we used the SHA-1 hashing functions and -then graft a cookie accordingly. This is eased by the fact -that for SHA-1 many strings and corresponding hashvalues are -precalculated. Type, for example, into Google the hash value -for \pcode{"hello world"} and you will actually pretty quickly -find that it was generated by input string \pcode{"hello -wolrd"}. This defeats the purpose of a hashing functions and -thus would not help us for our web-applications. +with its hash. We need to store both pieces of data in such a +way that we can extract both components (below I will just +separate them using a \pcode{"-"}). If we now read back the +cookie when the client visits our webpage, we can extract the +counter, hash it again and compare the result to the stored +hash value inside the cookie. If these hashes disagree, then +we can deduce that the cookie has been tampered with. +Unfortunately, if they agree, we can still not be entirely +sure that not a clever hacker has tampered with the cookie. +The reason is that the hacker can see the clear text part of +the cookie, say \pcode{3}, and also its hash. It does not take +much trial and error to find out that we used the SHA-1 +hashing functions and then the hacker can graft a cookie +accordingly. This is eased by the fact that for SHA-1 many +strings and corresponding hash-values are precalculated. Type, +for example, into Google the hash value for \pcode{"hello +world"} and you will actually pretty quickly find that it was +generated by input string \pcode{"hello wolrd"}. This defeats +the purpose of a hashing functions and thus would not help us +for our web-applications.