Crypto Key Management Is Next Wave In Net Security
Posted by
Alexander Wolfe
September 09, 2009
Against the backdrop of rising malware threats and organized cybercriminal rings, a national cybersecurity initiative is taking shape which will bring a "locked down" mentality to the way we authenticate users, apps, and anyone or anything that touches a network. I'm talking about the Cryptographic Key Management (CKM) project that is being run out of the National Institute of Standards and Technology's Computer Security Division.
Of course, keys are not a new thing, they've long been used in what amounts to a sophisticated security handshake so that there's some assurance there's no bad guy on the other end before you grant network access or hand over information. It's also true, as a CKM report noted, that "nearly all Internet security protocols use cryptography for authentication, integrity and/or confidentiality."
What's different this time is that there's an overarching effort to figure out how to extend and implement keys so that they're universally applied on the Internet -- and thus by extension, on all networks everywhere -- not only for legacy stuff, but also in emerging areas of concern including cloud security, as well as the plugging of holes that routinely exist for wireless authentication.
This is no small thing because you're talking millions (multi-millions, actually) of users. You've also got the little problem that authentication breeds user difficulties, which in turn breeds avoidance of use of said security. (That's a long-winded way of saying that usability issues are going to play a big part in whether this all flies.)
To give you an idea of just how broad the CKM effort is -- and to hammer home the point that this isn't some ivory tower government initiative -- here's a partial list of the companies represented at a recent big CKM gathering, which was held in the Washington, D.C. area in June: Cisco, Citigroup, EMC, Google, EMC, HP, Microsoft and Sun. That's in addition to Presidential cybersecurity advisor types.
A big reason I'm certain the CKM is going to move forward is that all these constituencies are behind it. They're all coming at it from slightly different angles -- each is looking at a different aspect of security -- but at the end of the day, their broad interests coincide in getting it done. Let's take just two: the first a government perspective, the second a network community view from Vint Cerf.
Coming at it from the national security aspect is retired Navy Vice Admiral Mike McConnell, who's a former director of national intelligence and currently senior vice president of Booz Allen Hamilton. He had this bullet point in the minutes of NIST's June CKM meeting: "My prediction is that we're going to have a catastrophic event, and then we're going to be screaming," he wrote. "We have an opportunity to address and solve Internet problems before we have that anticipated catastrophic event."
From the perspective of readers of Network Computing, we've got the comments of TCP/IP co-creator Vint Cerf, who's currently chief Internet evangelist at Google. Cerf looks at CKM as a tool for validate DNS records. (Read him quoted in this interesting Christian Science Monitor story, "When the Internet breaks, who ya gonna call?")
One gets a detailed idea of just how much this impacts the network by reading Cerf's bullet points out of the minutes of that June CKM meeting. Here they are:
- Stronger authentication is needed for smart Internet "edge devices" (e.g. routers, routing
switches, integrated access devices) that provide authenticated access to the backbone
network, as well as stronger authentication for active processes, users, and digital objects,
with the implication that we need better access controls and two-part authenticators for
devices. - More vulnerabilities will be found in browsers, operating systems, routers, domain name
resolution processes, DPI-based attacks (e.g. against TCP) and MANETs (auto
configuration and overrun conditions). - Vulnerabilities include zombies, botnets, drive-by downloads, and zero day attacks.
- If hosts and routers must authenticate themselves, the overhead will be too high.
- Multiple identities with multiple identifiers for an individual are a must. Attribute
certificates stating the authorizations of differing identities must be supported. - Individual activities must not be confused with organizational activities.
- The roles for an individual must be supported, and role-based authentication is needed
(i.e., the authentication of a person will depend on the role that the person is attempting to
fill). Roles for processes must be similarly supported.
There's much more to be said about this, and I'll come back to it in an upcoming post. For now, I'll point you to the NIST page which discusses future CKM plans. (Go here.)
What's your take on CKM? Please leave a comment below or email me directly at alex@alexwolfe.net.
Follow me on Twitter at @awolfe58.
