Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Central trusted authority provides computer authentication
Reexamination Certificate
1999-10-08
2001-07-03
Swann, Tod (Department: 2132)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Central trusted authority provides computer authentication
C713S156000, C713S158000, C713S159000, C705S051000, C705S054000
Reexamination Certificate
active
06256734
ABSTRACT:
FIELD OF THE INVENTION
The invention relates to trust-management systems. More particularly, the invention relates to a method and apparatus for compliance checking in a trust-management system.
COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
Emerging electronic commerce services that use public-key cryptography on a mass-market scale require sophisticated mechanisms for managing trust. For example, a service that receives a signed request for action may need to answer a basic question: “is the key used to sign this request authorized to take this action?” In some services, the question may be more complicated, requiring techniques for formulating security policies and security credentials, determining whether particular sets of credentials satisfy the relevant policies, and deferring trust to third parties. Matt Blaze, Joan Feigenbaum and Jack Lacy, “Decentralized Trust Management,” Proc. IEEE Conference on Security and Privacy (May 1996) (hereinafter “Blaze, Feigenbaum and Lacy”), the entire contents of which is hereby incorporated by reference, discloses such a trust-management problem as a component of network services and describes a general tool for addressing it, the “PolicyMaker” trust-management system.
As will be explained, the heart of the trust-management system is an algorithm for compliance checking. The inputs to the compliance checker are a “request,” a “policy” and a set of “credentials.” The compliance checker returns a “yes” (acceptance) or a “no” (rejection), depending on whether the credentials constitute a proof that the request complies with the policy. Thus, a central challenge in trust management is to find an appropriate notion of “proof” and an efficient algorithm for checking proofs of compliance.
Unfortunately, the compliance-checking problem may be mathematically undecidable in its most general form. Moreover, the compliance-checking problem is still non-deterministic polynomial time (NP) hard even when restricted in several natural ways.
Blaze, Feigenbaum and Lacy discloses the trust-management problem as a distinct and important component of security in network services. Aspects of the trust-management problem include formulation of policies and credentials, deferral of trust to third parties, and a mechanism for “proving” that a request, supported by one or more credentials, complies with a policy. A comprehensive approach to trust management independent of the needs of any particular product or service is disclosed along with a trust-management system that embodies the approach.
In particular, the PolicyMaker system comprises policies, credentials, and trust relationships that are expressed as finctions or programs (or parts of programs) in a “safe” programming language. A common language for policies, credentials, and relationships makes it possible for applications to handle security in a comprehensive, consistent, and largely transparent manner.
The PolicyMaker system is also expressive enough to support the complex trust relationships that can occur in large-scale network applications. At the same time, simple and standard policies, credentials, and relationships can be expressed succinctly and comprehensibly.
The Policy Maker system provides local control of trust relationships. Each party in the network can decide in each transaction whether to accept the credential presented by a second party or, alternatively, which third party it should ask for additional credentials. Local control of trust relationships, as opposed to a top-down centralized approach, eliminates the need for the assumption of a globally known, monolithic hierarchy of “certifying authorities.” Such hierarchies do not scale easily beyond single “communities of interest” in which trust can be defined unconditionally from the top down.
The PolicyMaker mechanism for checking that a set of credentials proves that a requested action complies with local policy does not depend on the semantics of the application-specific request, credentials or policy. This allows different applications with varying policy requirements to share a credential base and a trust-management infrastructure.
Three examples of application-specific requests, and local policies with which they may need to comply, will now be described. Although individually the examples are of limited complexity, collectively they demonstrate that an expressive, flexible notion of “proof of compliance” is needed.
As a first example, consider an e-mail system in which messages arrive with headers that include, among other things, the sender's name, the sender's public key, and a digital signature. When a recipient's e-mail reader processes an incoming message, it uses the public key to verify that the message and the signature go together (i.e., an adversary has not spliced a signature from another message onto this message). The recipient may also be concerned about whether the iname and public key go together. In other words, could an adversary have taken a legitimate message-signature pair that he produced with this own signing key and then attached to it his public key and someone else's name? To address this concern, the recipient needs a policy that determines which name-key pairs are trustworthy. Because signed messages may regularly arrive from senders that he has never met, a simple private database of name-key pairs may not be sufficient. By way of example, a plausible policy might include the following:
(1) He maintains private copies of the name-key pairs (N
1
, PK
1
) and (N
2
, PK
2
). A reasonable interpretation of this part of the policy is that he knows the people named N
1
and N
2
personally and can get reliable copies of the public keys directly from them.
(2) He accepts “chains of trust” of length one or two. An arc in a chain of trust is a “certificate” of the form (PK
i
, (N
j
, PK
j
), S). This is interpreted to means that the owner N
i
of PK
i
vouches for the binding between the name N
j
and the public key PK
j
. This can also mean that N
i
attests that N
j
is trusted to provide certificates of this form. The party N
i
signs (N
j
, PK
j
) with his private key and the resulting signature S.
(3) He insists that there be two disjoint chains of trust from the keys that he maintains privately to the name-key pair that arrives with a signed message.
As a second example, consider a loan request submitted to an electronic banking system. Such a request might contain, among other things, the name of the requester and the amount requested. A plausible policy for approval of such loans might take the following form:
(1) Two approvals are needed from loans of less than $5,000. Three approvals are needed for loans of between $5,000 and $ 10,000Loans of more than $10,000 are not handled by this automated loan-processing system.
(2) The head of the loan division must authorize approvers' public keys. The division head's public key is currently PK
3
. This key expires on Dec. 31, 1998.
As a third example, consider a typical request for action in a web-browsing system, such as “view URL http://www.research.att.com/.” In constructing a viewing policy, a user may decide what type of metadata, or labels, she wants documents to have before viewing them, and whom she trusts to label documents. The user may insist that documents be rated (S≦2,L≦2,V=0, N≦2) on the sex (S), language (L), violence (V) and nudity (N) scales, respectively. She may trust self-labeling by some companies or any labels approved by certain companies.
Previous work on “protection systems” is loosely related to the concept of a trust-management system. Recent work that is similarly related to the present invention can be found in,
Blaze Matthew A.
Feigenbaum Joan
Strauss Martin J
AT&T
Sulpizio, Jr. Ronald F.
Swann Tod
LandOfFree
Method and apparatus for compliance checking in a trust... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for compliance checking in a trust..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for compliance checking in a trust... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2556463