# Presentation: 363802

## Intelligent Trust 

***Intelligent Trust ***
***for Electronic Commerce***

- Howard “Skip” Chapman
- Business Development
- V :: 703.734.3000 Ext.101
- F :: 703.734.3002
- E :: schapman@conclusive.com

- Jim Heimberg, ABC, PhD
- Technical Sales Engineer
- V :: 703.734.3000 Ext 102
- F :: 703.734.3002
- E :: jheimberg@conclusive.com

**Notes:**
Introductions

## Agenda

- Company Background
- Conclusive’s Key Objective
- Enterprise Requirements
- Benefits of PKI
- Current Issues with PKI
- TrustLogic
- Technical Product Overview

## Company Background

- U.S. Company
- Corporate Headquarters – Tysons Corner, VA
- European Headquarters – Maidenhead, UK
- Regional Offices in Plano, TX and San Jose, CA
- Incorporated in Delaware
- 10 years Corporate experience in information security and cryptography
- Development team with over 100 years cumulative experience in IT security

## Conclusive’s Key Objective

## Key Objective

- by                                   Creating an Enterprise Friendly PKI Environment

- To Enable Secure          Electronic Business

## Friendly PKI Environment?

- Enterprise Requirements

## Friendly PKI Environment?

- In order to accomplish... the Enterprise
- MUST have the:
- Ability to PK Enable multiple applications
- Enterprise must isolate applications from the need to understand PKI and other security technologies
- Ability to define who to trust and how much to trust them

## Friendly PKI Environment?

- Ability to define what user has which role & rule base within individual enterprise applications
- Ability to have **true** End-to-End Encryption
- Ability to have Persistent Proof of transactions

- A Look at PKI Benefits
- and
- Current Issues

## Why PKI? : Benefits

- Authentication of identity
- Confidentiality of data
- Integrity of data
- Nonrepudiation of transaction or event...at that specific point in time

## PKI Deployment Issue?

- How does an organization
- leverage the benefits of PKI...
- and cost effectively conduct secure electronic business and define & manage risk across applications?

## PKI Status

- PKI, though a great core technology, is currently trapped...
-    Why?

**Notes:**
To take full advantage of the opportunity offered by the Internet to extend the reach of applications to the hundreds of millions of users with a PC and Internet access e-communications (HTTP and SMTP) need to be conducted in an environment that can:
extend “trust” as appropriate based on business decisions (business rules driven digital signature trust model)
keep communications confidential to the appropriate parties (role base encryption)
keep an irrefutable record of those communications (evidentiary proof)

The PKI industry has so far failed to deliver on these basic requirements.  To compound the frustration of early adopters, the technologies on offer are difficult to implement, difficult to integrate into applications, and subject to rapid change with little backward compatibility.

## PKI Status

- Lack of “Solutions Orientation”
- Unworkable trust models...binary
- Unworkable multi-domain, multi-vendor interoperability models
- Breaks in the chain of confidentiality
- Lack of evidentiary proof
- Difficult to deploy & integrate into applications
- Unattractive cost:benefit ratio

## Current Issues with PKI

- PKI:  Outstanding Enabling “Core” Technology
- 	Current PKI paradigm does not provide necessary solutions orientation and enterprise defined trust
- Traditional PKI Trust Model is Binary & Closed
- No extension of trust model outside closed user domain
- Current Options = Cross-certification or Bridge CA
- No degrees of trust

## Current Issues with PKI

- Vendor Inter-Operability
- 	Open Standards - Yet PKI and other security technology vendor “standards-based” products do not inter-operate
- Solutions / Applications Deployment
- Each application must understand individual security technologies deployed
- Rules- & roles-based security not addressed
- Persistent Proof
- 	CA – PKI model cannot provide time context nonrepudiation

## Current Issues with PKI

