\documentstyle[]{article}
\addtolength{\oddsidemargin}{-1in}
\addtolength{\evensidemargin}{-.5in}
\addtolength{\textwidth}{1.75in}
\addtolength{\textheight}{1.75in}
\begin{document}
\noindent
David Golombek\\
6.033 Section 6, David Wetherall\\
Paper \#6: Is {\em Anything} Perfectly Secure?\\\\
     
Achieving perfect security is extremely difficult.  This may simply be 
a fact of the universe, or merely of our understanding of it.
Several issues make it difficult to achieve security at all levels. 
First, all source code to security systems should be freely available,
to let people verify the software they are using.  Second, all but a
very few components of every system (ie, the network and workstations)
must be assumed insecure, and able to me monitored and modified in any
way.  Finally, to be truly portable, a security system cannot rely 
upon any hardware for it's security.  Kerberos does a very good job of
handling the networking requirements of a security system, but was
never intended to fix all possible problems, including Eve's.  Indeed,
it is infeasible given existing Athena policy to completely secure a
workstatation.  Therefore, a firm policy is the best approach for MIT
to take.
     
The source code to a system such as Kerberos should be widely 
available for several reasons.  For instance, Kerberos must run on a 
wide variety of platforms, from Macintosh, to Windows NT, to the 
hundred varieties of UNIX available on the market.  If only binaries 
are to be distributed, the Kerberos Development team must compile and 
test binaries for each of these systems before distribution, which is
beyond the facilities of the existing group.  Next, 
the security of Kerberos may be great in theory, but if the 
implementation is broken, that security is lost, as seen the problems
recently reported by COAST about generating weak keys.  The downside
of this is policy is that a malicious programmer has the source code
to any program verification methods.  For example, one attempt to prevent Eve 
Dropper's attack would be create a complex interface to Login, hoping
to make duplication too dificult (as with Driver's Licenses).
However, this is a useless attack when you provide Eve with all the
tools used to produce the original.
     
Even if distributing a binary only version of Kerberos was deemed 
acceptable, Eve can still create a fake binary Login by monitoring the
key strokes on an Athena workstation as a user logs in using the real
Login binary.  By simply patching the X Windows binary, it is simple
to copy all keystrokes into a buffer, to be later sent out to an
random location.  Indeed, any number of components of a workstation
could be compromised to achieve this result.  It is infeasible to
fully reinstall the software on a computer between users due to time
constraints, and this reinstallation procedure could be modified
itself.  Therefore, all software on all workstations must be assumed
compromised.  

The obvious solution to software insecurity is hardware additions
which are more difficult to fake.  One currently popular solution is
the to install card readers on a computer, into which a user inserts
both a keycard and then types his password.  Only the combination of a
valid keycard and it's associated password will allow login onto
Athena, and so a password alone is worthless to Eve.  Unfortunately,
this is less secure than it initially seems, because Eve could
additionally read all information off the keycard and send that along
with the password, to later produce an identical keycard.  This
solution also means Athena Operations must install expensive new
hardware, and distribute keycards.  There is the additional hassle to all
users that a lost keycard denies access to Athena and the academic
resources that it provides.  Thus, a hardware solution would probably
not be acceptable to Athena Operations.

Kerberos was never intended to do more than secure transmission of
passwords over the network.  However, it provides no security on
either end of transmission.  Eve's attack occurs on the local
workstation itself, and thus is not protected against.  Because it is
preferable to distribute software in source format, protection through
a dificult interface is not possible.  The insecurity of every other
component on the local workstation makes protecting keystrokes
themselves impossible.  Finally, the impracticality of adding hardware
security to Athena workstations makes a written policy more practical
than a technological approach.
     
\end{document}
