Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Live Migration of Crypto Domains of local HSMs

IP.com Disclosure Number: IPCOM000239930D
Publication Date: 2014-Dec-16
Document File: 3 page(s) / 181K

Publishing Venue

The IP.com Prior Art Database

Abstract

Migration of Virtual Machine to a new physical instance including its crypto domains where each physical instance has its own local Hardware Security Modules.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

Live Migration of Crypto Domains of local HSMs

The migration of a Virtual Machine (VM) (110) to a new physical instance (210) includes its crypto domains where each physical instance (100 & 200) has its own local Hardware Security Modules (HSMs) (120 & 220). This is outside of High Availability (HA) scenarios.

The problem of cryptographic workloads is, that they depend on HSMs (120 & 220). So relocating the workload needs a mechanism for having access to the relevant crypto tokens in the target location.

Advantageous setup

To improve the security the roles of HSM Management Console (HMC) (400) users could to be

1


Page 02 of 3

separated into

• Role A (500) to set keys
• Role B (600) to setup "secret exchange group"

This is useful, to avoid that role B (600) can access to keys of role A (500). Both roles can be combined in one user or separated into multiple users.

The solution

At HSM setup time the HSMs(120 & 220) of the physical instances (100 & 200) are added to a "secret exchange group" via HMC that allows securely exchanging card secrets. The "secret exchange group" is defined by a distinct user role (in our embodiment role B (400) via HMC(600)). As a first step of the live migration the target HSM (220) has to be checked for available resources and matching preconditions. This can be done by two-face commit or alternatively via "blocking agents" that directly claim resources. The control instance (300) (e.g. initiated by user C (700)) triggers migration of the secrets from HSM A (120) to HSM B (220). The control instance (300) contacts the Hypervisor (130) in server 1 (100) in order to request the encrypted secrets from HSM A (120) to be transferred to HSM B (220). The Hypervisor (130) in Server 1 (100) delegates the request to HSM A (120). HSM A (120) encrypts the secrets of the source domain to be received by HSM B (220) and returns it to the Hypervisor (130) in server 1 (100). The Hypervisor (130) in Server 1 (100) transmits the encrypted secrets to the Control instance (300) (or alternatively direct to the target Hypervisor (230)). The Control instance (300) transmits the encrypted secrets to the Hypervisor (230) in server 2 (200)....