Key Management Framework (KMF) generates automatic key exchange requests for supported cryptographic modules during the fresh installation or upgrade of the instance. manages the data encryption key locally for the instance.

Before you begin

A cryptographic module with a key must be created in both the target and source instances before using Key Exchange.

Role required: sn_kmf.cryptographic_manager

About this task

Key Exchange requests are initiated from the target instance.

Automatic Key Exchange is active by default when cloning an instance, where the property is cloned to the target instance. Along with KMF, configure system properties to manage how keys are handled during an instance clone:

  • Turn off automatic key exchange: Set the glide_encryption.auto_key_exchange.enabled property to false for recurring clone requests.
  • Send auto key exchange requests: Set this property to true.
Important: The base system property is set to true by default, meaning that automatic key exchange is activated when cloning an instance. This value must be set to false if you're using the Rekey ciphertext with Key Exchange or the recurring Key Exchange functionality. See Recurring Key Exchange walkthrough for additional details.

Procedure

  1. Navigate to All > Key Management > Resource Exchange Requests > New.
  2. On the form, fill in the fields.
    Table 1. Resource Exchange Request form fields
    NameDescription
    Exchange Frequency
    • Adhoc: Sends requests from the key target instance to the source instance. Enter the instance sys_id and the Host information for the Source. Not supported with Rekey of Key Exchange.
    • One Time Clone: One-time exchange of the keys from the source crypto specifications to the target instance.
    • Recurring Clone: Exchange keys from the selected source crypto specifications to the target instance on a defined recurring clone.
    <Source or Target> Instance sys_id
    • Adhoc: Enter the sys_id for the source instance to request the keys from.
    • One Time Clone, Recurring Clone: Enter the sys_id for the target instance that sends the requests.
      Tip: Enter stats.do in the application navigator to locate the instance ID.
    <Source or Target> Instance Host Enter the host location or name of the source or target instance.
    Tip: For example instanceA.service-now.com
    Crypto Specifications The keys from the crypto specification in a crypto module define the keys to clone. For both one-time and recurring clone requests, your instance automatically creates a Resource Exchange module access policy. You don’t need to configure a policy manually.
    Note: Select the lookup using list icon (Lookup using list icon.) to browse the available cryptographic specifications.
    Enable Rekeying after Key Imported Option to enable auto rekeying.
  3. Select Submit.
    If successful, a confirmation displays at the top of the form. The Requests table is updated with an entry of Request Pending in both the source instance and in the target instance. Open the Request Record to view the status of the request, the Imported Key Count, and the Total Key Count on the target or source host.
    Shows the request status for Requests.
  4. The pending request is accepted in the source instance to complete the exchange.

    At clone time, the module access policy on the source instance is invoked to auto-approve the request and send keys to the newly cloned target.

    Request Approved appears in the Status field on the Request record.

Result

After a key exchange is attempted, your non-production instance updates the protected.script.values.kmf.rekeyed system property. This property is visible in the System Properties [sys_properties] table after a key exchange is attempted. If the encryption using the exchanged key is successful, this property has a value of true. Otherwise, the property has a value of false. If the value is false, the instance will attempt to encrypt again the next day.