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

Mt. Wilson APIs

Figures 4-8 and 4-9 show the core APIs for the Mt. Wilson provisioning and trust query API and the management and whitelisting API.

Figure 4-8. Provisioning and trust query API

Figure 4-9. Management and whitelisting API

To facilitate interoperability, consistency, and seamless integration, we expect the industry to converge toward a standardized set of APIs related to attestation. We offer these as a starting point for the industry to help drive interoperability across different attestation solution implementations.

The API Request Specification

All API calls are http requests with one required header: “Authorization: X509

<authentication-info>”. Any unauthorized request is challenged with a standard header: “WWW-Authenticate: X509 <challenge-info>”.

Each API request includes the following parameters:

• Fingerprint (base64-encoded SHA-256 digest of the client API certificate)

• Signature method (RSA-SHA256)

• Time stamp from standard http Date header (RFC 822 date format)

• Client nonce (base64-encoded) in http X-Nonce header

• http request method

• Signature over the above and also:

• Original request URL including query string

• http message body (required, use empty string if not applicable)

• Any other custom headers specified besides Date and

X-Nonce in the “headers” field of the Authorization line, in the order specified

• Signature created using client's RSA private key, and it is base64-encoded

• Strongest method is RSA-SHA256

Figure 4-10 is an example of a sample API request using authentication.

Figure 4-10. API request including authentication

API Response

Mt. Wilson asserts all API responses. Responses are signed SAML assertions. Assertions are signed with the Mt.Wilson RSA SAML signing key. There is one SAML signing key for each installation of Mt.Wilson. An API client validates the signature with the SAML public key and uses the trust information. Here is an example of an API invocation with a SAML assertion. This Java example uses the Apache HttpClient library to obtain the SAML assertion for “192.168.1.121” by sending a GET request to Mt. Wilson:

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

String samlForHost = api.getSamlForHost(new Hostname("192.168.1.121"));

Here's how to interpret the SAML response:

TrustAssertion trustAssertion = api.verifyTrustAssertion(samlForHost); if( trustAssertion.isValid() )

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

getStringAttribute(attr));

Attributes for subject's trust status in the SAML response are:

Trusted: True if both Trusted_BIOS and Trusted_VMM are true.

Trusted_BIOS: True if the BIOS measurements on the subject match the whitelist (known-good values)

Trusted_VMM: True if the VMM measurements on the subject match the whitelist (known-good values)

Attributes for subject's measured launch environment in the SAML response are:

BIOS_Name, BIOS_Version, BIOS_OEM, VMM_Name, VMM_Version, VMM_OSName, VMM_OSVersion

 
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >
 
Subjects
Accounting
Business & Finance
Communication
Computer Science
Economics
Education
Engineering
Environment
Geography
Health
History
Language & Literature
Law
Management
Marketing
Philosophy
Political science
Psychology
Religion
Sociology
Travel