Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

[CC-ing Henk, who knows a little about TPMs]


Hi Balazs,

> The ‘generate-hidden-key’ action is meant for cases when the key must be generated in the device and not the operator is configuring it. The ‘generate-hidden-key’ is said to produce a ‘permanently-hidden’ asymmetric key. The description of ‘permanently-hidden’ is as follows:
>  
>                 "The private key is inaccessible due to being
>                   protected by the system (e.g., a cryptographic
>                   hardware module).  It is not possible to
>                   configure a permanently hidden key, as a real
>                   private key value must be set.  Permanently
>                   hidden keys cannot be archived or backed up.";
>  
> Th second sentence doesn’t sound right. I can create a permanently hidden key any time by calling the ‘generate-hidden-key’ action,

True, but *when* the action is called is not pertinent, right?

> or if the device or the model allows I could even switch to non-hidden key, I believe, by providing the binary.

How would you get the binary?   Yes, some implementations, as a hack, MAY not actually use a cryptographic processor, but that is besides the point.   The intent with this action statement is that a cryptographic processor IS used and that the private key is forever hidden.


> So I find the second sentence irrelevant in this description.
>  
> More importantly, I find the “Permanently hidden keys cannot be archived or backed up” statement false. Isn’t that implementation specific how archiving is done? If a device puts the hidden keys on some storage, it may still be possible to back them up.

Maybe.  I am aware that e.g., TPMs, have the ability to backup a key but, I think that doing so necessitates that the key is encrypted with the SRK (storage root key) such that only the same TPM chip can decode it (Henk, can you check me on this statement?).  To this end, I agree that the last sentence is too strongly worded.

> I would prefer to remove this sentence and leave backup considerations to implementations.

Remove or replace, let's keep the conversation going. 


> Could these changes be done?

Sure, pending the outcome of this thread.


Kent // contributor