Re: [P1619-3] OASIS EKMI Article in InformationWeek

[Arshad Noor <arshad.noor@strongauth.com>]

[Note:  The protocol used within a Symmetric Key Management System
(SKMS) - one of two major components of an EKMI (the other being a
PKI) - is the Symmetric Key Services Markup Language (SKSML).]

To date, there is only one implementation of the DRAFT 1 version of
the SKSML protocol (an open-source implementation called StrongKey,
produced by our company and available at www.strongkey.org).

The protocol, after much discussion within the OASIS TC over the
last 18 months, is at DRAFT 6 and is scheduled to be released to the
general internet for review and comments within the next 10-14 days
(it is under ballot within the committee as we speak).

While confidentiality agreements with our customers preclude us from
mentioning where it is being used, I will point you to some publicly
available statistics on the number of downloads of StrongKey at
SourceForge.net:

http://sourceforge.net/search/?type_of_search=soft&type_of_search=soft&words=strongkey

If we assume that a mere 2-3% of the downloads are in use, that makes
30-45 EKMI's using the DRAFT 1 protocol.  Not much, I agree, when you
compare it to the millions of downloads of software like the JDK,
Apache, JBoss, etc.; but we're talking about a paradigm-shift in
cryptographic key management here - a highly specialized niche - so
it will take time to register.

I will also point you to the OASIS EKMI TC home-page, where you can
see the publicly-visible supporters of the protocol, which includes:

- CA
- FundServ (a Canadian company)
- MISMO (the Mortgage Industry Association in the US)
- PrimeKey (a Swedish company)
- Red Hat
- the US Department of Defense
- Wave Systems and
- Wells Fargo.

What is not visible - unless you are an OASIS member - is that two
of the three largest software companies in the world, two of the three
largest security software companies in the world, and two very large
consulting firms, are all Observers on the Technical Committee.

While the number of EKMI TC members certainly is smaller than the
1619.3 WG, there is a broader acceptance across business sectors for
the vision of EKMI.

Given this, I would like to make a suggestion to the storage vendors
in the P1619.3 WG.  (Please don't shoot the messenger because of the
unpopularity of this message I'm about to give) :-).

It is my personal belief that the market for storage-device based
encryption will dry up within 3-5 years.  Why?  Because of the
following:

An application stack on a running server resembles something like the
following diagram (I've simplified it for brevity - real applications
typically have more layers in the stack):

+-----------------------+
|   Application Layer   |  <-- Focus of OASIS EKMI TC efforts
+-----------------------+
|   Network Layer       |
+-----------------------+
|   Web-server Layer    |
+-----------------------+
|   Application Server  |
+-----------------------+
|   Database Layer      |
+-----------------------+
|   Operating System    |
+-----------------------+
|   Storage Device      |  <-- Focus of IEEE P1619.3 WG efforts
+-----------------------+

While transparently encrypting/decrypting data as it goes in and out
of the storage device makes it easy for enterprises in the short-term,
it does not protect them from attacks on plaintext in any of the layers
above the storage device.  The only threat that encrypted storage
devices protect against is, theft.

For an always-on, operational system in a data-center, this is an
insufficient counter-measure against data-breaches, since an attacker
may be reading plaintext at ANY of the layers above the storage device
and land the company on the front-pages of the Wall Street Journal and
CNN in spite of the encrypted storage device.

This is not to say that the OASIS effort eliminates the problem - it
does not.  However, it minimizes the attack-surface to the minimum
possible target, and allows the enterprise to not have to duplicate
protecting data in any of the layers below the application layer.

Given that many application developers already have to protect their
applications from X-site scripting, SQL Injection, and a host of new
application-specific vulnerabilities, adding encryption to the list
of things to do is going to become a formality.

The OASIS effort is also planning on educating IT Auditors through
ISACA about potential vulnerabilities in the stack (as shown above),
so ignorance on the part of developers/managers will not be an excuse
for too long if they want to comply with SOX, GLBA, PCI-DSS, HIPAA,
FISMA, PIPEDA, EU Directive, etc.

It is my belief that once ISVs and customers recognize this problem,
they will start modifying their applications to encrypt data at the
application layer.  Once we're past the tipping-point on that, there
will be little need for duplicating encryption on storage-devices.

Notwithstanding this, I believe there is a place for the P1619.3
protocol in the short-medium term - it is to take the keys and polices
supplied by an EKMI and push it down to the storage devices for
storage-based encryption in the intervening years before applications
encrypt data directly.  Towards that end, what is needed is a compact
binary protocol that can be used between the Management Console of the
Storage environment and the storage device itself, while the MC itself
becomes an EKMI client and uses the SKSML protocol to get the keys
and policies.

It is my belief that the WS-MAN based XML protocol being worked on by
the P1619.3 WG will create confusion in the marketplace.  While this
will serve the key-management vendors in the WG (who are not members
of the OASIS effort), it neither serves the industry nor the storage
vendors.

Since the market for encrypted storage-devices is not a long-lived one,
how much effort do storage vendors want to put into building XML-based
protocols, libraries, tools and MC applications, when another effort has
reasonable acceptance and traction, and can be easily used to meet the
goals of the storage industry?  If storage-industry budgets allow for
duplicating the OASIS work and dealing with the mixed-marketing messages
that customers receive, that's a different issue.  However, if you want
to optimize your investments while making the most of the opportunity
that presents itself over the next 3-5 years, then it makes sense to do
the minimum necessary work on the binary protocol and use the OASIS
XML-based protocol where it makes sense.

Arshad Noor
StrongAuth,Inc.

Luther Martin wrote:
> How many vendors have implemented EKMI? Are there any users of it? Knowing how it has succeeded or failed might provide some particularly useful insights for P1619.3.
> 
> ________________________________
> From: Gary Palgon [gpalgon@NUBRIDGES.COM]
> Sent: Tuesday, July 01, 2008 7:22 AM
> To: P1619-3@LISTSERV.IEEE.ORG
> Subject: [P1619-3] OASIS EKMI Article in InformationWeek
> 
> Oasis' open Enterprise Key Management Infrastructure initiative promises less-complex encryption. But will vendors get on board?
> 
> http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937
> 
> 
> Gary Palgon
> VP Product Management
> gpalgon@nubridges.com<UrlBlockedError.aspx>
> nuBridges, Inc.  |  1000 Abernathy Road  |  Suite 250  |  Atlanta GA USA 30328
> Tel:  +1 770 730 3592  |  Fax:  +1 770 730 3784
> 
> www.nubridges.com<http://www.nubridges.com>
> The Secure eBusiness Authority