- PK Enabling Multiple Applications &       Deployment of PKI has proven extremely difficult.
- Each application has to be rewritten to “learn” to use individual PKI & Security technologies.
- Different PKI/CA vendors have interpreted & implemented standards in different ways.
- Different PKI/CA vendor client-side key store solutions lock the client into a specific CA technology and/or domain.
- Vendors of associated technologies (X.500 directories, hardware authentication, etc.) all have their own specific interfaces.
- Technologies are evolving rapidly & deployments are obsolete before they go into service.

## Current Issues with PKI

- In the HTTP environment, SSL has been presented as the preferred means to provide confidentiality...However:
- Data is in clear on the web server and user platform – the most likely points of attack
- No provision for role-based confidentiality required for web-based workflow
- No validation of the client certificate presented
- No possibility of granular data level encryption
- Heavy processor overhead, “everything” has to be encrypted

## Current Issues with PKI

- Result:  An extremely attractive core technology with an                       unattractive Cost:Benefit ratio
- Costs have been High:
- Long term service costs are high due to:
- Rework needed on applications
- Each application has to be individually PK enabled
- CA costs are high because of admin & tech cost and limitations associated with registering all users into a single CA
- Maintenance costs are high because enterprise is not future proofed for new technology and revisions

## Current Issues with PKI

- Current PKI Cost:Benefit (continued)
- Benefit has been low for implementing PKI:
- Cannot be rolled out to encompass the heterogeneous universe of a web-based application
- Users with certificates from a variety of CAs, from different CA technologies, & of varied security “quality”
- Users with no certificates at all

## TrustLogic 

- Conclusive has responded with an enterprise-driven & solutions-oriented approach for:
- PK Enabling multiple applications via a common interface that isolates applications from PKI & other security technologies
- Authentication of identities across domains with varying degrees of Trust
- Using Rules & Roles based security across applications
- True end-to-end confidentiality
- Persistent proof that meets business needs

## Solutions Oriented Approach

**Multi Vendor - Security and PKI Management**
**-----------------------------------------------------------------------------------**
**Rules and Roles Based Trust Management **
**-----------------------------------------------------------------------------------**
**Persistent Proof of Transactions**
**-----------------------------------------------------------------------------------**
**End to End Data Level Encryption**

**Vendor “B” **
**CA & Security **
**Technologies**
**TL=3**

**Vendor “A” **
**CA & Security **
**Technologies**
**TL=4**

**E-Commerce**

**Workflow**

**CRM**

**Other**
**Applications**

**Vendor “C” **
**CA & Security **
**Technologies**
**TL=0**

**Vendor “Z” **
**CA & Security **
**Technologies**
**TL=2**

- Solutions-Management Technical Overview

## Key Attributes

**What TrustLogic Does**
- Authenticates signatures issued by any CA
- Allows rules-based control of HTTP communications
- Manages trust using enterprise rules & processes
- Ensures consistent enterprise-wide PKI behavior
- Encrypts data between HTTP applications & users
- Ensures role-based encryption of data
- Data exchange via secure forms with separate access control to fields as well as to the form

**Notes:**
These are the key messages that will be contained in the presentation.  Sales slides may be added at or before this point.  Some of the sales people will have a longer list, but it is important to remember to cover these topics when doing the technical presentation as they are the succinct list of key messages.

## Multiple Technologies of PKI

**Notes:**
This slide defines the intent of enabling Web applications with PKI technology.  It should be pointed out that it demonstrates the market as it exists before the introduction of TrustLogic.  The segue to the next slide is how to accomplish this with PKI enablement.  If anyone asks about the CPS entry on the bottom, remind them that the Certificate Practice Statement drives key management.

## Toolkit Approach to PKI

- 	One-by-one process = unmanageable complexity + high recurring maintenance

