{"id":64,"date":"2014-06-29T18:28:09","date_gmt":"2014-06-29T18:28:09","guid":{"rendered":"http:\/\/credelius.com\/credelius\/?p=64"},"modified":"2014-06-29T18:39:13","modified_gmt":"2014-06-29T18:39:13","slug":"cloud-hsm-security-part3","status":"publish","type":"post","link":"https:\/\/credelius.com\/credelius\/?p=64","title":{"rendered":"Cloud HSM Security – Part3"},"content":{"rendered":"

Cloud HSM – Part 3: Passing Secrets<\/h2>\n

As mentioned in “Cloud HSM – Part 2”<\/a>, to start using an HSM deployed to a cloud, you’ll need to find a way of passing credentials such as a partition level password (or PIN) and a client side certificate to all HSM’s clients.<\/p>\n

 <\/p>\n

Passing this kind of secrets using common AWS mechanisms like S3 buckets<\/a>, user data<\/a> or baking them to AMI<\/a>‘s might not be such a good idea if you consider that common “we do not trust them” mentality described in “Cloud HSM – Part1”<\/a><\/p>\n

 <\/p>\n

General Approach<\/h2>\n

Since a VM in any environment, including AWS, has a number of attributes (or metadata), some of which are unique for a VM, these attributes can be used to verify an instance that is making a claim by sending an assertion to a verifying party (VP).<\/p>\n

 <\/p>\n

In static VM environments the attributes can be used to create a VM’s fingerprint and then compare that fingerprint against a white list of all trusted fingerprints stored on a VP.<\/p>\n

 <\/p>\n

Creating\u00a0 “white list” for all instances running in an auto-scaling group (ASG<\/a>) doesn’t seem possible though due a volatile nature of some attributes such as internal\/external host names and instance ID. A way around would be to make an instance verification dynamic. Fortunately, AWS API does have all necessary functions to implement a dynamic credential-less EC2<\/a> instance validation and next section provides the details.<\/p>\n

Credential-less Dynamic EC2 Instance Verification<\/h2>\n

In this approach an EC2 client would need to collect instance parameters that are both available through a meta-data interfaces on a client, which could be considered as an asserting party (AP) and through a an AWS API on a server, which can be considered as a relying party (RP). Yet another special parameter that can be accessed on both AP and RP is an internal or external IP address, which is not exactly metadata, but can be an essential part of the instance verification process.<\/p>\n

 <\/p>\n

I’m intentionally using a SAML<\/a> terminology here, since an authentication and authorization scenarios described below look very similar to those of SAML.<\/p>\n

 <\/p>\n

Here are parameters that an asserting party can fetch through a meta-data interface (e.g. through http:\/\/169.254.169.254\/latest\/meta-data in the ‘us-east’ region):<\/p>\n

 <\/p>\n