Noted cryptographer on SSL, encryption and cloud computing

Noted cryptographer on SSL, encryption and cloud computing

Noted cryptographer on SSL, encryption and cloud computing

Date: Mar 10, 2010

In this wide ranging interview, cryptographer, Taher Elgamal, chief security officer of Axway Inc. and the inventor and initial driving force behind SSL, explains how applications may be better adapted to defend against attacks and how cloud computing may alter data protection and authentication. The SSL protocol will be updated to prevent man-in-the-middle attacks, but researchers need to find better ways to prevent malware from getting on PCs in the first place, Elgamal said. Better security at the browser layer and a greater focus on Web application security could help prevent future attacks, he said. End-to-end encryption is a marketing term that doesn't hold much weight, Elgamal said.


Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.   

Noted cryptographer on SSL, encryption and cloud computing

Taher Elgamal: So there are several "attacks" that people have cited
that have had issues with SSL. There is really only one real one that
has to do with SSL as a protocol, and everything else has to do with
either implementation issues, wrong choice of a cypher suite, client trust
model problems. So the biggest problem is you can present any certificate
in front of any user in the browser, the user says OK, and then you've got
to trust something that you shouldn't have trusted, and then everything
breaks loose.

The one issue with SSL, the protocol that has been discovered, has
to do with the key. If the session keys are being re-negotiated, there's
an opportunity for somebody in the middle to actually leak in clear
text information at the TCP level and make themselves look like they're
in the middle, so they can actually terminate both sides. That's what the
man in the middle is.

Number one, there has to be a piece of malware set in our machine
some place to do this. So if you have a clean machine there is just
nothing that's going to do that. So if you have malware you could, actually,
in fact, do this, and then you could listen to the keys and negotiate both
keys on both sides and make yourself look like you're the man in the middle.
This is something we really never thought of, I mean, to be completely honest,
because trying to write a protocol that prevents a piece of malware to do
something is a very interesting thing. It's something that just showed up
these days, right?

ITF is taking care of that, and there will be newer versions of SSL and
we'll take care of this. The reality of the world is that if you actually have
malware sitting on a machine, there's a lot more interesting things to do
than be in the middle of an SSL transaction because it can actually sit from
the beginning of the transaction and listen to everything anyway. Yes, the
protocol has to be fixed. There's no question about this, but we have to
prevent malwares from actually going to the machine, which is the bigger
problem here, in my own opinion.

Reporter: Well, that gets down to software security in an extent when you
talked about, in the past, about browser issues being targeted by
attackers. Now it seems to be more web-based issues, whether it be
web-based applications, websites, and what have you. What, in your
estimation, can be done?

Taher Elgamal: In the security world, everything is like cat and mouse.
Five years from now we'll be talking about a completely different set of
things by the way, and I'm going on the record saying that. There will always
be new kinds of attacks that "the good guys" have never thought of before.
You discover new things and you actually basically sit down together and
come up with solutions, so there are solutions coming up with all the “new”
web attacks, bot nets, and the like. And actually, this show is a great place
to look at these. There are actually several of those here, and I think some
of them work in different ways, and as a customer you can pick and choose.

I think the browsers need work, and it's very difficult to tell a browser company
- I did work for one at some point in the past - to actually change their browser
because there could be malware. But browsers do pose an interesting issue,
and you need more security at the browser layer itself to actually really
protect the consumer. It's kind of amazing actually. It's easier to protect an
enterprise because there is IT staff in an enterprise and you know that bot
nets are not cool, so you actually want to buy equipment to prevent bot nets
from propagating inside the enterprise. But the consumer sitting at home does
not benefit from that at all being that that thing doesn't see it. So there does
need to be something else, either at the service provider level or somebody
that is serving the Internet into these homes to actually do the same thing and
that's a harder sell.

So, the attacks that we know today, we have ways to actually defend
and because we know what these attacks do and most of them sneak
their way into machines and sit for a while and then at some point they
wake up and they call some plays, that we say call home in security
language. So we know what these things are, and sometimes we know
the home location. Sometimes, we know the protocol, so we can actually
detect that this particular machine is trying to call home to do something
wrong, and if you have the right defense, then that call does not go through
basically. So you're actually preventing the harm. We haven't prevented
the bot net from going onto the machine, but we prevented the harm from
happening at the back-end. And there will be new things in the future, I
guarantee you, because once we find the real solution to all of these things,
something else will pop up.

