\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: + −