Log in / Register
Home arrow Computer Science arrow Building the Infrastructure for Cloud Security
< Prev   CONTENTS   Next >

Security of Mt. Wilson

Security is integral to the Mt. Wilson platform. The ultimate objective of an adversary of Mt. Wilson would be to subvert and control the outcome of the attestation by:

• Spoofing the trust agent to attain a fake TPM quote

• Compromising the Mt. Wilson attestation server to subvert signed content

• Spoofing the Mt. Wilson attestation server to fake a signed content

• Hacking the whitelists

• Compromising the data on the network and repositories

Figure 4-7 shows the threat model considered during the design of Mt. Wilson, with articulation of the consequences when the adversary accomplishes the attack and possible mitigations implemented. We summarize the mitigating actions against the threats listed above.

Figure 4-7. Mt. Wilson threat analysis

• Registered API client calls (signed with their private key) can be verified by the Mt. Wilson attestation server using the corresponding public key. These keys get generated and stored by the API client during the registration process. Users are encouraged to secure their private keys using a password-based mechanism, at minimum. The Mt. Wilson Java API Client Library includes convenient functions for this purpose, using the Java Key store format to secure the private keys.

• The communication channels between the hosts and the users are encrypted using SSL. When a new user registers with Mt. Wilson, the Mt. Wilson SSL TLS certificate is verified and stored by the user to secure subsequent communication between the user and Mt. Wilson. The trust agent stores its SSL TLS certificate with Mt. Wilson upon registration of a new host to secure all future communication between Mt. Wilson and the trust agent.

• Trust agents store their TLS private keys in a password-protected Java Keystore file.

• Users are allowed to call into APIs based on their existing roles. Users request roles during registration with Mt. Wilson and these are approved by the Mt. Wilson administrator.

• The attestation status of the hosts is returned as signed SAML assertions that can be verified by the end consumer. The

Mt. Wilson SAML certificate is stored by users when they register with Mt. Wilson in order to later verify SAML assertions.

• A public and private key pair is the preferred authentication mechanism for management of the whitelist and host trust policies.

Mt. Wilson Trust, Whitelisting, and Management APIs

Mt. Wilson provides a rich set of APIs for all interactions with it. In fact, the primary communication with the Mt. Wilson attestation authority is via authenticated APIs. There are five categories of APIs:

1. Provisioning APIs, for registering hosts and requesting AIKs.

2. Query APIs, the trust APIs that requesting entities (requesters/ API clients) invoke to get a trust assertion.

3. Reporting APIs, providing details about hosts registered with Mt. Wilson, including the current measurements and the whitelists.

4. Automation APIs, allowing an administrator to easily register all hosts within a VMware cluster or create an MLE using a known-good host in a trusted environment.

5. Management APIs, enabling registering users, managing their authorized roles, and downloading various certificates managed by Mt. Wilson.

Calls to the API must be sent over SSL TLS. All APIs are REST-based. Mt. Wilson APIs use a client-server model without third-party intervention to provide authentication. The authentication model is very similar to OAuth 1.0 and HTTP Digest, and it provides a stateless scheme for use with clusters and load balancers. However, it does not work with URL-rewriting proxies because the URL is covered by the client's signature. Every API client—that is, any entity invoking the APIs, such as portals, schedulers, other subsystems or policy engines—needs two RSA keys, as follows:

API signing key. The public portion of the API signing key is stored in the Mt. Wilson keystore. The API client retains the private portion of this key in an encrypted and secure keystore

SAML assertion validation key. This is the public portion of the Mt. Wilson SAML signing key and is stored with the API client

• An API client registers with Mt.Wilson via a credential management server to acquire the RSA keys. A Mt.Wilson instance can register a number of API clients.

Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >
Business & Finance
Computer Science
Language & Literature
Political science