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

Mt. Wilson Programming Examples

In this section, we look at how to invoke the attestation APIs to get trust information about a server in a data center. Figure 4-11 shows the high-level steps involved in setting up the system and configuring it for use.

Figure 4-11. Mt. Wilson high-level programming steps

After the installation of the Mt.Wilson server and trust agent on the hosts, required only for Xen or KVM hosts, users need to include the .jar file provided as part of the API toolkit in their project and import the following packages:


import*; import*; import;


API Client Registration Process

Before the user can make any API calls into the system, the user has to register and the access has to be approved. Below are steps for how to register with Mt. Wilson and how to make API calls after the registration has been accepted. The following code creates a

keystore “test1.jks” in the home directory. The keystore contains an RSA keypair that is used to authenticate the API calls to the system. The keystore would also contain the Mt. Wilson SSL certificate and SAML signing certificate, which are downloaded from the server.

File directory = new File(System.getProperty("user.home", ".")); String username = "test1"; // you choose a username

String password = "changeit"; // you choose a password

URL server = new URL(""); // attestation server String[] roles = new String[] { "Attestation", "Whitelist" }; KeystoreUtil.createUserInDirectory(directory, username, password, server, roles);

After the request is created, the user has to contact the system administrator to approve the access request (offline step). After the request is approved, based upon the roles the user has, appropriate APIs can be executed, such as maintaining a whitelist, adding hosts, and obtaining a trust assertion on one or more hosts.

To use the API, the user needs first to create an ApiClient object configured with the credentials and the attestation server. Notice that the variables directory, username, password, and servers are the same as what was used during registration.

File directory = new File(System.getProperty("user.home", ".")); String username = "test1"; // username created during registration String password = "changeit"; // password created during registration URL server = new URL("");

ApiClient apiClientObj = KeystoreUtil.clientForUserInDirectory(directory, username, password, server);

Once an APIClient object is created, the user can use that to configure whitelists and also to register the hosts with Mt. Wilson so that they attest when challenged.

Whitelisting and Host Registration

Here's some sample code for how to create a whitelist and register the host with Mt. Wilson—for VMware ESXi hosts:

TxtHostRecord gkvHostObj = new TxtHostRecord(); gkvHostObj.HostName = "hostname-in-vcenter"; gkvHostObj.AddOn_Connection_String = "vmware:;Username;Password";

boolean configureWhiteList = apiClientObj.configureWhiteList(gkvHostObj);

boolean registerHost = apiClientObj.registerHost(gkvHostObj);

Verify Trust: Trust Attestation

Once hosts are registered with Mt Wilson, it is now possible to request a trust assertion in SAML format using getSamlForHost. You can verify the signature on the assertion and get easy access to the details using verifyTrustAssertion.

Note if you are directly calling into the REsT APis, you have to implement the

verification of the sAMl assertion using the sAMl certificate that needs to be downloaded explicity. The APi toolkit downloads this certificate as part of the registration itself.

String samlForHost = apiClientObj.getSamlForHost(new Hostname("hostname-invcenter"));

TrustAssertion trustAssertion = apiClientObj.verifyTrustAssertion(samlForHost); if(trustAssertion.isValid()) {

for(String attr : trustAssertion.getAttributeNames()) System.out.println("Attr:"+attr+":"+trustAssertion.



As shown in this above example, using the API Client Library is a very simple way of using the Mt. Wilson attestation mechanism. The Mt. Wilson software is being licensed by many ISV and CSPs to integrate trust into the software and service offerings. More and more organizations are moving to clouds, and they are asking for assurance of trust of the platform on which their workloads are running; they are also asking the CSPs to provide proof of a chain of trust. The attestation solution is fast becoming a critical security component in the security toolset. For developers favoring a DIY approach, the opensource OpenAttestation (OAT) is a good starting point for attestation.

Note oAT is the open-source version of Mt. Wilson code, and is provided and maintained

by intel Corporation. you can download the documentation, code, and installation/deployment scripts from the oAT website.


In this chapter we covered attestation as a foundational function of trusted computing environments that provides proof of trustability and auditability of trust for various computing devices. We covered the TCG remote attestation protocol, and we described the vision and architecture of Intel's Trust Attestation Platform, followed by a detailed look one of the first attestation solutions, called Mt. Wilson. The chapter reviewed the security architecture and the attestation APIs, and explained how requesters of trust and attestation information can invoke these APIs and process the assertions for decision making. There are many usages in data centers that would utilize the attestation information. As shown in the previous chapter, attestation is used in the creation of trusted compute pools and the attestation-based policy enforcement in these pools.

Thus, attestation can be used to provide granular trust-based access control to consumer and BYOD devices, and the kind of services they can access within the cloud data centers. Attestation as a security management component will become an integral component of virtualization and cloud management, and it's becoming a critical requirement in cloud data centers to assert the integrity and compliance of platforms and systems. ISVs and security management vendors may also start offering it as a SaaS offering. We believe that, over time, value-added capabilities will emerge around the attestation function and will enable monetization possibilities.

Chapter 5 will introduce a new concept and control, called hardware-assisted asset tag, which can be used to provide isolation, segregation, placement, and migration control of workload execution in multi-tenant cloud environments. Additionally, as a specialization of asset tags, geolocation/geo-tagging can be enabled to definitively provide increased visibility to the physical geolocation of the server, which may enable many controls that require hardware-based roots of trust to assert the location of workloads and data. These attributes and the associated controls are dependent on the boot integrity assertion of the platform; hence, they become a great adjacency to trusted compute pools and boot integrity.

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