7. Trust Management

7.1 Trust Management

Trust Management is an approach to distributed access control and authorization based on the following concepts:

• An access control policy that establishes which parties have rights to access or delegate access to applications and information,

• A deduction engine that determines, given policies, whether to grant or deny access to a given resource,

• Signed certificates authenticating policy statements and access requests.

Policies determine when an entity or members of some group may perform an action on some object, such as a document, database, or purchase order. Deduction determines the consequences of a policy and produces “proofs” that can be enforced locally by access monitors. Digital signatures provide cryptographic security and eliminate the need for passwords and replicated password files.

.

Policy Language A policy language allows individuals to define interdependent information sharing and trust policies locally, referring to policies of other individuals or corporate hierarchies. Central concepts in role-based trust management are:

- Authorization, granting a permission to all individuals occupying a certain role,

- Delegation, allowing an individual to trust others to make specified decisions,

- Roles, grouping individuals into categories for easy policy definition,

- Revocation, terminating permission.

Access policies can be simple statements allowing all employees of a company to access all company documents, or complex policies that specify how different classifications of employees may read or update different parts of a complex database. Policies may further specify what kind of database updates are allowed by each kind of each employee, or give specific limits on how many times a right may be delegated.

Here is an example illustrating authorization and delegation. In this example, a hospital establishes the policy that the primary physician of any patient may access the patient’s records, where the association between patient and physician is determined by the clinic where the doctor normally sees the patient outside the hospital. When a doctor is not available, she may delegate her role as primary physician to another doctor:

Hospital policy

allow access(medical_record(Y)) if clinic says primary_physician(Y)

define role clinic : Oak_Medical, Central_Clinic, …

Central_Clinic policy

define role primary_physician(Nancy): Susan allow delegation

define role primary_physician(Albert): Susan allow delegation

define role primary_physician(Tony): Susan allow delegation

Susan policy when off-duty

delegate Central_Clinic.primary_physician(Nancy) to Bob

In the condition, “clinic says primary_physician(Y)”, the word says is interpreted as meaning that a clinic must sent a digitally signed certificate stating that the individual requesting access is the primary physician of the patient. Access requests come with digitally signed certificates that allow the source of the request to be identified.

Another example illustrates the use of policy logic in a peer-to-peer application, where

Richard shares snapshots with his friends and family over the network:

Richard’s policy

allow access(photos) if photo_friends or family

define role photo_friends: Edith, John, Fernando

define role family: Vivi, Larry allow delegation

Vivi’s policy

delegate Richard.family to Meredith

In this example, Richard identifies his brother and sister as members of his family and allows them to name other members of his family. However, he does not allow his photography friends to transfer their access to others.

Deduction. When an access request is received, the deduction engine uses deductive inference to determine whether the request should be granted or denied. If the engine determines that the request should be granted, then the engine can produce a sequence of signed policy statements that can be verified by a simple access guard. This allows a trust management engine to be located separately from an access guards. Since access guards do not need to perform deduction or search policy files, an access guard may be installed on an embedded or handheld computing device with limited computing power or limited network bandwidth.

The same deduction process that determines access can search distributed policy logic for conflicts. The deduction engine can also answer administrative queries, such as a request to display all employees who can sign purchase orders.

Distributed policies. In a distributed computing environment, policy statements governing a single resource may by stored at many locations. In addition, delegation allows one policy statement to refer to others. For example, Barbara, the owner of one folder, may allow Greg to delegate access to any file in this folder. Greg may then delegate access to anyone that Susan says is a member of her family. In this example, Greg trusts individuals that Susan trusts. Interrelated policy statements can be maintained using a peer-to-peer architecture, eliminating the need for a centralized server that contains all policy statements. By referring to each other, individuals may establish a “web of trust,” relying on each other to certify individuals and organizations.

Definitions

Keys. Public-key cryptography allows users to generate key pairs, each consisting of a private signing key and a public verification key that may be distributed freely without compromising the secrecy of the signing key. The owner of a signing key may digitally sign a document by carrying out a cryptographic calculation. Once signed, anyone in possession of the verification key can check the signature.

Public-key infrastructure (PKI) refers to key-generation algorithms and certificate authorities that generate cryptographic keys, distribute them securely, and provide a record of who received specific keys.

