The Internet enables connectivity between many entities that do not recognize each other. In order to do business, they must establish a certain level of trust. The presentation of third party certificates can help to establish trust between the entities. We have developed a new approach that enables business to define flexible policies for mapping strangers to predefined business roles, in which issuers do not need to be known in advance. In turn, according to the policy, they provide certificates that are considered to be from a trusted authority. This allows for the building of trust, thus enabling e-business.
By providing automated role assignment, our approach extends, rather than replaces, the existing role-based access control mechanisms. The existing access control mechanisms use identities, based on a static table, to map the subject to a given role. Our system maps the subject to a role based on: the subject's certificates, a given role assignment policy set by the resource owner, and the roles of the issuers of the certificates. The role is then fed as input to the existing role based access control mechanism. This provides for simple, modular architecture and role assignment policies.
Here we describe an implementation of the automated role assignment mechanisms that can be used to provide a complete PKI-enabled Web server (or other e-commerce server), or to extend access control systems. A central element in our implementation is a simple, yet powerful, Certificate-based Role Assignment Policy Language, specified using XML . We believe that the policy language is expressive enough to allow complex policies including non-monotone (negative) certificates, while being simple enough to allow automated policy checking and processing. Processing of the policy is essential to ensure reasonable efficiency, such as in the handing of a new certificate or revocation, and to ensure a checking policy, which checks for conflicts, collects missing certificates, composes policies, or allows subjects to select which certificates to present. Our system includes an intelligent certificate collector that automatically collects missing certificates from peer servers, allowing for the use of standard browsers that only pass one certificate to the server.
The TE is planned to be submitted to AlphaWorks in the next month.
Trust Establishment Examples
The following are application examples that show the benefits of our Trust Establishment solution.
Example 1 - Kid Communities
Motivation: To create kids' communities in which only children can participate.
Problem description: A Web site designer wants to build a chat forum in which only children can participate. Furthermore, s/he would like to create one forum for kids aged 6 - 9 and a second forum for kids aged 9 - 15. The site designer should be able to identify the age of the accessed clients (child details are anonymous).
Solution: The site designer defines the following policy:
- A child is:
- Someone who brings a certificate from a recognized community organization (e.g., a school, a youth community center, etc.).
- A recognized community organization is either:
- Known locally.
- Certified by some known national organization (e.g., an educational office, a school union, etc.).
- Certified by at least two already recognized community organizations.
- A recognized national organization is either:
- Known locally.
- Certified by at least two already recognized national organizations.
Benefits of the solution: The suggested solution assumes no global CA but allows small communities to grow from the bottom up. For example, some schools can certify each other and create a chat forum for their children. More schools can join the community by bringing certificates from at least two schools that are already in the community. HRL's Trust Establishment system automates the process of adding more recognized organizations through automatic certificate collections. The CAs that produce the certificates are different from the site that runs the policy; hence, the site designer can define flexible policy based on the certificates.
Example 2 - Access to Medical Data
Motivation: To enable access to large medical databases for research purposes, while limiting access to authorized people only.
Problem description: Each hospital or medical institute has data about its own patients. For research purposes, a researcher may want to access data from other institutes as well (accessed data is anonymous). A hospital would like to have a policy that controls data access so that access to cardiology records is allowed only to cardiologists, oncology data only to oncologists, and so on.
Solution: Using HRL's Trust Establishment system a hospital can define the following policy:
- A cardiologist is someone who brings:
- A certificate that states the doctor currently works in a recognized hospital.
- A certificate that proves the doctor graduated as a cardiologist from a recognized University hospital.
- A recognized hospital is either:
- Recognized locally.
- Certified as a hospital by at least three already known hospitals.
- Certified as a hospital by a known health office.
- A recognized University hospital is either:
- Recognized locally.
- Certified as a university hospital that can graduate cardiologists by at least two already known institutes.
- Certified as a university hospital by the council for higher education and by the health office.
Benefits of the solution: There is no need to have a root authority that certifies all hospitals and all university hospitals. Hospitals from different countries can cross certify each other to create a web of trust such that doctors can share data.
Example 3 - Trusted Suppliers
Motivation: A business policy to select a reliable supplier.
Problem description: A business (e.g., a supermarket) wants to select reliable suppliers with which to work. The business may be a branch in a big company and it would like to select its suppliers based on recommendations from other branches in the same company or from recommendations from peer businesses.
Solution: A branch in an organization can define the following policy:
- A recognized branch is:
- Known as a branch inside the organization.
- A recognized peer is either:
- Known to be trusted by the local branch.
- Recommended as a trusted peer by at least two already trusted peers.
- A recognized supplier is either:
- Recommended by some known branch.
- Recommended by at least three different peers.
Benefits of the solution: A branch in a big organization can select its suppliers based on recommendations from other branches in the same organization or from recommendations from peer businesses. The group of trusted peers can grow dynamically, hence, enabling a business to trust more suppliers. Again, there is no root CA that signs to all peers and to all suppliers.
Example 4 - Transportation & Insurance
Motivation: To create a business policy to select a reliable transportation company.
Problem description: A business that frequently uses transportation services needs to select a reliable company to deliver its products. The business wants to make sure its products are insured, at a desired level, while being transported.
Solution: A business can define the following policy:
- A recognized transportation company:
- Can show insurance certificates from one or more recognized insurance companies such that insurance against fire is at least X and the insurance against loss is at least Y.
- Can be recommended by a peer business.
- An insurance company should either:
- Bring a certificate from the inspector of insurance in that country.
- Show that it is insured by some recognized secondary insurance company.
- Be recommended as a trusted insurance company by a peer business.
- A secondary insurance company is either:
- Recognized locally.
- Certified as a recognized secondary insurance company by at least two already known companies.
- A peer business is:
- A locally known business that is trusted to recommend other businesses.
Benefits of the solution: A knowledge database of reliable transportation and insurance companies can be formed. Again, there is no root CA and the information retained in the certificates is independent of the policy.