%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentstyle[12pt,twoside,alltt]{article}
% \documentstyle[12pt,twoside,alltt,psfig]{article}
% is the line you should use IF you're using EPS images.
% make sure to copy the psfig.sty file into the directory with
% the latex document however.
\textwidth=6in
\oddsidemargin=0.25in
\evensidemargin=0.25in
\topmargin=-0.1in
\footskip=0.8in
\parindent=0.0cm
\parskip=0.3cm
\textheight=8.00in
\setcounter{tocdepth} {3}
\setcounter{secnumdepth} {2}
\sloppy

\newenvironment{proof}{\noindent{\bf Proof:}}{\qed\bigskip}
\newenvironment{proof_sketch}{\noindent{\bf Sketch of 
Proof}\hspace*{1em}}{\qed\bigskip}

\newtheorem{theorem}{Theorem}
\newtheorem{corollary}{Corollary}
\newtheorem{lemma}{Lemma}
\newtheorem{claim}{Claim}
\newtheorem{fact}{Fact}
\newtheorem{definition}{Definition}
\newtheorem{assumption}{Assumption}
\newtheorem{observation}{Observation}
\newtheorem{example}{Example}
\newcommand{\qed}{\rule{7pt}{7pt}}

\newcommand{\lecture}[4]{
\pagestyle{headings}
\thispagestyle{plain}
\newpage
\noindent
\begin{center}
\framebox{
\vbox{
\hbox to 5.75in { {\bf 6.857 Computer and Network Security
\hfill Fall Term, 1997}  }
\vspace{4mm}
\hbox to 5.75in { {\Large \hfill Lecture #1 : #2 \hfill} }
\vspace{2mm}
\hbox to 5.75in { {\it Lecturer: #3 \hfill Scribe: #4} }
}
}
\end{center}
\markboth{Lecture #1 : #2}{Lecture #1 : #2}
\vspace*{4mm}
}

\begin{document}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Lecture command takes 4 arguments:
%		ordinal number of the lecure
%		date of the lecure
%		lecturer
%		scribe---that is you
%
\lecture{24}{Decmeber 2, 1997}{Yoav Yerushalmi}{Eytan Adar} 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% For theorems, lemmas, definitions, remarks, etc. use commands
% \begin{theorem} .... \end{theorem} 
% \begin{definition} ... \end{definition} 
% \begin{proof} ... \end{proof}
% and so on ...
%
% If you want to insert figures in your notes do the following: 
% 1) Prepare your figures using your favourite graphic editor
% 	for example idraw or xfig
% 2) Save your pictures in PostScript form using the following convention
% 	notes-nn-fig-mm.eps where nn is the number of the lecture you 
% 	are scribing and mm is the sequential number of the picture in the 
% 	notes
% 3) Insert the following block in your LaTeX code in the place you 
% 	want to insert the figure. HOWEVER, leave it commented or follow
%	  the instructions at the top if you want to latex it on Athena. 
%
% \begin{figure}[h]
% \begin{center}
% \mbox{\psfig{figure=notes-nn-fig-mm.eps}}
% \caption{A very nice picture.}
% \label{fig:mm}
% \end{center}
% \end{figure}
%
% 	of course the picture will not show up when you compile and 
% 	print your notes, but don't worry the TA will take care of it. 
% 4) When you mail the TA the LaTeX code mail him/her the PostScript
%	files for the figures as well 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Your notes start here!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Today's Topics}

\begin{itemize}
\item Digital Cash
\item Fingerprinting
\end{itemize}

\section{Digital Cash}

One of our main interests in providing digital cash is that the cash
should in some ways remain anonymous.  That is, Alice should be able to
ask the bank to generate the cash, but the bank should not be able to
attribute the cash to Alice when it's done.  This effect can be achieved
with blinding.

{\bf Blinding - review}
\begin{itemize}
\item Alice generates a message M and sends M to the Bank
	\begin{itemize}
	\item trick is that M = $r^d$ $m$ ($r$ is some random value)
	\end{itemize}	
\item The Bank calculates $m_{c}$ = $(r^d m)^e$ mod n and send $m_{c}$ back
to Alice.
\item Alice divides out $r$: ($r$ $m^e$ mod n)($r^{-1}$ mod n) = $m^e$ mod
n, and she has a bank signed digital cash message. 
\end{itemize}

{\bf Problem 1}

The first problem in the basic scheme is Alice's ability to generate any
message that she wants.  She may tell the bank that her message is
``this is \$5'' but instead she sends ``this is \$5000.''  The bank has
no way of knowing this, and will sign either message gladly (but will be
out \$4995 in the latter case).

There are two solutions to this problem:

\begin{itemize}
\item The bank can have a limited number of possible currency values:
\$1, \$5, \$10, etc.  The bank will then make different signatures for
each value, and will sign Alice's message with the appropriate signature
no matter what the message says.  This, however, limits the number of
choice for currency to some finite set.  Ideally, we would like to be
able to get any value signed.
\item The second, ``nicer,'' solution works as follows: Alice creates
100 messages, each with the same m, but differnt random values $r$.  She
sends the messages to the bank.  The bank, in turn, asks for 99 $r$
values and decrypts the 99 messages.  The bank can then verify that
Alice's messages are the same, say ``this is \$5.'' and will sign the
100th message which it did not open.  The probability of Alice fooling
the bank is small, and the first problem is solved.
\end{itemize}

{\bf Problem 2}

The second problem is how to prevent Alice from double-spending (using
the same signed cash twice).  The solution to this is to use some unique
serial number $y$, where $y \in \{0,1\}^k$.  We can then find out what
Alice has double spent, but...

{\bf Problem 3}

Although we can now find out which bill was double-spent, Alice is still
untrackable by either the merchant nor the bank.  As a possible solution
we introduce a new cryptographic method that allows for ``holes'' in the
message which can be filled in after encryption has occured. So Alice's
encrypted message can have 32 holes in it that can be set to either 0 or
1 at a later time.  When Alice purchases something from the merchant,
the merchant can ask Alice to encode a special message which the
merchant generates in her payment. If the merchant keeps track of the
money he receives he can make sure that Alice doesn't double spend.  But
this doesn't solve the general problem of Alice double-spending.

There are a number of extensions to this scheme, that can help

\begin{itemize}
\item The merchant can always check back with the bank before completing
a transaction.  However this doesn't necessarily scale because the
merchant would have to keep talking to the bank for every miniscule
transaction.  This ``check'' might cost more than the value of the sale.
\item We can also have a hardware solution to the problem in which we
use a money card.  It is then very hard to double spend if the card is
smart enough
\item A better method uses a scheme in which a message is divided into
two halves.  The message can not be reconstructed without both halves.
So for example, we can take the message ``I am Alice'' and break it up
into $h_1$ and $h_2$.  If you don't have $h_1$ or $h_2$ you can't read
the message.  We do this by using XOR, and each $h_1$ and $h_2$ are
one-time-pads.  $m \oplus h_1 = h_2$.
\end{itemize}

Our new scheme now works like this:  

\begin{itemize}
\item Let Alice's message, m = ``I am Alice''
\item Pick the left side, $L \in \{0,1\}^l$, and the right side is $R =
m \oplus L$
\item Alice generates m left messages and m corresponding right
messages for each of the 100 money orders (as specified above).  
She commits each $L_i$ and $R_i$ (called the Identity strings) and sends
them to the bank (using a bit-commitement scheme).   She also appends
the uniquness/serial number string (also discussed above) to each message.
\item The bank asks Alice to open 99 of the money orders, and all the
identity strings.
\item As before, the bank sends back the one unopened, but signed, money
order back to Alice.
\item Alice goes and spends her money
\item The merhant sends back an m length bit stream indicating which
halves of the identity strings to open.  So say at position 5, the bit
stream has value 0, Alice will open $L_5$.  If the value was 1 she would
open $R_5$.
\item The merhant takes the money order to the bank.  The bank verifies
that the uniqueness string is indeed unique.  If not, the bank can open
the identity strings and find out who's been double-spending (by taking
the ``spent'' value and the newly submitted value, XORing them, and out
pops Alice's name').
\end{itemize}

