Original Publication Date: 2005-Apr-04
Included in the Prior Art Database: 2005-Apr-04
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.
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)
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...