Re: [netconf] latest update to crypto-types and keystore drafts

[Balázs Kovács <[e-mail]>]

Hi Kent,

Yes, it makes.

I assume the “secret” symmetric key could be just equally configured as normal private-key since the key is coming from outside, depending on the taste of the client if it is just a NACM protected normal private-key or an encrypted key.

Br,
Balazs

From: Kent Watsen <[e-mail]>
Sent: Saturday, August 3, 2019 1:48 AM
To: Balázs Kovács <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] latest update to crypto-types and keystore drafts


Migrating configuration, including encrypted keys, from device-1 to device-2.

Preconditions:

    1) the client possesses a "secret" symmetric key
         - for this example, the key's clear-text value is known to the organization's
           "crypto officer", but it seems that it could as well be protected by an HSM.
         - this symmetric key value MAY be unique per device, region, or whatever
           boundary the organization chooses up to being globally shared by all
           devices.

    2) devices 1 & 2 each posses a unique asymmetric key that, e.g., may be
        associated with an secure device identity (e.g., IDevID)

+--------+           +----------+          +----------+
| client |           | device 1 |          | device 2 |
+--------+           +----------+          +----------+
    |                     |                     |
    | 1. get config       |                     |
    |-------------------->|                     |
    |                     |                     |
    | 2. scrub config     x                     |
    |-----------------+                         |
    |                 |                         |
    |<----------------+                         |
    |                                           |
    | 3. get tpm protected asymmetric key       |
    |------------------------------------------>|
    |                                           |
    | 4. encrypt operator's symmetric key       |
    |--------------------------------------+    |
    |                                      |    |
    |<-------------------------------------+    |
    |                                           |
    | 5. stitch encrypted op key into cfg       |
    |--------------------------------------+    |
    |                                      |    |
    |<-------------------------------------+    |
    |                                           |
    | 6. stitch additional info into cfg        |
    |--------------------------------------+    |
    |                                      |    |
    |<-------------------------------------+    |
    |                                           |
    | 7. set config                             |
    |------------------------------------------>|
    |                                           |
    |                                           |


Steps:

1. get config

    - the client gets the full configuration from device-1
    - this config would contain an entry for an encrypted operator key
    - this config may also contain an entry for the tpm protected key

2. scrub config

    - remove the encrypted operator key
    - remove the tpm protected key, if present

3. get tpm protected asymmetric key

    - the client gets the tpm protected key from device-2
    - this key's "private-key" value would be hidden
    - only the algorithm and public-key values are present

4. encrypt operator's symmetric key

    - using device-2's public-key, encrypt the operator's "secret" symmetric key
    - this is a local operation, using any crypto library

5. stitch encrypted op key into cfg

    - put the new encrypted operator key into the config

6. stitch additional info into cfg

    - put other, presumably non-migratable info into the config
      (e.g., node-locked licenses, etc.)

7. set config
    - set the new config onto device-2

Done.  Makes sense?

Kent // contributor




On Aug 2, 2019, at 8:41 AM, Balázs Kovács <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

One question regarding migratable keys. The conversation between Kent and Martin was concluded with this in the list:

“That said, the general recommendation, which would both be correct and avoid any potential failures, would be for the client to remove the device-specific and operator-wide keys first, leaving just the migratable keys in the config uploaded to the second device.”

I don’t see how migration is possible here. The migratable keys were generated on the first device and are encrypted with the operator key of the first device. Does the second device has a different operator key? If yes, the migrated encrypted keys cannot be decrypted by the second device.

Unless I misunderstand this statement (which I don’t see how to achieve in the model):

“3) privileged admin encrypts a well-known (secret to the organization) symmetric key using the public key from the manufacturer generated asymmetric key, and stores the result (i.e., <edit-config> into keystore.”

Does this well-known symmetric key mean that the symmetric key was generated externally thus its clear value must be configured to /ks:keystore/ks:asymmetric-keys/ks:asymmetric-key/ct:private-key? How is the operator key configured in clear to the second device so that it gets encrypted with the hidden manufacturer key of the second device?

Br,
Balazs