I had the opportunity to attend the inaugural Key Management Summit this week in Baltimore, MD. The IEEE hosted it in conjunction with the Mass Storage Systems and Technologies (MSST) conference as the IEEE P1619.3 key management standard (under development) is part of the IEEE Security in Storage Working Group.
Overall, the conference was interesting and enlightening, but not perhaps in the way that I'd hoped. In general, it really highlighted the dysfunctional nature of IEEE standards committees, as well as how far removed these groups can be from reality. It was intriguing to the see the contrast of 1619 against the OASIS EKMI technical committee, which itself had to demonstrate business value and buy-in just to be launched; against the IETF committees, which were similarly dysfunctional; and against the ANSI X9 committee, that has apparently covered much of the ground under discussion, or leading up to the key management topic, but which has played almost no direct role in any of the other committees because their focus is technically limited just to the financial services industry (despite a lack of involvement with BITS).
Toward the end of the second day of the conference, I jotted down the following notes about the conference in reflection on all that had passed:
- The conference seemed to generally represent a mix of the arcane and the boring. Very rarely was there much truly interesting information, and there certainly was a broad lack of understanding of business requirements.
- The conference truly highlighted key problems with the standards committees. That is to say:
- ANSI X9 has developed a ton of useful information, much of which has fed directly into NIST standards and guidelines. However, none of the standards committees seem to be making use of this info, nor does X9 seem interested in reaching out and participating. This seems partly due to X9's focus on the financial services industry, but it was even found that X9 has not been involved with BITS, which provides heavy support to that industry. At one point, someone angrily got up and demanded to know why X9 wasn't being involved, to which my response was "wait, how many people were even aware of the X9 work?" The answer was about 50% of the people in the room. Of course, one arrogant person then added on "oh, we're aware of them, but they haven't solved this problem either."
- The 1619.3 standard committee is bogged down by insanely academic discussions on messaging, costing orgs time and money as they wait for these standards to emerge. What's worse, committees like .3 haven't even clearly defined the problem space that they're attacking, to the degree that their scope has changed over the past few years. While still heavily focused on key mgmt for storage systems, they've since added XML messaging support, which has in and of itself introduced holy wars.
- The OASIS EKMI TC was mocked by the .3 folks for not being academic enough, even though EKMI matches what business want and need. It was quite ironic (or maybe moronic) that these big brains thought that key mgmt revolved exclusively around storage systems, completely ignoring the world of applications and databases.
- The standards committees seemed to be a case of too many vendors working in a vacuum. They weren't really working to solve a problem that necessarily needed solving. Worse, they hadn't well-defined the problem they were solving. Worse yet, they couldn't even agree on what the terminology was around the general problem space. Part of this also related to cryptographers bandying about the term "security" as it's defined in their context, not from the risk management perspective.
- Oh, my, the egos! One is quickly reminded of the negative image of the ivory towers of academia, far-removed from the realities of the business world (case in point, check this guy out - and this was one of the key leaders for 1619.3!). Lots of in-fighting, too, among these elitest snobs. Oh, and btw, don't try confronting these jerks because they just get dismissive. It's really tough for them to deal with the rest of the world when nobody is as smart as they are, you know.
- None of the standards organizations were considering the risk management perspective. OASIS came the closest to doing this in setting a business case and requiring business sponsorship to launch the TC. However, even then, decisions weren't being made based on what the best impact would be for reducing risk. Instead, much of the discussions were oriented toward vendor implementations, solving problems of the vendors rather than of the customers.
- Being coupled to the MSST conference was not useful. There was too much of a focus on storage and an outright rejection of legitimate business needs around applications and databases. Many people and vendors actually completely missed the point, too. They were largely interested in things like encrypting tape backups. This problem has been solved. Managing keys for these environments really does represent a significant problem, but one that needs to be abstracted and genericized.
- Who do these standards benefit? Who are they supposed to benefit? What is the relevance of the standards process? I could (and may) write a post on this separately, but I strongly question the value of some standards organizations now after this conference.
- Old school technologists place heavy blame on developers for screwing things up and not being trustworthy. They don't believe that, given reasonable toolkits, developers will do the right thing as it pertains to encryption, security, and key management. Nothing, however, could be further from the truth. If you provide developers with an easier way to solve a problem, they will be all over it, because, as with sysadmins, they are always interested in achieving the desired outcome with the least effort possible.
- There's definitely a generation gap in understanding and tackling the problem space. There's lots of in-fighting and finger-pointing and general distrust. No wonder nothing seems to be getting done!
- The problem space itself is not well-defined. What in the world is a Key Management System (or Service)? What all should it do? One could argue that it should manage the entire lifecycle of a key, but then one gets into questions about key provisioning and distribution, and if those are considered inclusive components of key management. There are other related questions about whether tracking related metadata, such as key identifiers and their association to segments of data, is also a desired function of a KMS. This strikes me as another good blogging topic that I should explore later this week.
- One question raised during the conference was whether exposure of metadata about the keys and KMS constituted a viable threat to the security of the system. The hard-core crypto types insisted on an obscurity approach to security, ignoring that protocols based on standards are easily understood and attacked, regardless of the availability of metadata. It struck me as another misguided attempt to derail efforts that didn't match a given person's perspective. Moreoever, it was a ham-fisted use of risk management language to attack a solution without actually analyzing a given threat scenario. This was the only case where the term "risk" was raised during the summit, and it wasn't even used properly.
- As already noted, the conference had far too much focus oni tape backups and mass storage. This was understandable given it's relation to the MSST workshops, but it was not useful. Applications of cryptography are not key management problems, per se.
- Lastly, it was interesting to note that major vendors Sun and HP had interesting approaches to key management, but they were proprietary and targeted only at their tape backup solutions. Their interest in P1619.3 seemed to be limited to how key management clients (aka "backup agents") could securely connect into their overall backup solution. So sad to see good work pigeonholed like that. It was just as bad as hearing of all the ANSI X9 work and how it was so blindered on financial services that they were missing opportunities to be involved in IEEE, OASIS, and IETF.
