Re: [P1619-3] OASIS EKMI Article in InformationWeek
Hi Arshad,
I think you are somewhat comparing apples and oranges when talking about
"application layer encryption" and "encrypting data on the device.
I absolutely agree that currently applications are not secure. When I
use the term "applications" I mean application software running atop an
OS on a given hardware platform. I would also say that the problem of
application security is really the problem of OS security. It's the job
of the OS to make sure that Applications can run with the correct
security properties (eg. non-interference, memory isolation, executable
integrity, etc. etc). Afterall, an application is written against the
given OS. Which is why today there is great interest in client-side
hardware-assisted virtualization. Just having an Application
encrypt/decrypt its own data (down through the file system) is not going
to add much to the security of the application (specially when an virus
has attached itself to the app:)
However, IMHO when you look at the efforts in IEEE1619.3 it is not
entirely accurate to compare against "application security" because
IEEE1619.3 is not aiming at securing applications.
Here are some observations about what I have seen (in the small corner
of my world). I believe some (or all) of these items below are
motivating many of the vendors inside IEEE1619.3:
(a) Security moving down into the hardware-layer:
I believe there in undeniable evidence that many security-related
functions (e.g. encryption, hashing, signing) is moving down into the
hardware layer. Some examples include the cheap TPM hardware now found
on most new machines (over 100 million units shipped), the great
interest in hardware Full Drive Encryption (FDE) or "self-encrypting"
hard-disk-drive (HDD) units, software-FDEs and other platform-level
*cheap* crypto-hardware. Included here would be the various security
hardware used by backend storage devices and networked storage devices
(eg. crypto hardware in controllers, tape-backup units, etc). Many of
the later type of vendors are members of SNIA, TCG SSWG, T10/T13 and
IEEE1619.
PS. It is important not to confuse Software-FDEs (that provide
software-based volume encryption) with Application-level encryption (as
shown by Arshad's diagram).
(b) Current flavor - Data-at-Rest (DAR) protection:
CEOs losing laptops is a huge deal. See the Laptop Losers Hall of Shame.
I believe this is one of the main driving forces in the industry
interest in data encryption currently. The interest may die-off soon (or
later) but it happens to be the current flavor. Related also are stolen
backup tapes.
http://www.networkworld.com/slideshows/2008/052208-laptop-losers.html
(c) DAR protection requires Enterprise management:
Hardwares that perform DAR protection require lifecycle management
(including key management). This where 1619.3 comes in. They need to be
tied into the existing Enterprise management systems.
So, I think there is a place for device-level encryption, it requires
management (and key mgmt) and it will soon be a part of daily enterprise
systems and network management. Its our job to make it as painless and
transparent to the IT guy :)
Regards.
/thomas/
> -----Original Message-----
> From: Arshad Noor [mailto:arshad.noor@xxxxxxxxxxxxxx]
> Sent: Wednesday, July 02, 2008 4:25 PM
> To: P1619-3@xxxxxxxxxxxxxxxxx
> Subject: Re: [P1619-3] OASIS EKMI Article in InformationWeek
>
> 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.
> >
> >
>