The final thing we want to add to this scheme is a timestamp to the
digital cash.  We want to prevent a merchant holding on to money until
the bank forgets which money it has seen before (as it may have to do if
it becomes expensive to store the messages indefinitely).  If the
merchant doesn't collect after a certain time, they lose the money.

\section{Fingerprinting}

Fingerprinting refers to the generalized concept of using identifying
marks to identify the owner of some object.  For example, mapmakers
would like to prevent other mapmakers from copying their hard work.
They would create fake streets our map features and hide them somewhere
in their maps in some vague spot.  If someone were to ever copy their
maps it would be easy to point out the probability of the same fake
street or feature appearing in another mapmaker's work would be very
slim.  More generally, we would like to be able to fingerprint maps,
books, audio, movies, pictures, programs, chips, and anything else whose
ownership (intellectual property we value).

For books we can hide fingerprint information by chaning the kerning
(space between letters), spacing between words and lines.  However,
these methods don't work for things like OCRing where the text is
scanned and converted into some other form.  For pictures, we can enrypt
messages by flipping and modifying pixels in the picture.  For example,
we can modify the contrast of pixel (5,10) by some value that is
undetectable to the eye, but easily detectable by analyzing the picture
electronically.  

For programs we have a number of methods to fingerprint:

\begin{itemize}
\item We can add something to the end of the program that doesn't get
executed.  
\item We can hide something in the code itself, like an array that
doesn't mean anything but has values that we remember.  The same
technique can be applied to computer chips by hiding non-functioning
parts in chip design.
\item Flip NOPs and real commands in some way that doesn't change
program performance but is not the ``natural'' compiled way.
\end{itemize}

Ideally we would like to avoid having people know about or modify
fingerprint information.  There are two types of fingerprinting:
\begin{itemize}
\item {\bf C-frameproof} Given C evil users, they can't get together to
frame another user not in their group.
\item {\bf C-secure} Given C evil users, they can't invent another
working fingerprint
\end{itemize}

Let's say we have three users A, B, and C and each has something that is
fingerprinted.  The fingerprint is a 3 bit value, and each of A, B, and
C has 100, 010, and 001 respectively.  If users A and B get together and
diff the two objects the have, the only difference they will find is the
first two bits.  They won't be able to figure out that a signature is 3
bits, and won't be able to frame user C.  Worse, if they generate
something that's only two bits different, we can blame it on the only
two users who could have figured out that the first 2 bits are part of a
print: users A and B.  The is C-frameproof but no C-secure because users
A and B can generate values outside the set of they know, or can make the
fingerprint 000 so that no two people can be blamed.  The problem is
that we require lots of bits for people (specifically, we need as many
bits as we have people).  The partial solution is to compress the
fingerpring, which isn't perfectly secure, but can help with some
probability.  

Here's an example of C-secure scheme.  Say we have 4 users, A, B, C, and
D. Each has the following embeded fingerprint strings.
\begin{itemize}
\item User A: 111 111 111
\item User B: 000 111 111
\item User C: 000 000 111
\item User D: 000 000 000
\end{itemize}

We permute and hide each of the strings randomly in the document we give
to each user.  If any of them gather together they will only find some
limited number of ``different'' bits.  Say users A and C work together.
They will only figure out that the first 6 bits are different.  If they
try to invent some new message we will be able to at least catch one of
them.  

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Your notes end here!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}