Authentication is the process of identifying an individual or process. Password authentication asks a user to type in a user name and password. If the name-password combination matches an entry in the password file, the user is considered authenticated. Key-based authentication relies on key pairs and digital signatures instead of passwords; cryptography allows the same user key to be used for many applications. The X.509 certificate format is an industry standard format for presented certificates that tie a cryptographic key to a specific individual or device.

Access request. Web access requests and peer-to-peer access requests may be presented using different network protocols. In a web environment, the owner of a cryptographic key may establish a secure web connection using https, a secure version of the standard protocol http, augmented with steps that transmit the client’s key to the web server.

Comparison with other mechanisms

Authentication. Traditional access decisions have been based on a combination of authentication and access control. For example, in order to determine whether to answer a database query, a system may determine who sent the request and whether that person is allowed to ask that query. Traditionally, authentication is achieved using passwords. In a simple password-based system, a server may ask a client to transmit a password across the network. In Kerberos-based authentication, a challenge-response protocol is used that avoids sending passwords on the network, increasing security. The X.509 standard is a modern example of a mechanism for certifying identity. The X.509 standard specifies a format for digital certificates, but does not have associated policy logic or other decision-making aspect.

Access control. Traditional access control decisions are made using access control lists. For example, a secure web site may contain a list of authorized users and their passwords. If a client tries to access the site, the server asks for a user name and password. Access control lists are cumbersome to install and maintain, since a complete list of all authorized users must be installed at every site. If an employee leaves the company suddenly, then many access control lists must be updated.

Toward trust management standards

SDSI, A Simple Distributed Security Infrastructure], combines public-key infrastructure design with a means of defining groups and issuing group membership certificates. SDSI groups provide a basis for access-control lists and security policies, SDSI does not address the general problem of formulating, testing , following, or enforcing policies. However, a SDSI key can delegate to a group the authority to sign certificates on behalf of the key. SDSI certificates can time out, and they can be reconfirmed by an on-line agent acting for the issuer.