**Notes:**
This slide defines complexity of the process without TrustLogic & TrustStream.  The ‘spaghetti’ indicates what happens if the process is to modify applications individually using either Shym (a multi-tiered environment for modifying and generalizing changes to applications) or ColdFusion (a single application at a time)  technologies.  The point is that if an enterprise has more than one application that it wants to modify like this, the complexity level is greatly multiplied with each application that is modified.  With very few applications, the complexity becomes unmanageable, changes to the applications becomes a large hurdle to get over, and keeping up to date becomes practically impossible.  Market research tells us that the average enterprise has multiple web applications that it will want to PKI enable.  Thus, there had to be an easier way.

## PKI Reality...Reviewed

- PKI technology currently operates within a closed user group paradigm and often fails in the Internet environment, precisely where it is most needed.
- Why?
- Unworkable trust models
- Breaks in the chain of confidentiality
- Lack of evidentiary proof
- Difficult to deploy & integrate into applications
- Unattractive cost:benefit ratio

**Notes:**
To take full advantage of the opportunity offered by the Internet to extend the reach of applications to the hundreds of millions of users with a PC and Internet access e-communications (HTTP and SMTP) need to be conducted in an environment that can:
extend “trust” as appropriate based on business decisions (business rules driven digital signature trust model)
keep communications confidential to the appropriate parties (role base encryption)
keep an irrefutable record of those communications (evidentiary proof)

The PKI industry has so far failed to deliver on these basic requirements.  To compound the frustration of early adopters, the technologies on offer are difficult to implement, difficult to integrate into applications, and subject to rapid change with little backward compatibility.

## Conclusive’s PK Enablement

**Notes:**
This slide starts to define the role of TrustLogic & TrustStream as middleware.  In that regard, the key functionalities listed below can be applied to any web application to PKI enable it and can be applied across an enterprise using the middleware single interface.

Multiple Certificate Authority technologies
OCSP & CRL support
Compliant directories
Full audit
Interchangeable cryptography
Data protection & integrity
Hardware & software tokens
Time stamps
Business model drives technology

## TrustLogic – Logical Components

- Applications “talk” to TrustLogic via enterprise-defined processes using XML.

**TrustLogic **
**Process Manager**

**App makes procedure call  + XML**

- 1

- Context Management

- Application

- Session

- User

- 3

**TrustLogic  Services**

**Rules**

- Rules

- Directory

- 3rd Party Rules Engine

- CRL

- OCSP

- Verify
- Certificate

- Directory

- Registry

- Cache /
- Storage

- Encrypt XML

- Decrypt XML

- Transform XML

- Audit
- Log

- Time
- Stamp

- Receipt

- 4

- Processes

- 2

- LDAP

**Notes:**
Applications “talk” to TrustLogic by
 Issuing a Remote Procedure Call to a TrustLogic process and passing the data required by the process in XML. 
 The TrustLogic Process manager retrieves the process definition from the LDAP
 TrustLogic creates a context for every process that includes information about the user, the application, etc. The content of what is held in context is open-ended and the enterprise can add other data it may need. The context is used when rules are context sensitive.
 The Process Manager then steps through the process calling on TrustLogic services and invoking rules. TrustLogic services each understand how to call the low-level components that interface directly with the PKI technologies.

One of the main features of the Process Manager is the ability to record each step in the process. The ability to record what happened, at what time and store the information securely is a key element in any system where there may be a requirement to go back and confirm that an event took place. 

## Web Application Templates

- Conclusive delivers a working, template-driven web application as a starting point for deployment in a web-based environment.

**Notes:**
Conclusive offers a template driven approach to enabling web-applications.  In fact we deliver a complete working web application that demonstrates all the basic technologies.  If the situation calls for a new application the template application can be the foundation.  If it is a case of enabling an existing application the template provides working components that can be cut and pasted and modified as required.

As well as the template web application, Conclusive provides specific editors to create the processes and XML actions.

## Deployment - Overview

- Defining business requirements in terms of authentication, confidentiality, & evidentiary proof is the basis of successful deployment.

- Define application requirements

**1**

- Describe processes

**2**

- Identify rules &
- roles required

**3**

- Write rules &
-  XML actions

**4**

