You are only going to see me say this once about
an HSM so pay attention because I will deny it in the future.
There are cases where application, file system,
OS, software, TPM or even the best HSM based encryption cannot meet the
performance requirements of a given application (notice I did not say
security here).
In these cases encryption will be performed
where it can best meet the needs of the application. It is extremely
likely that encryption will happen at two or more points in the path so
that data can be processed optimally by the application using all of
the available resources.
In other words encryption will be performed
where it is best suited to be done based first on business and then the
applications requirements.
In a lot of cases the CPU's are under utilized
and it will be fine in those systems. As blades and other shared
resource computing system are put it place it remains to be seen if
this will still be the case (most likely will be but I refuse to commit
to one side or the other here).
The long term concept is to come up with a key
management service that can address management of all keys under one
umbrella. Arguing about which is best here is kind of moot until the
full set of use cases is understood (doubtful in our lifetime).
I agree with Matt that it will be good to go to
the Key Management Summit and get all views and hopefully in the
process we can get some good feedback about things none of us has
thought about yet.
Bob L.
ROBERT A. (BOB)
LOCKHART
Senior Systems Architect
nCIPHER
_______________________________________
Arshad Noor wrote:
Laszlo,
The reason I keep saying that there is no *long-term* reason for
encrypting data on the device (or even the wire) is because of
my belief in the paradigm that data needs to be encrypted and
decrypted only by the resources that actually use data - the
applications - and not the resources that store or transport it.
The primary reason we have so many problems with securing IT
infrastructure today, is because, for the last 20 years, we've
been focusing on securing the network as a proxy for securing
applications and data. This is because network device vendors
have sold IT the notion that protecting the perimeter was all
that was required, and you could leave all your computer hosts,
applications and data alone. Very seductive. Thousands of
companies bought into the vision and now look where we are:
- Those who have firewalls must, typically, have port 25 and
port 80 open to do business - and guess what? The attackers
use precisely those ports to compromise live systems;
- Applications are weak and insecure - many developers are still
trying to protect against x-site scripting and SQL-injection
attacks on the internet. And now - are you ready? - we have
XML-injection attacks already surfacing against the new breed
of SOA-based applications because the security paradigm I'm
talking about is still out of focus for most IT organizations;
And the industry is now getting ready to sell IT shops the same
bag of goods - that its OK to continue ignoring the application
and data - the stuff that really matters - as long as we secure
the media and the wire.
Application developers have gotten increasingly security-ignorant
while attackers are getting increasingly sophisticated (one attack
I read about even installs the attackers self-signed Root CA X509
certificate on the target's PC and then redirects them to a cloned
web-site of a financial institution with their own SSL certificate,
thereby eliminating any security warnings about unknown CAs or
sites while having the "lock" icon clearly ON! All this for a
phishing attack. Most developers do not even understand how SSL
works, let alone code something as sophisticated as this).
If companies want to be secure, they need to stop focusing on the
perimeter and devices and focus on the applications and data. This
is the only long-term viable strategy, IMO.
Once they've secured their applications and data, they can ignore
the transport and media layers. A POS application encrypts CCN in
the application, passes the ciphertext to the DB, which stores the
ciphertext as a blob in the table on the storage media. Neither
the wire, the DB nor the media care what the blob means; only the
authorized application with the decryption key does.
Securing an application isn't just about encrypting data. Its also
about authenticating the resource that's trying to access the data;
its about determining the authorization of the resource trying to
access the data and finally, its also about determining the integrity
of the data being accessed. An application needs to do all this.
With the right combination of digital signatures and encryption
all the threats you enumerate are addressed.
You should download StrongKey and see what I'm talking about;
everything I've described in this e-mail was implemented two years
ago. This is the paradigm application developers need to move to
if IT organizations want long-term security benefits at the lowest
TCO. Just imagine, if all the applications developed over the last
20 years had followed this paradigm, we wouldn't even need firewalls
today.
Arshad Noor
StrongAuth, Inc.
Laszlo Hars wrote:
I understand that EKMI does not care where
and how the keys are used. I had
issues with your other statements, like saying that there is no need
for
encryption in the device level (P1619.0-2).
You seem to agree that encryption in the transport layer is very
different
from encryption in storage. In the later case, you cannot change the
key
very often or use arbitrary IV's, without a large loss of storage
capacity,
or the need of transferring a large amount of non-user data from a key
server, slowing the disks down. The need of encryption in the storage
devices remains for practical reasons: speed, capacity, security,
complexity...
Once the payload has been encrypted, then
you can ignore threats to that
data at all other layers of the stack.
This is putting your head in the sand. Such systems can still leak
valuable
information: the equality of data blocks, the frequency of updates of
certain records, the location of system files, database records... We
could
face malleability issues: messages could be replayed, data mixed and
matched, program data patched, documents falsified, etc. Our goal
should
not be just to satisfy certain vaguely formulated laws, but to provide
(facilitate) comprehensive security.
|