\documentclass{article}
\usepackage{../style}
\usepackage{../langs}

\lstset{language=JavaScript}

\begin{document}

\section*{Handout 1 (Security Engineering)}

Much of the material and inspiration in this module is taken
from the works of Bruce Schneier, Ross Anderson and Alex
Halderman. I think they are the world experts in the area of
security engineering. I especially like that they argue that a
security engineer requires a certain \emph{security mindset}.
Bruce Schneier for example writes:

\begin{quote} 
\it ``Security engineers --- at least the good ones --- see
the world differently. They can't walk into a store without
noticing how they might shoplift. They can't use a computer
without wondering about the security vulnerabilities. They
can't vote without trying to figure out how to vote twice.
They just can't help it.''
\end{quote}

\begin{quote}
\it ``Security engineering\ldots requires you to think
differently. You need to figure out not how something works,
but how something can be made to not work. You have to imagine
an intelligent and malicious adversary inside your system
\ldots, constantly trying new ways to
subvert it. You have to consider all the ways your system can
fail, most of them having nothing to do with the design
itself. You have to look at everything backwards, upside down,
and sideways. You have to think like an alien.''
\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
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
rules, and it may be unethical. Under some circumstances, even
probing for weaknesses of a system may result in severe
penalties, up to and including expulsion, fines and
jail time. Acting lawfully and ethically is your
responsibility. Ethics requires you to refrain from doing
harm. Always respect privacy and rights of others. Do not
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.\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
never a sufficient one). This is actually an important thread going
through the whole course: We will assume that encryption works
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 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. 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. 

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
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
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 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
customer used the card, which they often did not bother with.
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 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.
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
to the banks. They need to prove whether it was really the
customer who used a card or not.

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
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.

\subsection*{Of Cookies and Salts}

Lets look at another example which should helps 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.

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:

\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.

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
\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

\begin{center}
\lstinputlisting{../progs/ap2.js}
\end{center}

\noindent The overall structure of this program is the same as
the earlier one: 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 an integer. In case the cookie is not present, we default
the counter to zero. The odd looking construction \code{...||
0} is realising this defaulting 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
specially grafted message back to the client.

Let us step back and analyse this program from a security
point of view. We store a counter in plain text on the
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)
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
is that they are stored on the client's side, which from the
the server's perspective is 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 single, global key for all the
clients that visit our site, then we risk that our whole
``business'' might collapse in the event this key gets known
to the outside world. Then all cookies we might have set in
the past, can now be decrypted and manipulated. If, on the
other hand, we use many ``private'' keys for the clients, 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.

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
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

\begin{center}
\pcode{2aae6c35c94fcfb415dbe95f408b9ce91ee846ed}
\end{center}

\noindent Another handy feature of hash functions is that if
the input changes only a little, the output changes
drastically. For example \pcode{"iello world"} produces under
SHA-1 the output

\begin{center}
\pcode{d2b1402d84e8bcef5ae18f828e43e7065b841ff1}
\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
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 wolrd"} 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. 



There is one ingredient missing, which happens to be called
\emph{salts}. Salts are random keys, which are added to the
counter before the hash is calculated. In our case we need to
keep the salt secret. As can be see in Figure~\ref{hashsalt},
we now need to extract from the cookie the counter value and
the hash (Lines 19 and 20). But before has the counter again
(Line 22) we need to add the secret salt. Similarly, when we
set the new increased counter, we will need to add the salt
before hashing (this is done in Line 15). Our web-application
will now store cookies like 

\begin{figure}[p]
\lstinputlisting{../progs/App4.js}
\caption{\label{hashsalt}}
\end{figure}

%The corresponding attack is called \emph{dictionary
%attack}\ldots hashes are not reversed by brute force
%calculations, that is trying out all possible combinations.


%We have to make sure the salt does not get known.


%Note ....NYT 
\end{document}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: t
%%% End: 