Reporter: A panel of government officials yesterday had a discussion
about privacy issues. Two of the officials talked a bit about getting ISPs
to do deep-packet inspection, whether it be the government through
regulators forcing them to do it, or whether they should do it themselves.
Where do you stand on that? Could that be a reality?

Taher Elgamal: I think it could be a reality, whether we actually like
that fact or not. The idea, there are two different things that people talk
about, there's privacy and there's anonymity, and they're actually different
requirements. Privacy means that there is particular private communication
that you want to communicate with your friend some place, and there's really
nobody's business to listen on that conversation, right? The problem with
the Internet is that you cannot differentiate between the honest conversation
and the not so honest one, right? So, government is in the business of
protecting citizens. That's why we pay them the money. And part of
protection is to find these rings of bad people trying to do bad things of all,
all different kinds of bad things, right?

Now, does that imply that you have to listen to all conversations, to all,
that all people are doing? And the answer is probably no, because in the
intelligence world, they actually know who you suspect that they're trying to
do bad things and if you find out that a person that was thought off as honest
is trying to get access to these people, then maybe that's a good reason to spy
on this particular thing or listen to that conversation. But if two people are sitting
in their home in Wisconsin trying to talk to each other, there is really no reason
to try to listen. When you say deep-packet inspection, it does not mean that it's
deep for every single packet that goes on every single wire at all times, that you
can actually still do targeted deep-packet inspections on things that you suspect.
You can actually mix the two.

Q: This kind of goes back to what you were just talking about with
software security. I listened to an interview that you gave with somebody,
and you said that currently the industry, the security industry you were
referring to, is all about embedding infrastructure on top of all existing
applications and networks and what have you. You were referring to the
fact that maybe, applications should be built with better defenses or be
able to detect attacks and defend themselves, and you were also referring
to DLP. So let's take the first part here. Is that maybe, the future,
self-defending applications?

Taher Elgamal: I hope so, actually, is the answer. It's much easier
within a constrained range of what an application does between people
who care and the data they communicate and try to impose whatever
rules you want to impose on this application, whether it's a business
application or private application, whatever it is. So, we do have the ability,
we do have the technology to write better applications, and I think these will
pop up more as this cloud thing people talk about here comes to reality.
I think it's still fantasy at this point and time but it will come to reality. And the
only way, not only way, the best way to deploy good Cloud security is to
actually embed it in the application because the application knows the users,
the application knows the data, and if it's sensitive it knows what you do with it.
If it's not sensitive, it broadcasts it. It knows who's authorized.

It knows who's not authorized and if you use the application right, it
doesn't matter where you deploy it. You can deploy it locally. You can
deploy it between two companies. You can deploy it up in the Cloud.
You can deploy it wherever you want, and it knows how to protect its
people and it knows how to protect its data and it knows how to report on
compliance with certain things because compliance is here to stay. We
will always need to be compliant with something or another.

So my philosophy says that we need to teach our engineers to write good
applications. It sounds simple. It's actually not because I went to school,
and nobody at school teaches you how to do these things. But I know
there are a lot of companies that are actually putting a lot of money and
effort into teaching their engineers what it means to write better applications.

On top of that, we need to actually expand the scope of an application.
So you mentioned DLP. So the data that is sensitive is much, much
easier to detect in the application because the application knows this is
a card number or a Social Security number because it actually does do that.
It's much, much easier in the application to say, "Any time you store one
of these things, just encrypt it before you store it". The encryption technology's
been out for a very long time. The application will have the keys that certain
individuals will be authorized to get, so the Cloud guy's not going to have
access to anything. So the clients from the Cloud provider or the hosting
environment or the ISP, whoever is hosting this thing, doesn't actually have
exposure because the application is right. And the same thing applies to
defending from threats.