- Write processes

**5**

- Integrate to Application

**6**

- Requirements
- Authentication, Confidentiality, Proof

- Rule Definitions
- User, Unit, Company, CA

- Pseudo code

- TrustLogic XML Editor*

- TrustLogic Process Editor*

- TrustLogic Templates

- Objects in X.500

- Processes in X.500

- Web Application

- Requirements Templates

**Activity**

**Tools**

**Output**

- * = Completed using
- a single GUI

**Notes:**
Clarity “upstream” at the design stage in terms of what authentication, confidentiality, and proof is needed is critically important for a smooth deployment.

Before undertaking integrating TrustLogic the enterprise should have defined:
what are its requirements for authentication
	what is the range of authentication modes that will be accepted?
	what is the initial group of CAs from which certificates will be accepted and what level of trust will be associated with each?
	what level of trust will be required for each different process in the application?
	what should happen if a user cannot offer credentials that are sufficiently trusted?
	etc.
what are the requirements for confidentiality
	looking at a a table of all application data fields, which roles should have access to which data?
	which data will be stored encrypted (and if so does it need to be tagged in any way)?
	if data is stored encrypted what are the arrangements for archiving escrow keys?
	what algorithms and key lengths will be used – which will client machines support?
	etc.
what are the requirements for proof
	what communications are susceptible to dispute and therefore need proof?
	what events will need to be proven?

It should then be able to write out in psuedo code what the processes are, including which rules will be invoked to make decisions.

Only then does the integration work begin.

## TrustLogic

**Notes:**
At this point, the presentation changes from what the current status of events is to what TrustLogic really does.  For this slide, the important thing is that it is a three-fold integration effort, integrating the PKI functionality with not only the web applications, but also with the users.  Each point of this triangle will be discussed starting with the users.

## User Key Selection

**Notes:**
This slide provides a further breakdown of the user portion of overall functions.  What is important here is that the user selects which of multiple possible sets of PKI credentials will be used to access the HTTP application.  By selecting the correct set of credentials at the client end, the appropriate role for the client at the server end will be selected.  If the client selects credentials that are not tied to a specified role, access to the application or to specific information or qualities of the application will not be permitted.

## User Session Initiation

- TrustLogic Server

- X.500/LDAP
- Directory

- Rules
- Processes
- DN
- Other data about User

**TrustLogic**
**Benefits**
-    Proof
-    Control
-    Encryption
-    Decryption

- HTTP Application
-    ----------------
-      Website
-      Application
-      Database

- Storage

- Via client HTTP
- application &
- server

**Notes:**
This slide represents an overview of what is really happening between the  user and the Web application.  The order of TrustLogic and TrustStream services does not matter, but both are implied.  At this point, ensure that the audience understands that when we refer to HTTP applications, we could be addressing webpages, legacy applications, or databases.

## Session Functional Interface

## Data Movement

- The XML Form carries the XML fields into which data can be loaded & both separately signed & encrypted.
- XMLin determines how to decrypt & use the data in the fields throughout the session.
- Java is used as the transport mechanism to move the data around during the session.

## Session Progression

## User Open E-Commerce

**Notes:**
The punch line of this slide is the benefits of the business model driving the technology as indicated by the questions in the lower right corner of the slide.  The overall story is that the:

User selects credentials rather than parameter of PKI domain.
TrustLogic supports common browsers.
Security & business managers decide who to trust & how much to trust them through definition of business processes & rules.

## Trust & Open PKI

- Conclusive offers PKI management that corresponds to how business actually works.
- Trust is a business decision – not dictated by technology
- There are degrees of trust - decisions are made in context (In Situation “A”, I will extend trust to this person; in Situation “B”, I will not)
- Trust is extended, to the appropriate degree, to anyone with whom the business needs to communicate regardless of which CA issued the certificate or how the certificate is stored on the user’s machine
- Users are active – they choose which credentials to present & state their intentions when signing

