[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ekmi] Re: [P1619-3] OASIS EKMI Article in InformationWeek
Arshad, I have not seen the IEEE 1619.3 specification and so I cannot comment on how it would compare to EKMI. You seem to imply that it is limited and not a standard that could be elevated above the storage device architecture to a more generic architecture (does the EKMI have access to the 1619.3 specification or other documentation on the mission and direction of this WG?). It would seem to me that ultimately one standard could be applied and service the enterprise at whatever level any particular software or hardware vendor chooses, be that at the application level or down at the device level. In terms of creating an industry standard for symmetric key management I feel we should not be bias towards any one vision of where the cryptographic engine would architecturally reside, and is there a reason would we assume that the EKMI protocol could not be implemented at the hardware level or the 1619.3 protocol at the application level? Ultimately, it is my opinion that the industry will standardize on a single protocol, and the candidates would seem to be either the EKMI or the 1619.3 (or some extension to one or the other). Again, having not seen anything specific on the 1619.3 specification it was my hope that EKMI would ultimately envelope both the PKI and 1619.3 protocols into a single architectural standard for truly end-to-end enterprise key management. Also I believe you are missing one of the key market factors that has been driving the industry towards providing cryptographic solutions, and that is the news press's recent focus on identity theft and on how businesses and governments are apt to loose very private and confidential information. Certainly these losses can occur in a variety of ways, but the most publicized losses have been either in lost or stolen backup tapes, lost or stolen lap tops or hackers accessing e-commerce information through web sites or other public access points. All of these issues can be addressed by encrypting at either the application or the hardware level, but it would seem to me that the issue of hacker attacks is very problematic because at some point in any e-commerce application the data has to be in the clear and if it is in the clear in real time then there will always be a possible exposure that cryptography can not address by itself. The other issues of lost tapes and other storage devices such as lap tops can be very securely addressed with cryptography, especially in the area of lost tapes but also with the loss of other storage devices that use tamper sensitive technologies to zero key information if necessary. Here again, cryptography could be done at any level from the application to the device but as you and I discussed most storage devices today store data in compressed format to save space and cipher text does not compress very well. This is an argument for encrypting at the device level rather than the application level. Then there are also the issue of the impact cryptography has on a server's valuable processor cycles. The bottom line is I would not count on winning a standards war based upon the argument that encryption at the storage device level is a flawed and short lived vision. Rather than fighting to win that battle, I would rather us be fighting to marry our visions and our efforts over the next few years to merge EKMI, PKI and 1619.3 if at all possible. The DNS-like aspects of the EKMI vision are very attractive and could enhance 1619.3, and there may be aspects of 1619.3 that could benefit the EKMI. Tim Bruce Principal Software Architect, Development 5465 Legacy Drive Plano, Tx. 75024 tel: 214-473-1917 fax: 214-473-1069 -----Original Message----- From: Arshad Noor [mailto:arshad.noor@strongauth.com] Sent: Tuesday, July 01, 2008 8:33 PM To: Luther Martin Cc: P1619-3@LISTSERV.IEEE.ORG; ekmi; Ramon Krikken; Trent Henry; Eric Maiwald; jon.oltsik@enterprisestrategygroup.com Subject: [ekmi] Re: [P1619-3] OASIS EKMI Article in InformationWeek [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&w ords=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=2 08800937 > > > 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]