Now there are some threats that are infrastructure-oriented, and I think the
infrastructure knows how to deal with this. There are some attacks that are
at the network level, so that will always need to stay, but attacks that are
trying to get access to particular pieces of data, to ship them out to some
random country are better being created, stored and defended within the
application that understands the concept. Then if you do all of this then
there's no need, I think you're referring to the DLP additional layer of protection
thing. It actually doesn't do what you think it does because it's a lot harder to
scan all the data that runs around in a big enterprise and try to make sense
out of this. This is really a single credit card number or this is 10,000 of them
and are the names in the same thing or not. It's not trivial. The application
actually knows. We actually have access to all this stuff. So whatever
application you use to create and store these things, have it deal with it.
If another application needs to pick the data and do other processing on it,
then supply the keys through a key management mechanism and we know
how to do that, too.

Q: We were talking about this just before we began recording, end to
end encryption. What is your take about that term?

Taher Elgamal: I think it means whatever you want it to mean, I suppose.
So in the old days, there is actually history for why that term came back to
life. In the old days when we had link encrypters, so the only encryption we
knew how to do some 25 years ago was point to point, two entities that want
to just have secret conversation. So you actually did encryption at the link
layer, even below TCP, and you encrypted the entire thing and we called it
end to end because this end was in this enterprise and the other end was
the other enterprise and that was the end of the discussion.

Now the Internet comes along, the number of ends between the first end
and the second end is probably thousands. So in the Internet world when
you say end to end it's kind of meaningless, unfortunately, and the
implementations are unfortunately even worse. I think practically what it
means is it's whatever first end and whatever second end I get my hands
on to do the encryption. Unfortunately, it is not where you really need it.
It's sort of where you can do it, and I know that there's a lot of push in the
credit card industry to apply encryption on transmitting credit cards so that
we don't suffer from these exploits and that's a really good thing. I think
encryption is very good technology to use there.

I think we're over selling and over marketing certain things before we actually
do the real solution, and because in a credit card transaction there are seven
or eight different entities that actually process that thing until it gets back to the
original bank and back out again. If the ends, the real ends of the transaction,
then you haven't actually gained a whole lot. So you can have a fictitious end
in the middle of this thing and yes, that card is encrypted from A to B, but C
is the real end then back-end is not encrypted and then what exactly have
you done?

I love marketing people. I love sales. We all live for revenue. You can have
that on the video. You know, I represent a vendor. I'm not shy about it, and
we all have deficiencies, so over selling is just not a great thing because
we're over promising, and security is one of these things that if you think
you've got it because you were sold on it and then you get another exploit
the next week, that's really, really not a great thing to actually deal with,
and it will happen, guaranteed.

Q: One last question here, tokenization. That's another area that we're
hearing in the payment industry right now, but it's been around for quite
some time.

Taher Elgamal: So, from an encrypto guy, tokenization is just a special form of
encryption in my own kind of funny philosophy. So what you need to process
cards is a consistent representation of the card number so that all the software
runs, and then maybe you can map it back at the end. So the true end to
end encryption if you actually implement it correctly from the cardholder
all the way to the issuing bank is actually a token. It's just the token is
being generated by the encryption algorithm and the token gets passed
around. Nobody ever sees the real number. It goes all the way back to the
issuing bank. The issuing bank says, "I'm going to decrypt that to get the
original card number" and then you pass it back out, so that's perfect.

You can do the same thing with a table. So the tokenization is basically
a big, huge table that says, "If this is the card number, this what you pass
instead" and if you put the tables in the right places you can actually get
to do something like this, the current implementations of tokens are only
in the Internet side of stuff. It's only at the front end. So it only happens
at the merchant, at the payment processor of the Internet stuff. Once it
gets to the bank networks, there is no token anymore. It's actually the
real card number being processed back. So tokenization is useful if
you implement it correctly, but again, it's a special form of encryption.
It's all there is.

Instead of trying to keep the encryption keys protected because this is
how we decrypt the end to end thing, you need to keep that big table
protected because that has the keys to the kingdom. And if you know
how to keep a big table protected from a hacker to come in and
understand that map between the token and the number, then you're
actually doing OK.

Q: Well, thank you very much.

Taher Elgamal: Thank you.

More on Web Browser Security

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: