Logic programming based trust management

LOGIC PROGRAMMING BASED TRUST MANAGEMENT by Tran Ngoc Thai Kha A thesis submitted in partial fulfillment of the requirements for the degree of Master of Engineering Examination committee: Prof Phan Minh Dung (Chairman) Dr Sumanta Guha Dr Ho Dinh Duan Nationality: Previous degree: Vietnamese Bachelor of Engineering in Computer Science Ho Chi Minh City University of Technology Ho Chi Minh City, Vietnam Asian Institute of Technology School of Advanced Technologies Thailand December 2003 ACKNOWLEDGEMENT First, I would like to thank my advisor Prof Phan Minh Dung He was always ready to give me guidance and support when I encountered problems during my thesis I would also like to express my gratitude to Dr Sumanta Guha, Dr Ho Dinh Duan for their kind service as member committee, their constructive advises and comments I am thankful to my friends and CSIM fellow students for their help and friendship at AIT Finally, I have to thank Department of Industrial Systems Engineering - Ho Chi Minh City University of Technology, Prof Huynh Ngoc Phien, Dr Ho Thanh Phong, Dr Ho Dinh Duan and my family for their fully spirit and financial support ii ABSTRACT Trust management (TM) problem is a promising approach for authorization and access control in distributed systems according to given security policies Aspects of TM include formulating application-independent security polices and security credential, determining whether particular set of credentials satisfies the relevant policy, and deferring trust to third parties The core of TM consists of policy language and policy engine In this thesis, we clarify a well-known Trust Establishment system (Herzberg et al., 2000) by transforming TPL+ language and engine to logic programming context It is concluded that its solution for negation is very simple and so weak Afterthat, we design and implement a Trust Management system based on logic programming The policy language of this system is normal restricted logic language and the policy engine is extended from Fitting semantic and Stable model semantic This algorithm is proved to be sound for Preferred extension semantic iii Table of Contents Chapter Title Page Title Page i Acknowledgements ii Abstract iii Table of Contents iv List of Figures v Introduction Literature Review .3 2.1 Entity (principle) 2.2 Certificate (credential) 2.3 Monotonic Trust Policy Language (TPL) 2.4 Non-monotonic Trust Policy Language (TPL+) 2.5 Credential converter 2.6 Format converter 10 2.7 Credential collector 10 2.8 Trust management framework 12 Logic Programming and TPL+ 13 3.1 Definition of logic program .13 3.2 Iterated fixpoint semantic and minimal Herbrand model 14 3.3 Fitting semantic 14 3.4 Stable model semantic .15 3.5 Preferred extension 16 3.6 TPL+ in LP 17 LP-Based Trust Management 22 4.1 Data structure .22 4.2 Components .23 4.3 Input component 24 4.4 Ground component 25 4.5 Assign component 28 4.6 LPTM and Preferred extension 33 Conclusion and Future Research .35 References 36 Appendix 38 iv List of Figures Figure Page 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Application with Trust Establishment .3 A hospital policy A credential graph Credential converting .10 Common credential interface 10 Credential collector 11 Trust management framework 12 3.1 TPL+ and Preferred extension 21 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 LPTM system 22 LPTM components 23 Input component 26 Ground component 27 Assign component 29 Strongly connected component 31 Calculating Stable models 33 LPTM and Preferred extension 35 v CHAPTER INTRODUCTION 1.1 Background TM systems provide a flexible, standard, application-independent language for writing the policies and credentials (Blaze et al., 1996) Before TM, every party had to provide its own mechanisms for specifying policy, interpreting credentials, and binding user authentication with the authorization to perform security operations TM systems, on the other hand, provide a simple interface that takes care of all of these things All the party has to is identify the TM policies in the party and formulate appropriate queries to the TM system The single most important task in TM system is to answer the authorization question: “Can subject S access object O through the access operation A, given a set of credentials C and local policy P” when a subject S makes a request to access a protected object O Therefore, the core of TM system consists of policy language and compliance-checking engine, which checks whether the security policy accepts the request in order to answer the security question TM system can answer the authorization question by assigning roles which are introduced in Role-based access control (RBAC) (Sandhu et al., 1996) It is very necessary for standardizing policy and credential content in distributed environment In designing the TM system, we have to strike a balance between the expressiveness of the language and the computational complexity of the compliance-checking engine If the language is too flexible, then the role assignment may be undecidable We want a TM system of which the language is as much expressive as possible and the compliancechecking engine must be computationally feasible In the developing trend of TM, LP is very sufficient for designing an expressive policy language because it has mutually theoretic and practical foundation and is designed to imitate the human language Moreover, the policy engine is mainly a proof procedure in LP Therefore, we will concentrate on TM system based on LP 1.2 Problem statement The core of TM consists of policy language (LP language) and policy engine (proof procedure) In Trust Establishment system (Herzberg et al., 2001), TPL+ language is a normal LP language and TPL+ policy engine is extended Iterated fixpoint characteristic with SIL technique but it is not generally checked and so weak We will classify this engine in well-known LP proof procedures and base on them to propose a new engine which is more acceptable for specific purposes of TM system 1.3 Objectives Verify Trust Establishment system (Herzberg et al., 2001): - Transform Trust Policy Language (TPL+) to LP context Verify and compare TPL+ language and policy engine Propose a LPTM system: - Normal restricted policy language and corresponding policy engine Implement demonstrated LPTM system 1.4 Scope of work TM system is very complex It consists of credentials, credential pool, roles, policy language, compliance-checking engine, Public Key Infrastructure, credential collector… In this thesis, we propose a demonstrated LPTM system with two main components of policy language and policy engine 1.5 Organization Chapter reviews Trust management frameworks It covers primary components which must exist in the realistic system Chapter reviews well-known semantics of LP The TPL+ policy of Trust Establishment system also is analyzed in LP context Chapter proposes the prototype of Trust Management system Its policy language is normal LP language The engine is developed based on Fitting and Stable semantic and it is soundness for Preferred extension semantic Chapter concludes about LP-based Trust Management and gives future works CHAPTER LITERATURE REVIEW Several TM systems have been proposed in recent years KeyNote (Blaze et al., 1999) and SPKI/SDSI (Clarke et al., 2001), capability-based TM, uses credential to delegates particular permission for particular subject They can not express evenly a simple general policy with permission for a group Trust Builder (Yu et al., 2001) is prepositional logic language in LP context Role-based TM (Li et al., 2001) is very beautiful attribute-based TM but it supports only positive role-based policies In LP context, It is definite (monotonic) language The discussed policy languages are simple and monotonic and they are well done in LP In the practice, non-monotonic language is expected but it is very difficult to find out a completely solution Trust Policy Language is proposed by Hezrberg (2000) to solve this problem However, policy engine is graph coloring problem It works well in positive policies but it is so weak when negative policies are added In this part, we introduce the TrustEstablishment (TE) System (Herzberg et al., 2000), a TM which supports negation Figure 2.1 Application with Trust Establishment TE can decide on the user’s roles based on their certificates and a given policy The system extends traditional RBAC systems (Sandhu, 1996) by validating the certificate and then mapping the certificate owner to a role The TE does not make the actual access control decision, but rather decides who belongs to which groups The policy provides the rules that determine how to map entities to roles 2.1 Entity (principle) There are three types of entities: - Owner: Define the policy on access to its resources Subject: Request specific action (access) on the resource Issuers: Issue certificates with some properties to the subject or to other issuers The entity identifiers are the public keys (or cryptographic one-way hashes of them), which simply identify the corresponding private keys All remain properties can only be interpreted as specific attributes associated to the owner of the private key 2.2 Certificate (credential) A certificate is a statement signed by the issuer identifying a subject’s public key and properties of the holder of the corresponding subject’s private key They also transform from current known certificates to independent format certificates The following are mandatory components in TE certificate object: - Issuer’s public key: Identifier of the issuer Subject’s public key: Identifier of the subject The unified certificate type Version of the certificate profileURL: Provide the certificate type as its structure and semantics issuerCertRepository: Provide more certificates for the issuer and updated CRL subjectCertRepository: Provide more positive certificates for the subject Policy owner will define negativeCertRepository where the system should look for negative certificates Each certificate may include more fields, where a field is identified by its name (a string), and its value can be numeric, a string, a range of values, or a set of strings or numbers 2.3 Monotonic Trust Policy Language (TPL) The application's policy supplies the rules for mapping an entity to a group It supplies the rules that determine whether or not a certificate owner is a member of a certain group TPL is a language used to define groups and the rules on how to become a group member Rules are functions in certificate fields; to become a member of a group, one has to present one or more certificates Groups can represent roles and thus the TE system can be used by a RBAC system to assign roles to a non-predefined population (Golan et al., 2001) 2.3.1 Definition The constant of the language - R: A set of roles T: A set of types A: A set of attributes E: A set of entities C: A set of credentials in the form of C(Issuer, Subject, Type, Attr) where Issuer ∈ E, Subject ∈ E, Type ∈ T and Attr ∈ 2A Ct ⊆ C: the subset of all credentials of type t (Ct)n: all n length tuples of credentials from Ct as CredentialTuples The functions of the language - F: a set of functions Each function is defined from (Ct1)n1 x (Ct2)n2 x … x (Ctk)nk → {true, false} for some k>0 and is used to define constraints on the input credentials and on their attributes D: a set of different function Each function is defined from Ct x Ct → {true, false} for t ∈ T and give true if the two input credentials are different, false otherwise The terms and clauses of the language - - Include(CredentialTuples, Subject, type, number, diff) The Include (I) is satisfied if exist CredentialTuple ∈ (Ctype)number such that all different (diff) credentials in CredentialTuple has the same Subject Role(CredentialTuple, r) The Role (R) is true if all Issuers in all credentials of a CredentialTuple were already assigned role r IncSet(E, r, CT1, …, CTk) :- I1(CT1, E, t1, n1,d1), , I1(CTk, E, tk, nk,dk), f(CT1, , CTk), Role(CT1, r1), …, Role(CTk, rk) The term defines when an entity e can be assigned role r and it also outputs the CredentialTuples CT1, …, CTk that were used to satisfy the term Role(E, r) :- IncSet(E, r, CT1, …, CTk) Defines when an entity can be assigned role r Example Figure 2.2 R = {self, hospitals, doctors} T = {hospital, doctor} A = {} E = {sinai, ichilov, rambam, alice, bob} C = { c(self, sinai, hospital, null), c(sinai, rambam, hospital, null), c(ichilov, allice, doctor, null), A hospital policy c(self, ichilov, hospital, null), c(ichilov, rambam, hospital, null), c(rambam, bob, doctor, null) } Policy language: Role(E, hospitals) :- I(CT1, E, hospital, 1, null) Role(E, hospitals) :- I(CT2, E, hospital, 2, null), Role(CT2,hospitals) Role(E, doctors) :- I(CT3, E, doctor, 1, null), Role(CT3, hospitals) Let 2HB is set of interpretations 2HB is complete lattice with set inclusion T2: 2HB → 2HB is defined as L0 = Undefined ∈ T2(I) if ∃ L0 ← L1, …, Lm, ¬Lm+1, …, ¬Ln s.t {L1, …, Ln} ∩ I* ≠ ∅ Let T2↑0 = T20 (depend on previous partial model), T2↑i = T2(T2↑(i - 1)) The minimal Herbrand model is T2↑ω The simplified program is obtained by deleting rules whose head value is Undefined If program is not simplified then we us Stable model to calculate the program Otherwise, the remaining program is separated to many ordered subprograms by Strongly Connected Components We recalculate Extended Fitting with each subprogram in the particular order 4.5.2 Strongly Connected Component Strongly connected graph is a directed graph D = (V, E) ∀u, v ∈ V, there is a path from u to v (u, v) and from v to u (v, u) Strongly Connected Component (SCC) is a sub graph S = (V’, E’) if S is strongly connected graph and ∀u, u ∈ V, u ∉ V’, there is no vertex v ∉ V’ for which (u, v) ∈ E and (v, u) ∈ E Figure 4.6 Strongly connected component The directed graph DP = (VP, EP) is constructed from program by - VP = {v | v is atom in program} EP = {(u, v) | there is a rule in program that head is u and the body contains atom v 30 The SCC of a directed graph can be found using a variant of depth-first search (Sedgewick, 1988) The method we will use here was discovered by R E Tarjan (1972) The recursive visit function given below uses the computation to find the highest vertex reachable (via an up link) from any descendant of vertex k, but uses the value of in a slightly different way to write out the SCCs Algorithm public int visit(int k) { int m, min; id++; setVal(k, id); = id; push(k); AdjList al = (AdjList)get(k); for (int i = 0; i < al.size(); i++)//t=adj[k] { int adjki = ((Integer)al.get(i)).intValue(); if ((m = getVal(adjki)) == 0) m = visit(adjki); if (m < min) = m; } if (min == getVal(k)) { Vector scc = new Vector(); { pop(); scc.addElement(new Integer(stack[p])); setVal(stack[p], Integer.MAX_VALUE); } while (stack[p] != k); sccs.addElement(scc); } return min; } This program pushes the vertex names onto a stack on entry to visit, then pops them and prints them on exit from visiting the last member of each SCCs The point of the computation is the test whether == getVal(k) at the end: if so, all vertices encountered since entry (excepted those already printed out) belong to the same SCCs as k With each SCCs, subprogram consists of rules in program whose head belong to SCC Let define a directed graph DS = (VS, ES) VS = {scc | scc is SCC} ES = {(scc1, scc2) | there is an edge (u, v) ∈EP which u ∈ scc1 and v ∈ scc2 Clearly, relation between SCCs in graph is partial order Actually, assume there are two vertex scc1, scc2 which (scc1, scc2) ∈ ES and (scc2, scc1) ∈ ES Therefore, it exists (u1, v1), (v2, u2) ∈ EP which u1, u2 ∈ scc1, v1, v2 ∈ scc2 From definition of SCC, scc1 ∪ scc2 is also SCC Contradition Result of subprogram of SCC source will affect to result of subprogram of SCC destination if there are an edge from SCC source to SCC destination in directed graph DS 31 If we calculate subprogram in the right order, then each subprogram will calculate only once 4.5.3 Calculating Stable Model The stable model of program is showed out by Simons algorithm (Simons, 2000) The algorithm begins with set of stable model A = ∅ It adds atom and negation of atom to A and checks whether the resulting set corresponds to at least one stable model If it does not, then it backtracks by removing atoms and negation of atoms from A and by changing atoms into negation of atoms and vice versa The search space can be pruned by the heuristic way of choosing what atom or negation of atom that immediately gets conflict to avoid a lot of backtracking The detail of this algorithm is in Appendix B Program (ground rules) Stable Model Module Has models? Yes No Set of models All ground atoms value are Undefined Figure 4.7 Calculating Stable models Here, if program has no stable model then all atoms of program are assigned to Undefined Otherwise, all atoms belong to stable model are True and the others are False With this separation, the result of Stable model only affects to subprograms which contains this atoms Independent subprograms will not affect to each others Example1 P = {a ← ¬b b ← ¬a c ← ¬d, ¬c} Extended Fitting P: M = {d = False} SP = {P1 = { a ← ¬b b ← ¬a.}, P2 = {c ← ¬c}} Extended Fitting P1: M is unchanged 32 SP = {P1} Stable model P1: M = {{d = Fasle, a = True, b = False}, {d = Fasle, a = False, b = True}} Extended Fitting P2: M is unchanged SP = {P2} Stable model P2: No stable model All atoms in P2 {c} are assigned to Undefined M = {{d = Fasle, a = True, b = False, c = Undefined}, {d = Fasle, a = False, b = True, c = Undefined}} There are two Preferred extensions: P ∪ {¬d, ¬b}, P ∪ {¬d, ¬a} Example2 P = { a ← ¬b b ← c, ¬a c ← ¬c } Extended Fitting P: M=∅ SP = {P1 = {c ← ¬c}, P2 = { a ← ¬b b ← c, ¬a.}} Extended Fitting P1: M is unchanged SP = {P1} Stable model P1 M = {{c = Undefined}} Extended Fitting P2: M = {{c = Undefined, a = Undefined, b = Undefined}} SP = {} Preferred extension P ∪ {¬b}: {a = True, b = False} 4.6 LPTM and Preferred extension Although the algorithm tries to extend Fitting semantic and Stable model semantic for getting a more sufficient result, it is still a Band-Aid solution Let M is a model of program P of the LPTM algorithm For each A ∈ M-, all rule A ← A1, …, Am, ¬Am+1, …, ¬An satisfy {A1, …, Am} ∩ M- ≠ ∅ or {Am+1, …, An} ∩ M+ ≠ ∅ For each A ∈ M+, existing a rule A ← A1, …, Am, ¬Am+1, …, ¬An satisfy {A1, …, Am} ⊆ M+ and {Am+1, …, An} ⊆ M+ Let hypotheses H = {not-A | A ∈ M-} KB is abductive program which every negative literal ¬A is replaced to not-A M+ = Cons(H ∪ KB) Now, we show that S = KB ∪ H is an admissible scenario Assume P ∪ H is not admissible scenario ⇔ ∃ not-A ∈ H, not-A is not acceptable w.r.t S 33 ⇔ ∃ an evidence E of A, ∀not-B ∈ E, S a B ⇔ ∃ a proof tree Tr of A w.r.t KB whose terminal nodes belong to E ∪ {…} Proposition 3.6.3 hold with tree Tr with root A Contradition LPTM Preferred extension Figure 4.8 LPTM and Preferred extension 34 CHAPTER CONCLUSION AND FUTURE RESEARCH 5.1 Conclusion TM systems provide a flexible, standard, application-independent language for writing the policies and credentials Trust Establishment is one of the first systems which support negation The system extends traditional role-based access control systems by validating the certificate and then mapping the certificate owner to a role The policy provides the rules that determine how to map entities to roles In this thesis, TPL+ policy language is reconstructed with two types: role and credential and we conclude that it is normal LP language The policy engine use SIL technique to limit infinite loop of Iterated fixpoint characterization However, this technique does not bring the results like authors expected Most of roles can not be assigned because of SIL effect We also design and implement a LP-based TM system The policy language here is normal restricted language Policy engine is constructed by repeatedly calculating, reducing and separating program with Extended Fitting semantic and Stable model semantic However, this procedure can not totally cover powerful Preferred extension semantic Every TM system has a very large pool of credentials and policies Here, LPTM support partial updating technique When a credential is issued/expired or a policy rule is added/removed, the system only recalculate whatever has changed Finally, what have done in this thesis consolidates that logic programming approach provides systematic and logic framework for studying TM and it is very sufficient for the developing trend of TM 5.2 Future research There are several other components in TM are not covered The study of this thesis only concentrates on policy language and policy engine However, the language of LPTM does not contain functions, constrains; the engine does not totally cover Preferred extension semantic The following are open issues: - Develop more sufficient logic-based engine for well-known logic programming semantic such as Preferred extension semantic… Develop a parser to transform more expressive language which contains functions, constraints to normal language which engine can understand 35 REFERENCES Baral, C (2003) Knowledge representation, reasoning and declarative problem solving with Answer Set Cambridge Press Blaze, M., Feigenbaum, J., Ioannidis, J and Keromytis, A D (1999) The KeyNote Trust Management System IETF RFC 2704 Clarke, D., Elien, J E., Ellison, C., Fredette, M., Morcos, A and Rivest, R L (2001) Certificate Chain Discovery in SPKI/SDSI Journal of Computer Security 9(4):285-322 Dung, P M (1995) An Argumentation-theoretic Foundation for Logic Programming Journal of Logic Programming 22(2):151-177 Gelder, A V., Ross, K A and Schlipf, J S (1991) The Well-founded Semantics for General Logic Programs Journal of the ACM 38(3):620-650 Gelfond, M and Lifschitz, V (1988) The Stable Model Semantics for Logic Programming Proceedings of the 5th National Conference on Logic Programming 10701080, Seattle, USA Golan, I., Herzberg, A., Mass, Y and Omer, O (2001) An Efficient Algorithm for Establishing Trust in Strangers Manuscript IBM Haifa Research Laboratory Herzberg, A and Mass, Y (2001) Relying Party Credentials Framework Proceedings of the Crytographer’s Track and RSA Conference San Francisco, USA Herzberg, A., Mass, Y., Michaeli, J., Naor, D and Ravid, D (2000) Access Control Public Key Infrastructure or Assigning Roles to Strangers IEEE Symposium on Security and Privacy Oakland, California Li, N., Mitchell, J C and Winsborough, W H (2002) Design of a Role-based Trust Management System Proceedings of the 2002 IEEE Symposium on Security and Privacy 114-130 Lloyd, J W (1987) Foundation of Logic Programming, 2nd edition Springer Sandhu, R S., Coyne, E J., Feinstein, H L and Youman, C E (1996) Role-Based Access Control Models IEEE Computer 29(2) pp38-47 Sedgewick, R (1988) Algorithms Addison-Wesley Simons, P (1995) Efficient Implementation of the Stable Model Semantics for Normal Logic Programs Research Report 35 Helsinki University of Technology Simons, P (2000) Extending and Implementing the Stable Model Semantics Research Report 58 Helsinki University of Technology Syrjanen, T (2000) Lparse 1.0 User Manual Helsinki University of Technology 36 Yu, T., Winslette, M and Seamons, K E (2001) Interoperable Strategies in Automated Trust Negotiation Proceedings of the 8th ACM Conference on Computer and Communications Security 146-155 37 APPENDIX A LPTM EXAMPLE We add below rules step-by-step by input to text field of Rules view discount(bigc, X) :- student(U, X), university(U), ~punish(U, X) student(ait, X) :- aithro(X), person(X) likecoca(X) :- person(X), ~likepepsi(X) likepepsi(X) :- person(X), ~likecoca(X) likebrewery(X) :- likecoca(X) likebrewery(X) :- likepepsi(X) Then, we add certificates to Certificates view Here, certificates are converted to roles with type CERT After each certificate is issued, the system immediately calculates models of roles with type NEW from ground rules with type NEW and roles with type OLD Add certificate student(ait, ann) 38 Add certificate university(ait) 39 Add certificate person(bob) 40 APPENDIX B STABLE MODELS Let a rule r is of the form A ← A1, …, Am, ¬Am+1, …, ¬An fr(S, C) = {A | A1, …, Am ∈ C, Am+1, …, An ∉ S} Let program P consist of rules of the form A ← A1, …, Am, ¬Am+1, …, ¬An fP(S) = {A | A ← A1, …, Am, ¬Am+1, …, ¬An ∈ P, A1, …, Am ∈ fP(S), Am+1, …, An ∉ S} Let gP(S) = I {fP(S)}, gP(S) is the least fix point of f PS ( A) = U f r ( S , A) S is stable r∈P model if and only if S = gP(S) Algorithm public boolean smodel(P,A) { A = expand(P,A) A = lookahead(P,A) if (conflict(P,A)) return false else if (A covers Atoms(P)) return true {A+ is a stable model} else { x = heuristic(P,A) if (smodels(P, A ∪ {x})) return true else return smodels(P, A ∪ {¬x}) } } Figure B.1 A visualization of the search process Here, Atoms(P) is set of atoms that appear in the program A set of literal A is said to cover a set of atoms B if B ⊆ A+ ∪ A- = Atoms(A), and B is said to agree with A if A+ ⊆ B and A- ∩ B ≠ ∅ The expand function makes use of some simple properties of the stable model semantics to refine a partially computed model It is calculated by two subfunction Atleast(P,A) and Atmost(P,A) 41 public Set expand(P,A) { { A’ = A A = Atleast(P,A) A = A ∪ {¬x | x ∈ Atoms(P) and x ∉ Atmost(P,A)} } while (A ≠ A’) } Let S be a stable model of P agreeing with the set of literals A, then fr(S, S) ⊆ S for r ∈ P Let defines r ( A) = - I A+ ⊆ C ⊆ Atoms − A− f r (C , C ) and max r ( A) = U A+ ⊆ C ⊆ Atoms − A− f r (C , C ) , then If r ∈ P, then S agrees with minr(A) If there is an atom a such that for all r ∈ P, a ∉ maxr(A), then S agrees with {¬a} If the atom a ∈ A, if there is only one r ∈ P for which a ∈ maxr(A), and if there exists a literal x such that a ∉ maxr(A ∪ {x}), then S agrees with {¬x} If ¬a ∈ A and if there exists a literal x such that for some r ∈ P, a ∈ minr(A ∪ {x}), then S agrees with {¬x} Function Atleast(P,A) is the the smallest set of literals containing A that can not be enlarged four above points It is the least fix point of f(B) = A ∪ B ∪ {a ∈ minr(B) | a ∈ Atoms(P) and r ∈ P} ∪ {¬a | a ∈ Atoms(P) and for all r ∈ P, a∉ maxr(B)} ∪ {¬x | there exists a ∈ B such that a ∈ maxr(B) for only one r ∈ P and a ∉ maxr(B ∪ {x})} ∪ {¬x | there exists ¬a ∈ B and r ∈ P such that a ∈ minr(B ∪ {x})} Fucntion Atmost(P,A) is least fix point of f’(B) = U f’r(A+, B – A-) – Ar∈P The search space can be pruned by the heuristic way of choosing what atom or negation of atom that immediately gets conflict to avoid a lot of backtracking Consider a program P, a partial model A, and an atom a such that both expand(P, A ∪ {a}) and expand(P, A ∪ {¬a}) contain conflicts If smodels(P,A) choose a or ¬a immediately, then it will return after only two expand calls Figure B.2 Looking ahead yields a potentially smaller search space 42 public Set lookahead(P,A) { { A’ = A A = lookahead_once(P,A) } while (A ≠ A’) } public Set lookahead_once(P,A) { B = Atoms(P) – Atoms(A) B = positive and negative literals in B while (B ≠ ∅) { Take any literal x ∈ B A’ = expand(P, A ∪ {x}) B = B – A’ if (conflict(P,A’)) return expand(P,A ∪ {¬x}) } return A } The lookahead function try to expand with atoms in Atoms(P) – Atoms(A) until it find a literal x that cause conflict The last function heuristic is made in a backtracking algorithm can significantly affect the time the algorithm has to spend searching for a solution Simon’s heuristic tries to minimize the size of the remaining search space For a literal x, let Ap = expand(P, A ∪ {x}) and An = expand(P, A ∪ {¬x}) Assume that the search space is a full binary tree of height H 2n + p H–p H–n H +2 = 2n + p is an upper bound on Let p = |Ap – A| and n = |An – A| Then, the size of the remaining search space Minimizing this number is equal to minimizing 2n + p log 2n + p = log(2n + 2p) – (p + n) (*) Since 2max(n, p) < 2n + 2p ≤ 2max(n, p) + is equivalent to max(n, p) < log(2n + 2p) ≤ max(n, p) +1 (*) ⇔ max(n, p) – (p + n) < log(2n + 2p) – (p + n) ≤ max(n, p) + – (p + n) ⇔ – min(n, p) < log(2n + 2p) – (p + n) ≤ – min(n, p) It suffices to maximize min(n, p) If two different literals have equal minimums, then the one with greater maximum max(n, p) is chosen public Atom heuristic(P,A) { B = Atoms(P) – Atoms(A) = Max = while (B ≠ ∅) { Take any atom a∈ B B = B – {a} 43 p = |expand(P, A ∪ {a}) – A| if (p ≥ min) { n = |expand(P, A ∪ {¬a}) – A| if (min(n,p) > or (min(n,p)=min and max(n,p) > max)) { = min(n, p) max = max(n, p) if (p = max(n, p)) x = a else x = ¬a } } } return x } 44 ... engine to logic programming context It is concluded that its solution for negation is very simple and so weak Afterthat, we design and implement a Trust Management system based on logic programming. .. 10 2.7 Credential collector 10 2.8 Trust management framework 12 Logic Programming and TPL+ 13 3.1 Definition of logic program .13 3.2 Iterated fixpoint... collectors encode the credentials they collected in a XML -based syntax using Format converter 11 2.8 Trust management framework From Figure 2.1, Trust management system works with input (certificate,