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.