Now we're going to talk about some great fails and
successes of cryptography. The bottom line is be
sure you use it right. As an example, a vendor needed to secure
a connection over network. Basically the vendor was having his computer or her computer. I don't know the gender. Call another computer
and download information over a phone line. For various reasons they
couldn't use the Internet. The vendor wrote
its own version of SSL. Now whenever you hear "yes, I wrote this myself", alarm bell should go off in your head and now you're
about to see why. It turns out the vendor implemented the part
for confidentiality. So, they wanted to keep the
data flowing down secret. They didn't do the
integrity checking part. So, the protocol would send over the login name and
password to the system. You would then log in and
then the data would be downloaded over
a secure connection. The attack is fairly
straight forward. You have what's called a Man in the Middle or person
in the middle. Essentially, what
you do is you trick them into calling
a different computer. Computer answers, they send over their name and password
for the main machine. Then they download the data. Now the SSL secures the
data in transmission. But when it arrives,
it's unencrypted. I make my changes. Then using the login
and password they so kindly supplied to just log into the main machine and
download my stuff. All of a sudden none
of this is accurate. When this was tried by the way
it worked beautifully. The next slide shows
a few problems with this. The first one was the policy, the vendor got it wrong. The data which actually
was voting data, would be published within
10 minutes of receipt. In fact it may take
like a day or so but it wouldn't be published
and everyone would be able to see the data, which we're really
just vote counts. Confidentiality was completely irrelevant here. Who cares? Somebody saw it they might
gain five minutes or so. But how could they use that? Confidentiality was really
not important here. What was absolutely critical
was the integrity of the data because the counts
couldn't be altered. By the way for
whatever it's worth, it wouldn't have mattered
in the final result but it would have
created some confusion. Of course the version of
SSL they implemented, did not do integrity checking. If you protect for
confidentiality, you don't get integrity. You've got to do them both. That's exactly what
happened here. This by the way was preliminary counts from
a precinct for voting. Now it wouldn't have mattered in the end because the actual data, the vote counts were
actually determined from cards that were in the machine that would be brought
into election central. Problem is, the preliminary results that would be announced, were the ones coming from
this downloaded data. So, while you couldn't
change the results of the election you could sure
mess up a lot of things. The next example also
comes from voting. It's a perfect example of why you should never
write your own code, get a professional or use
a professional library. The idea here was that when you voted you have a
you have a ballot, which is just data on a computer. The problem is you
want to make sure that data is not altered. But you cannot sign
it with the voter. There's no way you can associate
a voter with a ballot. So what happens is
the system uses its private key to
encrypt the hash. That preserves that the
integrity of the ballot while protecting the voter
because there's no association between
the voter and the signature, it's between the machine
and the signature. So, the company
proposed the adding this and it was being analyzed by a group in Florida to
verify that yes it worked this good did what it should and didn't
impose any threats. So therefore we're
not going to worry. Therefore we can go
ahead and use this. Now election machines are
very interesting because the software can't be used
until it's certified. So, it was critical that
the step be passed. The next slide shows
how they did it. They generated what
was called the SHA-1 which is a hash function, generates a 160 bit hash or
digest as is called here. Then they would use
a public key scheme called RSA to encrypt the ballot. So the sign balance in
the second line in this the signature slide is the B and the signature
is the S 2048. That's the RSA signed digest 2048 bits.
But wait a minute. The hash is only a 160 bits and the RSA they were using
required 2048 bits. No problem, they
just padded it on the left with 1888 bits. If you put that
together that works out exactly the 2048 bits. So everything is fine, machine signs with
this private key. To verify the public key, the sign ballot take the
public key, decipher the hash, recompute the SHA-1 hash for B, and then compare the
160 bits you got from the hash to a 160 bits you
got from the signature. If they match you accepted. There's huge problem with
the way they did it. They very carefully checked those 160 bits but they didn't check
that the high-order bits where all zero. That's exactly what
the graduate students involved in this test did. They were able to generate fake ballots or rather
they were able to generate ballot signatures such that when you decipher them the bottom
160 bits would match. But instead of 1888 zeros, there would be some
one scattered. Since there was
no detection of that, the system accepted the ballot is valid even though it
had been tampered with. Another problem which was also interesting is that
the private key on all these systems was three. That's a very low number. Since it was the same
for all systems, if I got it on one
I get it on all. Okay. So what do you use to do this signatures in the encryption and cryptography in general? Use system functions. Up until recently desk script was a very good one to use because the desk was considered
quite strong. It is now considered different. Instead use a yes crypt or some systems have
called rijndael. This is a very strong cipher. It's the current standard. Also even better if you have a hardware that will
do crypto use that. Sometimes called device crypto. Typically what happens
is you plug it into your system and enter the key, and then the data is sent to the hardware device which encrypts it and
then gets sent out. Usually when you enter your key it is directly to the device or bypasses most trusted
path to the device. So, it's either impossible or highly unlikely your key
will be intercepted. There are several
other algorithms that are libraries that are very good. OpenSSL is excellent. Don't use the SSL part
using TLS part of course. But OpenSSL is
essentially freeware. It's now better supported than it was in the past
because of something called Heartbleed which was a rather serious bug that was essentially just
a silly accident. Anything by Peter
Gutmann is good. Peter is a very meticulous
and careful cryptographer. He is a library called cryptlib. That's another good one to use. RSA also markets
many libraries and the BSAFE 1 is the one that
most people would use. Just make sure it's BSAFE 2. Because BSAFE in before 2013 when BSAFE 2 came out
had a buffer overflow. Also the default
cryptographically secures random number generator
didn't work well. BSAFE 2 after 2013 all fixed. So again, this shows how hard it is to do cryptography
right when even professionals and
the RSA firm is one of the top firms in the field is
the people in their superb. But even they can make mistakes. So please don't write your own.