Browse Prior Art Database

Integrity-Based Computing

IP.com Disclosure Number: IPCOM000122404D
Original Publication Date: 2005-Apr-04
Included in the Prior Art Database: 2005-Apr-04
Document File: 5 page(s) / 74K

Publishing Venue

IBM

Abstract

A number of usage scenarios including business models and IT solutions supporting such business models are described for integrity-based computing (IBC), an approach that allows an entity to verify the integrity of itself or remote parties. The implementation of IBC is based on the TCG standards.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Page 1 of 5

Integrity-Based Computing

Basic TCG Scenarios

A "scenario" is considered a sketch of a situation/application where TCG functionality can solve or reduce a certain security or privacy problem.
· Support compliance arguments (e.g., for privacy, US public company financial application management, purpose limitation)
· Purpose limitation: A privacy policy (think of EPAL) limits the use of personal information to certain purposes. Applications might come with certain certified (by a vendor, a data protection commissioner, etc.) statements about the purposes they support. Using TCG functionality one might be able to enforce such a privacy policy,
i.e., ensure that data are only processes by an application A if the purpose supported by A is one of those allowed by the policy.
· Compliance proof (any regulations): TCG functionality can be used to ensure that a system, once in a state that ensures compliance, stays in this state, and thus stays compliant. More dynamically, as in "purpose limitation" one might use TCG functionality to ensure that certain critical data are processed only with applications that are compliancy ensuring.
· Trusted token exchange at STS: "WS Trust" specifies a service for exchanging tokens of Type A by semantically equivalent tokens of Type B (say, two certificates of different formats). If this translation is done remotely the requester might want a guarantee that the service is implemented in a trustworthy way. Using TCG functionality the client might be able to verify the integrity of the token exchange service.
· Customer verification of provider SLA conformance: Service level agreements assure both ends of a transaction or relation of certain security properties. TCG functionality might allow one end to verify that the other end actually has the assured properties (i.e., adds additional arguments to trust in the SLA agreement).
· Fault tolerant distributed computing: Fault tolerance is based on certain assumption about how components can fail, e.g., "crash failures" (a component is either correct or does not interact with its environment at all) or "Byzantine" (no assumptions are made about a failed assumption). Using TCG functionality a component can always check the integrity of a peer component, which allows to use algorithms for crash failures even in a model with Byzantine failures.
· Secure dynamic attachment of client devices
· Security remote connectivity / mobile device network access policy: An enterprise might want to limit access to its network to trustworthy devices (e.g., one might be allowed to use personal PDAs, but only if they are configured in a specific way). TCG functionality can be used to enforce this policy.
· Secure (remote) administration & anything for TCO reduction: A company is operating n servers, and wants to administer them from a central console. Two variants: For remote administration TCG functionality might ensure that a remote server can autonomously restart, ensuring th...