The Simple Public Key Infrastructure group has goals similar to the SDSI effort and now subsumes SDSI. The goals of the SPKI group are to develop Internet standards for an IETF sponsored public key certificate format, associated signature and other formats, and key acquisition protocols. An SPKI Certificate is intended to provide assurance if a public key is authorized to perform some action, e.g., access a system or spend money from a given account, grant or revoke authorizations , delegate authority to temporary , associate a public key with a name , and to disseminate useful information, secure from tampering (e.g., one's own preferred e-mail address or name). SPKI certificates do not directly address the specification of complex policies or the distribution of keys and certificates.

7.2 Trust management vs access control lists: an example

Scenario: Hi-Tech Sports designs and markets golf clubs and tennis rackets. Hi-Tech Sports is a cut-throat business that guards its intellectual property and competitive advantages carefully.

Problem: CEO Ralph sees a new opportunity marketing a redesigned line of clubs to women. He asks VP of Marketing Susan to prepare a description of the new line of clubs, to be endorsed by a prominent woman golfer. Susan asks a manager, Bill, in the Golf Club Marketingdivision to coordinate the project and keep her and Ralph informed. Bill contacts Alice in the Golf Club Engineering division to determine technical specifications of the clubs and work out compromises between appearance, performance, and price. Bill and Alice delegate certain responsibilities to their staff and ask their staffs to collaborate closely.

Document collaboration: Several kinds of documents will provide the basis for collaboration on this project, including planning charts, cost spreadsheets, CAD drawings, and so on. Ralph believes in delegating responsibility, so he would like read permission for all documents related to the project, but not write permission. Susan is a micromanager so she wants read and write permission for all marketing documents. Bill would like to share some marketing documents with Alice and her team, and reserve control of others. Alice works under the engineering division policy that all team members share documents, but no one outside engineering is allowed to modify any engineering document without explicit permission from engineering personnel.

Traditional Access Control Lists: The access control lists for the Hi-Tech Sports project are shown in this table. There are two folders for marketing documents, one for the documents Bill chooses to allow Alice to modify and one for marketing-only documents.

Folder	Read Access	Write Access
Project management	Ralph, Susan	Susan
Marketing Shared with engineering Unshared documents	Ralph, Susan, Bill, Alice Ralph, Susan, Bill,Alice	Susan, Bill, Alice Susan, Bill
Engineering	Ralph, Susan, Bill, Alice	Alice

Characteristics of Access Control List (ACL) solution

· IT will set up folders and establish permissions for each folder. If different divisions have separate file servers, this will involve folders shared between servers.

· Since documents will be created without IT, all documents in a folder will have same permission. It is too cumbersome to maintain ACLs on a per-file basis.

· Most policies can be implemented

o CEO Ralph can read all files

o VP Marketing Susan can read and write project management and marketing files; she cannot write files in the engineering folder.

o Martketing project manager Bill can read and write marketing files and read engineering files.

o Bill can move files between the shared and unshared marketing folders to control which files Alice can modify.

o Engineering project manager Alice can read and write engineering files and can read marketing files.

· Some policies cannot or will not be implemented

o Engineering policy allows Bill to make changes to engineering files if Alice approves them, but there is no way for Alice to grant Bill permission

o If Bill and Alice allocated some staff to the project initially, IT can add these employees to the access control lists. If Bill and Alice reassign staff, the access control lists must be changed.

Access control policies can be implemented at the file level instead of the folder level, at a cost of producing and maintaining a larger number of access control lists.

Trust Management Solution

The TM solution uses local policy logic, combined by a deduction engine. Each employee has a cryptographic key, installed in their computer, that identifies them. File access can be described by policy logic statements. Sample Hi-Tech Sports policy statements that apply to the golf project are shown in this table:

Name	Policy Logic
CEO Ralph	allow read(anyfile) if CEO allow set_policy(mktg_file) if VP_mktg allow set_policy(engr_file) if VP_engr
VP Mktg Susan	allow readwrite(mktg_file) if VP_mktg allow create(mktg_file) if mktg_division
Golf Mktg Mgr Bill	allow readwrite(golf_proj_file) if golf_prof or shared(golf_proj_file)
VP Engr	allow readwrite(eng_file) if VP_mktg or authorized(eng_file)
Golf Engr Mgr Alice

Characteristics of Deductive Policy Logic (DPL) solution

· The policy logic describes company policy, not individual files and folders. The same corporate policies will be applied to all folders when they are created; no basic policy changes are necessary for this project, or any other project!

· The VP of Engineering can set a policy for all engineering files. This policy can allow engineers to delegate authority over files. No IT action is needed.

· Golf Engineering manager Alice does not have to specify any policy; the deduction engine knows that Alice is in Golf Engineering and applies the policy established by the VP of Engineering.

Policy checking and conflict resolution

Policy statements, written in policy logic, can be tested using the deduction engine. Some examples are:

· List all of the individuals that are authorized to perform a given action,

· Make sure no person is authorized to review his own purchase orders,

· Find any conflicts in the policy.

The first example is the simplest. When someone tries to perform an action, the deduction engine decides whether this action is allowed. Since the policy determines the permitted set of person-action pairs, the deduction engine can also determine the set of people who are allowed to do a certain action. More generally, the deduction engine can answer a set of SQL-like queries about the policy logic within an organization or distributed among members of an interest group.

The second example illustrates an unintended consequence of a policy. More specifically, a company may have a policy about how purchase orders are reviewed. After this policy is written in policy logic, the logic designer may wish to test the policy for unintended properties. If the set of policy rules allow someone to approve his own purchase order, the deduction engine can determine this.

Policy conflicts can occur if policy logic with negation is used. For example, suppose Inez’s policy says that Janice cannot access any file she creates. However, Inez’s supervisor might have a policy that allows Janice’s supervisor to delegate access to anyone in her group. Then it may be possible for Janice to read Inez’s files, in violation of Inez’s policy. Policy conflicts can be avoided by assigning a priority to each statement. If a supervisor’s policy takes priority, then every policy is logically consistent. Even though priority is used to avoid logical inconsistency, it is valuable to use the deduction engine to find conflicting policy statements.

7.3 Example: Differential Pricing

This example shows a conference registration site, on the right, with a pricing policy that distinguishes academic participants from regular industrial participants. In particular, a student may register for the conference for $100. This pricing policy reflects the registration costs for the RSA Data Security Conference, for example.

The left column of the figure shows a root certificate authority (CA), which could be Verisign or similar site. The CA issues a certificate to Stanford University and identifies Stanford as an accredited university.

Stanford University issues a certificate to Prof. Mitchell, identifying him as a faculty member. Stanford also has a policy that faculty can identify their students.

Mitchell issues a certificate to Ajay Chander identifying him as a PhD student in the Computer Science department.

When student Ajay Chander registers for the conference, he registers as a student and sends payment for the $100 fee. The registration site can verify that he is a student by combining the information from the four certificates. The process of retrieving and combining certificates to answer a query (such as, “Is Chander a registered student at an accredited university?”) is a function of the certificate and policy infrastructure.

Comparison with access control: In the traditional approach based on access control lists, the registration site would either have to have a complete list of all students at all universities, or decide not to verify that student registrants are truly students.

8. Jini-Based Dynamic Discovery, Query, and Selection

8.1 Jini Architecture and Security

The Jini architecture and application program interfaces provide a convenient and relatively general framework for dynamic discovery and configuration of distributed services. Although Jini is designed to support dynamic system configuration and network communication, the security aspects of Jini are extremely limited.

Jini extends the Java environment from a single virtual machine to a network of machines. In general, a Jini system contains a set of services each of which offers some functionality to any member of a coalition. Services are located and installed using a lookup mechanism that involves network transfer of Java bytecode.

Jini communication is based on Java remote method invocation (RMI). Specifically, if a process on machine A wishes to communicate with a process on machine B, then machine A installs a surrogate stub object that communicates with a corresponding object on machine B through remote method invocation. This surrogate stub object is called a proxy. If the object on machine B provides a lookup service, then the stub object installed on machine A is called a lookup proxy. . If the object on machine B provides a distributed service, then the stub object installed on machine A is called a service proxy.

A Jini client obtains a lookup proxy and a service proxy through the following steps:

· Discovery: The client broadcasts a request for a lookup service. The lookup service responds with a lookup proxy. This stub object (proxy) allows the client to make further queries of the lookup service.

· Query: The client queries the lookup service for a service with specific property. The lookup service responds with a list of services and supplies a list of attributes associated with each service.

· Selection: The client requests and receives a service proxy for a specific service. The result of selection may be a signed or unsigned jar file.

The diagram below shows the communication phases that occur in discovery, query, selection, and installation of a service.

Figure 1: Jini architecture for discovery and installation of service

The first phase, used in discovery, involves communication with a subnet or multicast group, in order to locate a lookup service. In the second phase, which includes query and selection, the agent communicates with the lookup service through a lookup proxy that was obtained by communication from phase 1. While standard Jini uses remote method invocation, other forms of communication could conceivably be substituted. Since the agent must install and execute a lookup proxy (interface or driver), the agent is susceptible to errors or attacks resulting from corrupted or malicious proxy code. In the third phase, the agent interfaces with the installed service through a service proxy. Again, standard Jini relies on remote method invocation, but if the service is distributed, then other communication mechanisms could be appropriate. As with installation of the lookup proxy, the agent is again subject to risks associated with execution of service proxy code received over the network.

The standard Jini security model is simply the Java security model, designed by Li Gong who is a consultant to Stanford on this Dynamic Coalitions project The final jar file received as the result of selection may be signed. The client Java security manager may be configured to provide each lookup proxy or service proxy with specific access rights, according to the signing key used in creation of the jar file. This provides some protection, since it may prevent malicious bytecode attacks. However, a number of important problems must be addressed by extensions to the Jini framework:

· How does an entity prevent malicious attacks through malicious lookup proxies or service proxies?

· If an entity requires a service, and the only available service is unsigned or signed by a key not previously known to the client, how can the client proceed?

· How does the service authenticate the client?

• When a service requests listing with a lookup service, how can the lookup service enforce a listing policy?

8.2 Architecture for trust management and code filtering

The Stanford architecture for trust management and mobile code security is based on enhancements to the Jini primitives and conventions for calling library services under construction at Stanford. The main concepts are as follows:

· Trust between client and server is based on credentials provided by a trust management system. In the Jini architecture, a trust management credential authority and trust management inference engine run as a Jini service.

· The Jini lookup server stores credentials for registered services. Services include credentials in their serviceItem when registering with the lookup service.

· A Jini client establishes trust with a service by sending the credential received from the lookup service to the Trust Management service.

· A Jini client manages mobile code risks by invoking a Java bytecode filter that screens Java bytecode for security risks. The filter may be customized to enforce coding restrictions or software conventions established by a coalition and designed to prevent mobile code attacks.

· A Jini service establishes trust with a client by requesting credentials through the service proxy installed on the client (as part of the normal Jini service configuration) and sending the credential received from the lookup service to the Trust Management service.

The figure above shows a client requesting a service through the lookup service. The service has previously registered with the lookup service and therefore does not participate in this transaction. The lookup service provides the service credential to the client and the client consults a trust management service to determine if the service is allowed for this client. For example, a service may provide maps or navigation information about some area. The client locates an untrusted lookup service and asks for a service that provides navigation information. The lookup service responds and sends a service credential. The client can then consult a trust management service to see if there is a credential chain proving that this is a trusted coalition service. In this process, the trust management service provides the credential chain to the client, eliminating the need for the client to trust the trust management service performing chain discovery.

The following figure shows how the client may filter bytecode implementing the service proxy and received from the lookup service.

After the client has checked the service credentials and requested a bytecode service proxy, this code is sent from the lookup service to the client. The client passes this code through the Stanford bytecode filter, running locally on the client. The bytecode filter is invoked using an extension of the Java class loader, intercepting code before it is installed on the client computing environment. In this process, the client may use the service credential to verify the the service proxy is in fact signed by a key associated with a trusted service.

After the client has installed a service proxy, the client may communicate with the service. At this point, the service must determine whether to trust the client. This steps for accomplishing this are shown in the following figure.

The client uses the service proxy, shown as a shaded square in the client computing environment, to initiate communication with the service. The interface for this communication is set by the service, as part of the service proxy. Therefore, the service may require that the client send a credential as part of the initial RMI call via the proxy. The service then sends the credential to a trust management service to find a credential chain that would prove that this is a trusted or authorized coalition client.

Additional details and data formats are shown in the following figure.

The service registers with the lookup service through the three messages shown on the right. In the first message, the service discovers the lookup service. Then the lookup service responds with a serviceRegister message. Finally, the service registers, sending a serviceItem containing service proxy code (indicated SP), and identification number (ID#), and an attribute list (attr[]). The attribute list will contain a credential.

The steps used by the client for installing the service proxy and establishing trust are shown as steps 1 – 5 on the left. After discovering a lookup service, the client queries the lookup service to obtain a service matching requested attributes. In response, the lookup service sends the serviceItem containing the service credentials. The credentials are then sent to the trust management engine (step 4), with a trust management response in step 5. The client may then install the service proxy and begin communicating with the service, if the trust management engine provides a satisfactory credential chain, or reject the service and request another service from the lookup service.

9. Mobile-Code Security Mechanisms for Jini

9.1 Java bytcode modification

The Java Language has proven useful for a variety of purposes, including system development and the addition of active content to web pages. To protect against execution of erroneous or potentially malicious code, the Java Virtual Machine verifies code properties before execution and performs additional checks at run time. However, these tests will not protect against many forms of undesirable run-time behavior. Moreover, users cannot easily customize the tests that are performed since these are built into the Java Virtual Machine.

Stanford has previously developed methods for enforcing applet properties, in a manner that may be customized easily. The main technique is bytecode modification. Specifically, we have implemented bytecode filters that analyze the content of bytecode files and insert additional bytecode instructions. These additional instructions may monitor and control resource usage, limit applet functionality, or provide control over inaccessible objects. The Java bytecode modification techniques fall into two classes: class-level modification and method-level modification. In class-level modification, references to one class are modified to refer to another class. This may be done in a way that preserves the Java bytecode typing requirements by using class inheritance. Specifically, the modified class may be declared as a subclass of the unmodified class. Class-level modification is simple and fast, but cannot be applied to final classes since the Java language definition prohibits subclasses of final classes. In these cases, method-level modification is used since it may be applied on a method-by-method basis without regard to class hierarchy restrictions.

The Stanford bytecode filter is written in the Java programming language. The filter is general-purpose, reading a modification specification as input. The modification specification lists classes and methods and their replacements, making the filter generally applicable to a variety of situations. The filter is based on a publicly available library, called JavaClass, that is designed for manipulating Java bytecode files.

9.2 Intercepting Jini Bytecode

As described above, a Jini client locates and installs a service through a lookup server. The protocol is implementation specific, meaning that the Jini specification only requires a protocol based on TCP and UDP transport and object serialization. In particular, the specification does not refer to the RMI registry or wire protocols. The only requirement is that Jini interfaces preserve the RMI remote interface semantics, which means that the client needs to declare a RemoteException on its methods. After the lookup server is found, the lookup server sends to the client an object implementing the net.jini.core.lookup.ServiceRegistrar interface. This is done in the unicast discovery protocol. This appears to be the only specified use of RMI in current Jini. This complicates the problem of identifying a well-known, constant path of remote-class delivery rather difficult.

In general, there are three places where one could intercept the service object class bytecode – during transport from the LookupServer to the lookup service proxy, within the ServiceRegistrar before the serialized object is reconstructed, and within the ServiceRegistrar after object reconstruction.

Since it appears infeasible to intercept the service object along the network path, we decided to intercept the object bytecode in the ServiceRegistrar. This is best done before the serialized object is reconstructed, since modifying the bytecode of an object after reconstruction presents problems. (For example, it is difficult to maintain the state of the object.)

In Java, in order to load a class into the JVM execution, one needs a java.lang.ClassLoader object which does the actual loading via the protected final defineClass method. The whole loading process proceeds as follows. If the class name is referenced implicitly during the code execution, the JVM tries to locate in its internal runtime table a class with such name, that, was loaded by the same ClassLoader which loaded the class making the reference. If there is no such class, the JVM calls the method loadClass( className ) on the ClassLoader which loaded the class making the reference. This method first tries to delegate the loading of the class to its parent ClassLoader by calling its loadClass(), and so forth, up until the bootstrap. If all parents fail to locate the class (not previously loaded by them, and unable to find its .class file), then loadClass() calls findClass() in the ClassLoader that initiated the loading process. If findClass finds the .class file, it loads it into a byte array, and then calls the final, protected method defineClass. If findClass fails to locate the class, it throws a ClassNotFoundException.

In the Java API, there is only one network-aware ClassLoader, java.net.URLClassLoader. Even the java.rmi.server.RMIClassLoader class which implements the RMI-related class loading relies internally on a subclass of the URLClassLoader, sun.rmi.server.LoaderHandler$Loader.

This leads us to two possible ways of intercepting service objects. The first one is to assume that the classes for the downloaded service objects will always be loaded into the JVM by using either the URLClassLoader or the RMIClassLoader, and then replace all references to java.net.URLClassLoader with our extension of it, jinifilter.SafeURLClassLoader. The second one is to replace all calls to java.lang.ClassLoader.defineClass() with the static jinifilter.SafeClassLoader.defineClass(). In the current implementation, we chose assume that the classes for the downloaded service objects will always be loaded into the JVM by using either the URLClassLoader or the RMIClassLoader.

9.3 Intercepting Jini Bytecode

In summary, the architecture for filtering Java bytecode and replacing classes with safe library classes is illustrated by the following diagram:

The client class loader is modified so that Jini proxies installed in the client are scanned before they are executed. For example, a service proxy is defined as part of a service, and shown here as a square box with label “S” inside the service site. When the service joins the lookup service, the service proxy is sent to the lookup service. After discovery, in which the client selects this service, the service proxy is sent (in the form of a serialized service object) to the client. After the client receives the service proxy, the modified client class loader invokes the Java bytecode filter. The filter then modifies classes and methods in the service proxy so that safe classes from the safe class library are used in place of standard classes. This allows us to trace file access, trace network access, prevent denial of service attacks by limiting use of specified resources, and so on. In order to monitor network communication by a proxy, we must have a safe class that performs this monitoring. However, we have found it straightforward to construct safe classes for this and other purposes.

Further technical information about Java bytcode filtering and its application to Jini security is described in the attached conference paper prepared for DISCEX 2001.