[Cryptech Tech] Fwd: Question regarding Trusted Path Authentication

[Okubo, Tomofumi]

Dear Peter,

Thank you for your comment.

While I understand your argument regarding complexity, I was hoping the
open design HSM could be used for key management operations that require
multi person control. If you are implying that those who require stringent
key management operation are not the intended audience, I totally
understand.

I thought it would be nice if the open design HSM also supports the
functions that is required to perform proper key management along with
quality crypto. That way, high-value PKI services that require stringent
security controls could adopt the open design HSM which I think would be
revolutionary.

FWIW, I can help document key management practices (how to run key
ceremonies and how to handle HSMs) that ships with open design HSM if that
helps to reduce the complexity and improve user experience.

Thanks and best regards,
Tomofumi




On 12/17/14, 8:21 PM, "Peter Gutmann" <pgut001 at cs.auckland.ac.nz> wrote:

>Randy Bush <randy at psg.com> quotes Tomofumi Okubo <tomokubo at verisign.com>:
>
>>The question I had during the session is regarding the Trusted Path
>>Authentication.  This is popular for HSM usage in military, financial
>>institutions and commercial CAs. They use Trusted Path Authentication to
>>split the authority to access to the HSM. During the initialization of
>>the 
>>HSM, multiple credentials are created using the secret sharing scheme so
>>that 
>>it requires M out of N people to perform an operation on the HSM. Per
>>FIPS140, this does not necessarily have to use physical credentials so
>>it 
>>shouldn¹t be too messy to implement.
>
>It's actually really, really hard to implement, hard to document, and
>hard to 
>use.  I use this in my book as an example of something that seems quite
>simple 
>(and desirable to have as a feature) until you start thinking about it,
>and 
>then the more you think about it the harder it gets.  If you don't
>believe me, 
>sit down and write out the API required, the data formats, the order and
>form 
>in which the API is called to set things up, the user interface both for
>when 
>things go right and when they go wrong, the procedures required to use
>it, and 
>so on.
>
>This is a feature that can go on the wishlist if required, but a long,
>long 
>way down.
>
>Peter.