**Notes:**
Conclusive takes the approach that the enterprise (business or government) should explicitly decide which CAs it will accept certificates from and that it should explicitly decide what level of trust it wishes to associate with each CA (based on its own categories of trust). In this approach “trust” is extended to everyone the application needs to communicate with, as appropriate to the certificate they present.  

The enterprise makes a a business decision in respect to which CAs it will “trust” and the technology enforces those decisions – not the other way around. 

Decisions in respect to accepting certificates are made within each business process – not just as the door. A user may be allowed in but may not be allowed to touch.  Conclusive technology allows the enterprise to define the level of trust needed for each specific event in the application, the certificate a user presents may pass the trust threshold set for log-on but may fail the trust threshold set for issuing a purchase order or signing some data.

Conclusive allows trust to be extended to users regardless of which CA technology issued the certificate the user wishes to present (Conclusive currently supports all the major client side certificate stores and continues to add more).  Using Conclusive technology the enterprise does not have to have a CA (internal or outsourced) and does not have to issue a single certificate.  

## Extending PKI

- Provide confidentiality & authorization
- Manage one-to-many & many-to-many relationships

**Notes:**
This slide provides a further description of advantages.  Tan represents the original PKI implementation for the Simple Mail Transfer Protocol (SMTP) (e.g., e-mail transactions).  The checked are is quasi-authorization based on domain or certificate only, which reinforced the domain parameters that are so prevalent in viewing a PKI today. The canary yellow demonstrates what happens with the addition of web (HTTP) applications and how one application to many users is just a stepping stone to many applications to many users, the point of mass complexity.  The orange are is the result of using rule-based control added by TrustLogic as a middleware component, which finally allows the PKI commodity to achieve all of the goals for which it was intended.

## Application Perspective

**Notes:**
At this point, the presentation moves from discussing the user integration aspects to discussing the HTTP applications, the area in the blue box.

## Application Interface

**Notes:**
This slide depicts the application interface with TrustLogic.  In this case, the application or servlet makes a remote procedures call in whatever language it uses that is then translated into XML for use by TrustLogic.  Based on the remote procedure call and the applicable business processes that are part of that call, TrustLogic parses the directory to obtain the actions, rules, and full content of the business process and returns that information to the TrustLogic engine.  That is the area to the left of the dotted line and represents the external interfaces of the TrustLogic model.  To the right of the dotted line is the internal workings of the TrustLogic model in that XML data is passed between the engine, the user, and the application in the manner of XML forms

## Deployed Application Scheme

- For an application, TrustLogic processes are invoked from servlets that call application logic.

**Notes:**
Conclusive template applications are available in JSP, ASP and HTML.  In each case they use servlets (or equivalent) to provide the application logic.
Application logic can also be held in TrustLogic processes.  If this is the case Conclusive recommends these be stored in an application specific node of the directory.

## Functional Application Interface

- Web Application (e.g. Servlet)

- TrustLogic Services

- Rules

- Business Processes

- Audit Manager

- Properties

- Actions

- Low-Level
- TrustLogic Code

**Notes:**
This slide is a clarification of what is happening in the TrustLogic model where the web application or servlet, through a remote procedure call, calls a business process, which then makes actions occur through the use of rules and services.  In addition, actions are recorded in the audit log.  This is a good point to mention but not dwell on the fact that TrustLogic not only writes to the audit log, but also digitally signs the log and creates a cumulative hash so that the log cannot be changed without it being very clear that a change was made.

## PKI Management Perspective

**Notes:**
At this point, the  focus of the presentation changes to what TrustLogic & TrustStream do with regard to applying PKI functionality, the area in the blue box on this slide.

## TrustLogic – Logical Components

- Applications “talk” to TrustLogic via enterprise-defined processes using XML.

**TrustLogic **
**Process Manager**

**App makes procedure call  + XML**

- 1

- Context Management

- Application

- Session

- User

- 3

**TrustLogic  Services**

**Rules**

