Panel Discussion: The Future of HSMs and New Technology for Hardware Based Security Solutions (A31a)
Tony Cox, Cryptsoft, Australia;
Thorsten Groetker CTO, Utimaco;
Tim Hudson, Cryptsoft, Australia;
Todd Moore, Gemalto, United States; Robert Burns, Thales, United States
All of the panelists have a strong background in cryptography and HSMs. Starting out by defining HSMs, a secure container for secure information. Needs extra protection, may have acceleration, may be rack mounted, smart card, USB, PCMCIA card, appliance, etc. - maybe even software based.
Or, is it a meaningless term? It could be virtual, it could be a phone, it could be in the cloud - anything you feel is better than things that aren't HSMs, Tim postured.
Thorsten disagrees - there has to be a wall and have only one door and strong authentication.
Bob noted that overloading the term does cause confusion, but should not dilute what are good hardware based HSMs.
Tim notes that people buy their HSMs by their brand, not always for their features and a deep evaluation of the underlying project. Thorstein agrees that may happen in some cases, or they may be looking for a particular protection profile or FIPS 140 level. Bob notes that branding and loyalty plays a part, but does think people look at features. Tim said he's been in customer conversations where people are influenced by the color of the lights or box.
Bob mentioned that it's not easy to install an HSM, so you're only doing it because you need it or are required to have it.
The entire panel seems to agree (minus some tongue in cheek humor) that easier to configure is important, more likely to be installed correctly. But, still a way to go - customers are always asking for how to do this faster and more easily. This may be leading to more cloud based HSMs.
Bob - There are trade offs - we can't tell them what their risk profile is and what configuration is right for them.
On security, Thorstein notes that some customers may be required to use older algorithms, and he recommends doing risk assessments, and just because you are writing a compliant (say "PKCS#11) application does not mean it is secure. Having standards based makes migrating and interoperability a lot easier, but it does not always meet all of your business needs. This is why most HSM vendors make their own SDK as well.
Bob agrees, that a universal API means punting on some tough problems. As a vendor you can choose being fully compliant, or locking in your customer to your API. PKCS#11 is great, but it is a C API - where is the future going? Need more language choices.
Tony asks - given the leadership of PKCS#11 team in the room, what could we do better? Tim makes a comment on KMIP, Bob agrees it's important but still not fully portable. Bob thinks there's an opportunity to look at the problem in a different way for PKCS#11 - the implementation is locked into C, which is no longer on the growth curve for our customers. People what the more managed languages, so people are creating shims over PKCS#11.
Thorstein likes the aggregate commands in KMIP, but still not perfect.
Todd noted we need RESTful based APIs, and there are gaps in what the standards are offering.
Tim notes that he doesn't think the vendors are always clear with their customers that they are going down a path of getting locked in. Bob disagrees that vendors are doing this on purpose.
Valerie couldn't help but note that standards are only as good as the people that contribute to them, and if the vendors are finding gaps in PKCS#11 or KMIP, please bring those gaps to the committees and join them and help to improve them.
Tim notes that there are more hardware protections available to software developers (ARM trust zones and Intel's SGX). Bob notes that they are interesting technologies, but not a true HSM, not as strong of a container. Additionally, key progeny and ownership is an issue as those keys are owned by specific companies. It would be good to expand this, particularly in the cloud space.
Thorstein believes the jury is still out - interesting approaches, but not quite there for putting the level of trust you would put into a level 3 HSM. If a US / American vendor has a kill switch that could stop your whole system from running, it's much less appealing for those of us outside of the US. Worry about what other things could be exposed in that way - it's like a good new cipher; need to look at it and how it is implemented.
Todd notes these technologies are starting to get very interesting because they can go into edge devices and cloud services. We are excited to see how this are going to grow. Vendors still need to provide key life cycle guidance and standards compliance and making sure CIA are in place.
Thorstein notes it is a good building block of an embedded HSM, but he'd still be nervous about sharing the CPU.
Tim says it sounds like it's better than software alone, but not up to these vendor's HSMs. Bob remembers the time that HSMs used to be needed to get any decent performance, and they are already very different just 15 years later and expects another incarnation in 15 years.
Todd notes that Google just launched a silo that would leverage these technologies and managed SDKs. Bob agrees that middleware can benefit from technologies like SGX. Tim notes standards are still very important, and wants users to communicate this to vendors.
Lots more of excellent conversation.
Posts
