Page tree
Skip to end of metadata
Go to start of metadata

Images often need to make a call-out to the image vendor on boot, for instance to obtain licence keys. One challenge image vendors have is to determine whether that call-out comes from a real image, or someone impersonating that image, i.e. to verify the identity of the image. Whilst image vendors can use passwords or client side certificates to do this, there's always a risk that if these are discovered, someone has "the keys to the castle". The Image verification circumvents that risk.
Every image that exists on our platform is assigned a unique and secret key, which is only available to the Image Owner.

  • Each image has a random image key known only to the image provider.
  • Each server has a server key known to the customer and the VM.
  • FCO creates a cryptographic Image Server Hash from the Server Key and the Image Key.
  • The Server Key and Image Server Hash are presented in the metadata for the VM only.
  • The image calls back to the image provider, who verifies the hash against the Image Key.

Each server is also assigned a unique key, which is available to the owner of the server, and through the server's metadata.
We also compute a hash of these two, the Image Server Hash, and present that to the image using the metadata.
Assuming the image is appropriately locked using our Image Permissions feature, this can be passed to the image vendor together with the server's own key and the image's ID number. In case the image vendor has multiple images. The image vendor can then ascertain whether it is the right image making the call out. Obtaining one Image Server Hash would only allow impersonation of a single server.
This section describes the steps involved.

Image Creation

On creation of an image, the image is assigned a random Image Key (a 256 bit number represented as a 64 character hexadecimal string). The Image Key is available to the Image Owner (only) to read through the API using the ListImageTemplates call, but never appears within the metadata presented to any VM. This ensures it is private to the image owner.


Sample Image Key: 542246391f5ef2de58c66c21165c39672b703a272c9493b122edc75e47ba9d7a

Server Creation

On creation of a server, the server is assigned a random Server Key. Once again, a 256 bit number represented as a 64 character hexadecimal string. The Server Key forms part of the Server/System metadata and is available to read through the API by the server owner using the GetServer API call.
This is private to the server owner (as set out below), but as it forms part of the system metadata, it is also exposed to the server, and thus, potentially, the image provider.


Sample Server Key: 56dc5eb4661dac003f6019a07349d2b326c02ee2aca93e502fa0017f7cd0a6e0

On creation of the server, we also create an Image Server Hash. This is an SHA-256 hash of the ASCII concatenation of the hexadecimal Image Key and the hexadecimal Server Key. It too is presented as a 64 character hexadecimal string.
Like the Server Key, this forms part of the Server/System meta-data. As such it is available to read through the API by the server owner using the GetServer API call. It forms part of the system metadata, it is also exposed to the server, and thus, potentially, the image provider. Due to the one way nature of hashing, knowledge of the Image Server Hash, even when combined with the knowledge of the Server Key, will not allow a deduction of the Image Key.

Sample Image Server Hash: 74d796f800f7dfa8b40be760d207eede752e029556a7cd2927a53b01713a9659

Image Server Hash

The image may need to authenticate to the image provider's system. By this we mean make a call out to the image provider's own systems perhaps using http, for example, to obtain a license key.
The image provides the image ID from the metadata that will allow the image provider, who knows all the Image Keys they have generated, to deduce the Image Key, the Server Key and the Image Server Hash.
The image provider can then compare the Image Server Hash it generates with the one presented to authenticate the user. As only the server concerned can read the Image Server Hash, presentation of the (Server Key, Image Server Hash) tuple verifiably indicates that the Image Server Hash has been obtained from a server created with that image.
For example, the image provider might use a concatenation of the Image ID and the Server Key - possibly plus a prefix indicating "flexiant" - as a username, the Image Server Hash as a password, and use simple https authentication, verifying the image provider's SSL certificate to ensure that the VM is actually talking to the image provider.
As the Server Keys are unique, if this authentication is done periodically (rather than just on first boot) an Image Provider can get a good idea how many of their images are running simultaneously.
Obviously, the virtual machine needs to be appropriately locked to ensure that the Image Server Hash cannot be ascertained directly from the machine by the end user. 
This can be performed using Image Capabilities/Permissions (see the SetOtherImageCapabilities API call). The Image Server Hash should be sent over an encrypted session to ensure it isn't snooped.
However, should a customer or a third party obtain a copy of the Image Server Hash, the impact of such a leak is minimised. Whilst the Server Key/Image Server Hash tuple may be ported by a user with access to that virtual machine to another machine, the fact that multiple IP addresses are now requesting simultaneous authentication, with the same server ID is both detectable and traceable, and can result in a refusal to authenticate. Abusers can be quickly locked out by black-listing their Server Key. 
Compare this to the situation without this protection, where a shared secret of some sort is stored in the image: revealing that effectively gives away a 'master license key'.