- Rules

- Directory

- 3rd Party Rules Engine

- CRL

- OCSP

- Verify
- Certificate

- Directory

- Registry

- Cache /
- Storage

- Encrypt XML

- Decrypt XML

- Transform XML

- Audit
- Log

- Time
- Stamp

- Receipt

- 4

- Processes

- 2

- LDAP

**Notes:**
Applications “talk” to TrustLogic by
 Issuing a Remote Procedure Call to a TrustLogic process and passing the data required by the process in XML. 
 The TrustLogic Process manager retrieves the process definition from the LDAP
 TrustLogic creates a context for every process that includes information about the user, the application, etc. The content of what is held in context is open-ended and the enterprise can add other data it may need. The context is used when rules are context sensitive.
 The Process Manager then steps through the process calling on TrustLogic services and invoking rules. TrustLogic services each understand how to call the low-level components that interface directly with the PKI technologies.

One of the main features of the Process Manager is the ability to record each step in the process. The ability to record what happened, at what time and store the information securely is a key element in any system where there may be a requirement to go back and confirm that an event took place. 

## TrustLogic Services

**Notes:**
This slide shows the services and the categories they fall under that make TrustLogic core processes occur.  They key here is to demonstrate that although it is a complex list, the required functionality is achieved.  By name, the services are fairly self-explanatory.

## Persistent Proof

- Proof of the activity exists after the fact.
- Audit log entries are cryptographically secure.

**Notes:**
This slide should be used as a sample of core process and service integration into function as well as to demonstrate the audit capabilities of the product.  In this case, the TrustLogic product:

Logs events necessary to verify transaction details
Digitally signs log to prevent tampering
Maintains cumulative hash of events
Establishes nonrepudiation

## Granular Security of XML Data

**Notes:**
This slide demonstrates the definition of role-based granular security.  Granular security is desirable because:

Secure individual XML data references may be required
Change user roles without changing role-based encryption
Submissions to web site secured by role key
Transmissions to user still secured by user public key

The full story is that TrustLogic allows the user to select the role and credentials that will be used and then provides access to information down to the level of the XML field based on role authorization.  As an example, cite the medical demo where the doctor has access to all of the information on the patient, but the administrators may only see the billing information, the nurse to the patient care information, the lab to the tests that are prescribed, and a pharmacist to the drug prescriptions.  As such, the key portions of the patient record are available to everyone involved.

- Bringing it all together

**Notes:**
Move into the summarization mode.

## Generic System Architecture

**28**

**Notes:**
Discuss the overall flow of a session from the client (using TrustLogic and their own prior issued keys), the TrustLogic server’s role (setting up the session and managing the PKI functionality), and the interface with the application (using the session controls selected by TrustLogic and then throughout with only the client unless otherwise specified by any particular activities).

## Summary

- Authentication of application users & validity of certificates
- Role-based access to HTTP application services & storage
- Proof of what occurs through signed, unchangeable audit logs
- Encryption & decryption services down to the field level on XML forms, which are used as the basis of transactions between users & applications
- An open PKI free of domain parameters
- Based on an organization’s business model, certificates are accepted from any CA with an appropriate level of trust
- Benefits of PKI are fully available in the HTTP domain without having to modify applications
- Business models drive technology, not vice versa

**Notes:**
These statements should not only reinforce what was said in the presentation and the key messages that were cited at the beginning of the presentation, but also should leave those who heard the presentation or those who only read the printed material with the feeling of what the TrustLogic products are about.  It is important to know how the presentation will end and ensure that all of this was covered in sufficient detail at the proper place in the presentation.

## Conclusive Value Proposition

- Conclusive provides the:
- Ability to PK Enable multiple applications
- Ability to define who to trust and how much to trust them
- Ability to define what user has which role & rule base within individual enterprise applications
- Ability to have **true** End-to-End Encryption
- Ability to have Persistent Proof of transactions

## Questions

- Comments

- Observations