# Presentation: 142710

## Trustworthy Electronically Signed XML

**mmckennirey@conclusive.com**

- “Trustworthy” Electronically Signed XML &
- Data Confidentiality in Electronic Processes
- An Approach for Compliance with Federal Guidelines
- Presentation to CIO XML Working Group, March 19, 2003

**Notes:**
Introductions

## Agenda

**Today’s presentation**
**Part 1. Meet GPEA requirements**** **
**Use XML signature to comply with NARA and DOJ guidelines for creating and preserving “trustworthy” digitally signed documents:**
**Records Management Guidance for Agencies Implementing Electronic Signature Technologies,  National Archives and Records Administration, October 18, 2000**
**Legal Considerations in Designing and Implementing Electronic Processes A Guide for Federal Agencies,  Dept. of Justice, November 2000**
**Part 2. Comply with Federal legislation on data confidentiality**** **
**Use XML encryption for data confidentiality and to enforce role-based access in electronic workflow.**
**Computer Matching and Privacy Protection Amendments of 1990, Privacy Act of 1974**
**Health Insurance Portability and Accountability Act of 1996 ("HIPAA") **
**Gramm-Leach-Bliley Act of 1999, Privacy of Consumer Financial Information Regulation  SEC 17 Cfr Part 248**
**Guidance on Inter-Agency Sharing of Personal Data - Protecting Personal Privacy, OMB December 20, 2000**

## Presentation Resources

**For those joining by tele-conference, or for further research, resources for this presentation are available as follows:**
**HTML version of Presentation**
_**[http://www.conclusive.com/download/XMLWG19Mar03.](http://www.conclusive.com/download/XMLWG19Mar03.htm)**__**[htm](http://www.conclusive.com/download/XMLWG19Mar03.htm)**_
**Presentation (PDF format)**
_**[http://www.conclusive.com/download/XMLWG19Mar03.](http://www.conclusive.com/download/XMLWG19Mar03.pdf)**__**[pdf](http://www.conclusive.com/download/XMLWG19Mar03.pdf)**_
**OR at**
_**[http://xml.gov/agenda/20030319.htm](http://xml.gov/agenda/20030319.htm)**_
**XML documents**
**XML document for slide extracts (generic XML structure)**
_**[http://www.conclusive.com/download/XMLWG19Mar03XML.xml](http://www.conclusive.com/download/XMLWG19Mar03XML.xml)**_
**XML from demo application, retrieved from Audit Vault**
_**[http://www.conclusive.com/download/XMLWG19Mar03_epay.xml](http://www.conclusive.com/download/XMLWG19Mar03_epay.xml)**_
**PDF output from demo application**
_**[http://www.conclusive.com/download/XMLWG19Mar03_epay.pdf](http://www.conclusive.com/download/XMLWG19Mar03_epay.pdf)**_

## Part 1 Objectives: GPEA Requirements

**Part 1. Meet GPEA requirements **
**Paperwork elimination requires legally effective electronic signature.**
**Guidance has been provided by **
**National Archives (NARA) in respect to what is “trustworthy” and what they believe is necessary to preserve electronically signed documents**
**Department of Justice (DOJ) in respect to the legal considerations involved in electronic processes**
**This part of the presentation will lay out how NARA and DOJ guidance can be applied to XML documents using W3C XML signature standards and Public Key Infrastructure (PKI) technology.**

## Approach to Today’s Presentation

**The presentation today will create an XML document that is electronically signed and preserve it applying NARA guidelines for both processes.  **
**Document will be XML that conforms to W3C XML Schema**
**Document is created and edited in the context of a web application (example is filling in an XML electronic form)**
**Document is electronically signed (W3C XML digital signature with PKI certificate) and includes confidential data which is encrypted (W3C XML encryption)**

## Characteristics of a “Trustworthy” Record

**NARA definition of the characteristics of electronically signed trustworthy records (also ISO 15489):**
**Reliability: **
**Content can be trusted as a full and accurate representation of the transaction(s)**
**Authenticity: **
**Can be proven to be what it purports to be and to have been created or sent by the person who purports to have created and sent it.**
**Integrity: **
**The integrity of a record refers to it being complete and unaltered.**
**Usability: **
**Can be located, retrieved, presented, and interpreted.**

**Notes:**
Authenticity
Requires: policies and procedures which control the creation, transmission, receipt, and maintenance of records to ensure that records creators are authorized and identified and that records are protected against unauthorized addition, deletion, and alteration. 

Integrity
Requires: structural integrity of a record. “its physical and logical format and the relationships between the data elements comprising the record, should remain physically or logically intact”

Usability
Requires: identify a record within the context of broader business activities and functions. The links between records which document a sequence of activities should be maintained. These contextual linkages of records should carry the information needed for an understanding of the transaction that created and used them.

## Preserving Trustworthy Records

**To preserve “trustworthy” documents NARA guidelines are: “It is necessary to preserve its [the document’s] content, context, and sometimes its structure.”**

**<****payment****>**
**<****status****>****New****</****status****>**
**<****serial****>****7****</****serial****>**
**<****request_fname****>****Barb****</****request_fname****>**
**<****request_lname****>****Lance****</****request_lname****>**
**<****date****>****2003-02-20 13:29:50****</****date****>**
**<****total_amt****></****total_amt****>**
**<****comment****>”****Comment****“</****comment****>**
**<****myfile****>**
**<****name****>****Payments_CT.xls****</****name****>**
**<****size****>****27648****</****size****>**
**<****date****>****1/21/03 11:19:06 AM EST****</****date****>**
**</****myfile****>**
**<****ownerdn****>****Barb Lance****</****ownerdn****>**
**<****managerdn****>****E-PAY-PLI/Treasury****</****managerdn****>**
**<****hrdn****/>**
**<****test****/>**
**<****tlauditrecord****/>**
**</****payment****>**

**Content**
**(Signed)**

**Structure**
**“****Presentation”**

**Context**

**What application?**
**Who were the parties?**
**What role did user have?**
**What credentials were presented?**
**What authority was cited?**
**When did this occur?**
**What jurisdiction had authority?**

**Trustworthy Record**

**Notes:**
Content: 
electronic signature or signatures in a record are part of the content. 
Context:  
individual identifiers that are not embedded in the content of the record, trust paths, and other means to create and verify the validity of an electronic signature
Structure: 
its physical and logical format and the relationships between the data elements comprising the record remain physically and logically intact.

## Elements of a Trustworthy XML Document

**To conform to guidelines, the high level structure of our XML document will consist of these 3 elements: Context, Content (which is signed), and Structure. **
- [From here on, to avoid confusion with the structure of the XML, we will refer to NARA’s definition of Structure as the “Presentation” of the XML–  that which defines the user experience of the XML.]

**<?xml version="1.0" encoding="UTF-8"?>**
**<!–****Structure of NARA compliant signed XML document****-->**
**<****Transaction****>**
**<****Context/****> <!–**** identifiers to establish validity ****-->**
**<****Content****> <!–**** self-explanatory ****-->**
**	****<****Signature/****>  <!–**** Signature(s)****-->**
**  ****	****<****EncryptedData/****> <!–**** Encrypted data ****-->**
**</****Content****>**
**<****Presentation/****> <!–**** the user experience of the XML ****-->**
**</****Transaction****>**

**Presentation**

**Content**

**Context**

## Context

**Let’s start with Context. This is where we record session, authorization, and credential information that describes the context in which the XML was created or modified. This <Context> will be “extensible” to add any “identifiers” required.  **

**<?xml version="1.0" encoding="UTF-8"?>**
**<!--**** Example of type of data to be captured in Context ****-->**
**<****Transaction****>**
**<****Context****>**
**<****userUniqueID/****> **** ****<!–**** User Identity ****-->**
**<****timestamp/****>****  ****<!--**** Time Transaction started ****-->**
**<****sessionID/****>****  ****<!--**** HTTP session ID ****-->**
**<****userRole/****>**** ****<!--**** Role assigned to user ****-->**
**<****certIssuer/****> **** ****<!--**** Certificate Authority ****-->**
**<****clientTokenType/****> **** ****<!--**** Type of token used ****-->**
**<****application/****>****  ****<!--**** Name of application ****-->**
**<****serverID/****>****  ****<!--**** Identity of server ****-->**
**<****authName/****>****  ****<!--**** Name of the authority ****-->**
**<****organization/****>****  ****<!--**** Name of the organization ****-->**
**<****/Context****>**
**<****/Transaction****>**

**Context**

## Sign Context

**Because Context is critical, we will sign it, both by the application and by the user. To keep things straight we will structure our XML with a Header and Body and put Context into the Header.**

**<!--**** Example of type of data to be captured in Context ****-->**
**<****Transaction****>**
**<****Header****>**
**  ****<****Context****>**
**	****	****<****Header****> ****	****	**
**	****	****   ****<****Signature/****> <!–**** Signature of application ****-->**
**  ****	****<****/Header****>**
**  ****	****<****Body/****>   <!–**** Various identifiers ****-->**
**  ****<****/Context****>**
**  ****<****Signature/****>  <!–**** Switches between user and app ****-->**
**<****/Header****>**
**<****Body****>**
**    ****<****Content/****>**
**    ****<****Presentation/****>**
**<****/Body****>**
**<****/Transaction****>**

**Presentation**

**Content**

**Context**

## Content

**The next high level element in our XML is Content. A design objective is to make **_**any**_** XML document “trustworthy”, regardless of its own internal structure and content. In today’s example we use a <SecureForm> with signature and encrypted data elements. Any XML document could be included here.**

**<****Transaction****>**
**<****Header****>**
**   ****<****Context/****> <!–**** Context information ****-->**
**</****Header****>**
**<****Body****>**
**    ****<****BodyContent****>**
** ****<****SecureForm****>**
**    ****<****Data/****> <!–**** The Content ****-->**
**       ****<****Signature/****> <!–**** Signature info ****-->**
**       ****<****EncryptedData/****>  <!–**** Encrypted data ****-->**
**  ****<****/SecureForm****>**
**       ****<****Presentation/****>  <!–**** User experience ****-->**
**    ****<****/BodyContent****>**
**<****/Body****>**
**<****/Transaction****>**

**Presentation**

**Content**

**Context**

## Sign Content

**NARA requires that signature be part of the preserved Content. Considerations in respect to the application of signature include:**

**Ensure the appropriate content is actually signed**
**Ensure the means of signature conforms to a recognized standard**
**Ensure the signature is valid (in PKI:verifies, not revoked)**
**Ensure the signatory knows what they are signing. Be able to demonstrate the signatory was made specifically aware of what they were signing**
**Capture the reason (why) for the signature. Does the signatory mean to indicate they (a) saw the document? (b) attest to some part of the document ?(c) are bound by the document?, etc.**
**Only sign what the signatory intends. If the signatory does not mean to attest to the validity of other users’ statements, the latter should not be signed by them.**
**Ensure a signatory knows what others have signed. Be able to demonstrate the signatory specifically knew what others signed.**

## Presentation

**The final high level element of our XML is the Presentation of the document (“Structure” in NARA terms). Preserving the Presentation is critical to the interpretation of the signed XML. The same XML Content may be presented to, and experienced by the user, in many different ways in the same application. **

**An interactive form in a browser (XForm or similar). The visual presentation (Prompts, Drop downs etc) is important to know what the user intended.**
**A voice response system (VoiceXML).  Voice prompts and choices are critical to knowing what the user intended.**
**A graphic or other printed document  (SVG / XSL / XFO) **
**Others means yet to be invented **
**    ****(3D Hologram?)**

**<****Presentation****> **
**    ****<****Form****>**
**	****<****Reference**** URI****="“/>**
**    ****</****Form****>**
**    ****<****VoiceXML****>**
**	****<****Reference**** URI****=""/>**
**    ****</****VoiceXML****>**
**    ****<****SVG****>**
**	****<****Reference**** URI****=""/>**
**    ****</****SVG****>**
**</****Presentation****>**

**abc**

## Separation of Presentation and Content

**To facilitate integration of the signed XML with the rest of the infrastructure and with other XML applications the <Presentation> is structurally separate from the <Content> in the XML. **
**Supports simultaneous multiple forms of presentation from the same XML Content**
**Supports integration with other XML applications**
**Minimizes storage / bandwidth requirements – store / download 1 copy of the “presentation”, not “n” copies**
**Forms: the simple form in today’s demo has 29 Kb of content (after the 1st signature) and 146 Kb of presentation. Difference in storage / download requirements for this simple form is a 6:1 ratio**
**Forms: don’t force users to download formats they already have in order to complete another instance of the same form**
**Forms: supports automatic, instant, deployment of revisions to forms: change version number of form in XML document template on the server and all users will use the new version the next time they connect to the application**
**Forms: separation of content and presentation may be critical for the practical preservation of forms created annually in tens of thousands of copies (storage and processing requirement)**

## Presentation Integrity

**<****Header/****>  <!–**** includes Context ****-->**
**<****Body****>**
**    ****<****BodyContent****>**
** ****<****SecureForm/****>**
**    ****<****Presentation****>**
**<****Form****>**
**   ****<****Reference URI****=“">**** **** **
**<****DigestMethod**** ****Algorithm****=""/>**
**<****DigestValue/****>**
**   ****<****/****Reference****>**** **** **
**<****/****Form****>**** **** **
**    ****<****/****Presentation****>**
**<****/BodyContent****>**
**<****/Body****>**
**<****Signature/****>**
**<****/Transaction****>**

**The Presentation is treated as a resource and identified by a “URI”. To ensure its integrity the hash of the presentation resource is signed within the trustworthy XML document such that the integrity and authenticity of the presentation layer can be verified. **

**Presentation Layer Integrity**

## Preservation: NARA Guidelines

**We now have all the elements NARA identifies for preservation to create a trustworthy document: Context, Content (Signed), and the Presentation layer. **
**The next step is to ensure the preservation mechanism meets guidelines as well. **
**NARA recognizes two approaches to preservation:**
**(1) Maintain documentation of the proof of the validity of the document at the time the record was signed – retain contextual information and documentation of process**
**OR**
**(2) Maintain the ability to re-validate the digital signature –retain ability to perform digital signature verification**

## Preservation Requirements

**Our approach is “best of both”, conform to the  latter (re-validate signature) and include the contextual elements of the former. **
**Ensure the document’s integrity over time (internal integrity)**
**Ensure the integrity of the sequence of events that created the document (sequential integrity)**
**Preserve the integrity of the user experience at the time (presentation integrity)**
**Ensure the usability of the stored document: the mechanism of preservation must be able to reproduce the document as the user experienced it**
**Avoid proprietary or non-standard technologies (hardware, software, data formats) to mitigate issues of obsolescence**

## Integrity of Preserved XML

**To preserve the document, we store the XML in a SQL compliant database (TrustLogic Audit Vault) that is cryptographically “enhanced” to preserve records. **

**Metadata**

**XML Document**

**Record Integrity**

**Internal and sequential integrity: each record is hashed and each record holds its hash and a cumulative hash with the previous record**

**Metadata facilitates document search and exploitation of the document set . Other metadata (not shown) is held in a separate table within the database.**

**XML document, including signature and encrypted data**

**[Interface to table shown here is MySQL Control Center]**

- This is a partial view of the EventDetails table from TLAudit, the “protected” audit database of TrustLogic.

## Usability of “Preserved” XML

**The TrustLogic Audit Viewer interface to the digital vault makes the document available as any of: (a) the Audit record with its metadata, (b) as XML (c) as presented to the user at the time. It also provides verification of signature(s) in the document. (Signature verification shown).**

## Demo: Signature and Preservation

**Today’s demo shows how this all works in practice.**
**Workflow: (1) payment request, (2) approval, (3) issuance**
**Form is XML, each user signs their data, confidential data is encrypted (more on that later)**
**“****Presentation” alternatives include:**
**(1) Interactive form: XSL + JavaScript  using a commercial browser as interface**
**(2) PDF record (at user’s option) : using XSL + XFO**
**“****Preservation” mechanism is TrustLogic Audit Vault**
**Decision on what is preserved is determined by application**
**PKI based cross domain authentication**
**Users have a variety of tokens and certificates from different trust domains **
**Different Certificate Authorities each with their own certificate profiles, policies, and revocation technologies **

## Demo

**The demo will step through two processes in the workflow: create the XML then modify the XML  by another user, each user signing data they create and encrypting specific elements for specific roles.**

**Process 2:  Update XML Document**
**Client side operations**
**Logon (2nd role in payment sequence)**
**Retrieve payment request**
**Verify existing signatures**
**Complete approval and submit**
**Logoff & close browser**
**Server side views**
**View updated sequence of events in Audit**
**Retrieve preserved form from Audit **
**verify signature **
**view as XML **
**view as Form**

**Process 1: Create XML Document**
**Client side operations**
**Logon & download form**
**Complete form (payment request)**
**Sign & Save for off-line editing **
**Logoff & close browser**
**Using local copy retrieve form, edit, save, print PDF**
**Logon**
**Upload saved form**
**Server side views**
**View sequence of events in Audit**

## XML Form in HTML

**The <Presentation> in today’s demo uses XSL and JavaScript to interact with the XML through a commercial browser. This approach  does not impose any constraints on the web application developer in terms of user interface and application functionality.**

**User Name and Authorized Role**
**(Demo application design element)**

**XSL / JavaScript Presentation of XML**

**Authentication & Authorization Info (Demo application design element)**

- The TrustLogic infrastructure preserves the presentation layer but plays no role in the design of the user interface – that is an application responsibility.

## Application of Policy Rules

**When the user logs on, or as required by the application,  policy rules are applied based on the user’s role. These are defined and managed through the Policy Manager interface. **

- Policy rules may include topics such as what assurance levels are needed to permit a user to logon to the application or to execute a process, etc.

**Hierarchical Role Structure for application of rules – matches Role structure for cryptographic access control to data**

**Role name / Rule intersects where rules are defined: can be (J) Java, (B) Boolean, (N) Number or (S) String**

**Policy rule names**

## Signature Confirmation

**When the user submits the form, a signature confirmation dialog asks the user to confirm precisely (a) what they are signing, (b) what identity they are using, and (c) for what reason they are signing. They may save a copy locally and encrypt that copy.**

**Data to be signed**

**Identity being used**

**Reason for Signature**

- Signature confirmation is a function of the TrustLogic Agent software – not the web application and is a consistent interface for the user across all web applications.  It will always present the data to be signed and get user confirmation. The web application cannot get anything signed without the user being consciously aware of using their “signature”

## Off Line Operations

**When off line the user can verify signatures on local copies, continue to edit the XML in a browser, or generate a PDF file from the XML. (Create PDF shown)**

- The PDF is created using XSL / XFO. The PDF format is text searchable.
- When the XML is edited and saved off-line all the cryptographic security (signature and encryption) continues to be applied.

## Signature Verification

**To keep users informed of the authenticity of data, any accessible signatures on XML presented to them are displayed. The verification, for as many signatures as are found, includes (a) what was signed (b) who signed (c) what reason did they give.**

- Signature verification, like confirmation, is a function of the TrustLogic Agent software – not the web application and is a consistent interface for the user across all web applications.
- Within the verification dialog the user can extract file attachments and save them locally in their original format.

**Number of Signatures**

**Signatory**

**Reason for Signature**

**Signed Data**

**Attachment**

## Usability: Retrieve the XML with Presentation 

**The secure XML can be retrieved from the Audit Vault, and presented in the same manner as the user experienced the XML. Role based cryptographic data security always applies.**

- The saved form is presented here to the System Administrator whose role does not allow data access to encrypted elements on the form. A user with role access would “see” all the data.

**Data elements saved in clear**

**Data elements saved encrypted for a specific role(s)**

## Summary Part 1: NARA compliance

**That’s the end of Part 1 of our presentation: creating signed XML documents and preserving them in accordance with NARA and DOJ guidelines. **
**To sum up Part 1:**
**Our XML document captures:**
**Context**
**Content**
**Presentation**
**The mechanism of preservation maintains the internal integrity of the XML document and the sequential integrity of its creation and modification (including Context and Presentation)**
**The interface to preserved XML documents provides for:**
**Re-validation of signature**
**Retrieval as XML**
**Retrieval as Presented to user**

## Part 2 Objectives: Data Confidentiality

**Part 2. Comply with legislation on data confidentiality**** **
**Requirements for data confidentiality have been established in a range of Federal (and State) legislation and regulation**
**Computer Matching and Privacy Protection Amendments of 1990, Privacy Act of 1974**
**Health Insurance Portability and Accountability Act of 1996 ("HIPAA") **
**Gramm-Leach-Bliley Act of 1999, Privacy of Consumer Financial Information Regulation  SEC 17 Cfr Part 248**
**Guidance on Inter-Agency Sharing of Personal Data - Protecting Personal Privacy, OMB December 20, 2000**
**This part of the presentation will lay out how data confidentiality can be ensured in electronic processes where the data structure is XML by using W3C XML encryption and Public Key Infrastructure (PKI) technology.**

## W3C XML Encryption

**<EncryptedData Id="1045766063567" xmlns="http://www.w3.org/2001/04/xmlenc#">**
**<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc">**
**<Parameter Name="AlgorithmMode" Value="http://www.conclusive.com/2000/02/xml-crypto#mode-none"/>**
**</EncryptionMethod>**
**<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">**
**<KeyName>119509261</KeyName>**
**<KeyValue>**
**<RSAKeyValue>**
**<Modulus>AKjxh9XnlDDT3FTXkON5qsFJk379e2vVAmq2Hgpo6q9irDG/M8uD/rj</Modulus>**
**<Exponent>AQAB</Exponent>**
**</RSAKeyValue>**
**</KeyValue>**
**<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">**
**<EncryptionMethod Algorithm="http://www.conclusive.com/2000/02/xml-crypto#rsa">**
**<Parameter Name="AlgorithmMode" Value="http://www.conclusive.com/2000/02/xml-crypto#mode-none"/>**
**</EncryptionMethod>**
**<CipherData>fot8cr1bPTVaWLv9m/gD3IRfglyQW</CipherData>**
**</EncryptedKey>**
**</KeyInfo>**
**<CipherData>**
**<CipherReference URI="">**
**<Transforms>**
**<Transform Algorithm="http://www.conclusive.com/2000/02/xml-ref">**
**<DATAREF>//_ENCRYPTED[@DATAREF=&quot;Payee_Account&quot; and @Index=&quot;1&quot;]</DATAREF>**
**</Transform>**
**</Transforms>**
**</CipherReference>**
**<CipherValue>GJm8G8ETkVJeMLk1wGsDo4E6ib9zIoyvhVEyaiQJPIE8A1YLrtKiVRobVS9emPaL</CipherValue>**
**</CipherData>**
**</EncryptedData>**

**W3C XML encryption defines a “unique” encryption event. A single event in which something is encrypted and the result stored in an XML structure.   **

**Algorithm**

**Key Info**

**Cipher Data**

**“****In accordance with the requirements document the interaction of encryption and signing is an application issue and out of scope of the specification”. [W3C XML Encryption Syntax and Processing, December 10, 2002 para 6.1]**

_**Important Note:**_

## Encryption Sequences in an Interactive Application

**Encryption in an interactive web application and throughout a workflow process is, however, anything but a “unique” event. It is a ballet of cryptographic operations that are choreographed in interdependent sequences as data is exchanged between users within a web application. Three such “sequences” need to be defined, in a manner that ensures they are all coherent.**

**(1) **_**Internal**_** sequence describes which elements to be processed within the document and in what order crypto operations occur.**

**Application**

**Sign:**
**<Data/>**
**<Data/>**
**Encrypt:**
**<Data/>**
**Sign:**
**<Data/>**

**(2)**_** Interactive**_
**sequence defines operations at application and user locales as data moves back and forth.**

**Sign:**
**<Data/>**
**<Data/>**
**Encrypt:**
**<Data/>**
**Sign:**
**<Data/>**

**Sign:**
**<Data/>**
**<Data/>**
**Encrypt:**
**<Data/>**
**Sign:**
**<Data/>**

**User “A”**

**User “B”**

**User “C”**

**(3) **_**Workflow**_** sequence defines operations as encrypted data moves between users**

**1**

**2**

**3**

## Internal Encryption Sequence

**   ****<Element1>**
**      ****<Child1_1/>**
**      ****<Child1_2/>**
**   ****</Element1>**
**   ****<Element2/>**
**   ****<Element3>**
**      ****<Child3_1/>**
**      ****<Child3_2/>**
**      ****<Child3_3/>**
**   ****</Element3>**
**</XML>**
**     **

**The internal sequence defines which XML elements in the document are to be cryptographically protected, in what order using what keys and algorithms.**

**<****OP**** Type****="****sign****“ ****Keys****=“****user****“>**
**  ****<Child1_1/>**
**  ****<Element2/>**
**</****op****>**
**<****Op**** Type****="****encrypt****“ “****Keys****=“****role1****“>**
**   ****<Element1>**
**      ****<Child1_1/>**
**      ****<Child1_2/>**
**   ****</Element1>**
**   ****<Element2/>**
** ****</****op****>**
**<****Op**** Type****="****encrypt****“ “****Keys****=“****role2****“>**
**   ****<Child3_2/>**
**   ****<Child3_3/>**
** ****</****op****>**

## Interactive Encryption Sequence

**The Interactive sequence describes what happens at the 4 points in time where XML cryptography takes place as data moves from the application to the user and back. The OnSubmit and OnLoad events are typically cryptographically mirror images of each other. **

**App**

- Data

- <XML>

**XML Actions**
**<OP=sign>**
**<OP=encrypt>**

**Server OnSubmit**

**1**

**XML  Actions**
**<OP=decrypt>**
**<OP=verify>**

**Browser OnLoad**

**2**

**XML Actions**
**<OP=sign>**
**<OP=encrypt>**

**Browser OnSubmit**

**3**

**XML Actions**
**<OP=decrypt>**
**<OP=verify>**

**Server OnLoad**

**4**

**User**

## Workflow Encryption Sequence

**In the Workflow sequence, role based encryption is used to allow authorized persons, whose identity is not known when the data is encrypted, access to the encrypted data.**

**Authorize User to a Role**

**User “A” **

**Provide Role Key(s) to Encrypt Data**

**Return Data Encrypted Under Role(s)**

**User “A” **

**User “B” **

**Authorize User to a Role**

**Data Sent Under User’s Key & Provide Role Keys**

**Return Data Encrypted Under Role(s)**

**User “B” **

**Data Stored Under Role Key(s)**

**On user data request, retrieve XML, perform Key “Translation” to Encrypt Data Under User Key**

**Data Stored Under Role Key(s)**

**1**

**2**

**3**

**4**

**5**

**6**

**7**

**8**

**9**

## Encryption Sequencing Requirements

**At each point in this series of sequences questions need to be answered, and the responses have to be coherent throughout the sequences: **
**What is the event that initiates a cryptographic operation?**
**What cryptographic operations should be performed for that event?**
**In what order? **
**Which XML data elements are to be processed?**
**Where is the “protected” output to be stored?**
**How should the original data type be recorded (if not XML)?**

## XML Structure of <Actions>

**    ****<****Actionset**** Name****=“****workflowProcessPart1****“/>**
**    ****<****Actionset**** Name****="****workflowProcessPart2****“>**
**<****Action**** Name****="****serverprotectform****"**** Event****="****onsubmit****"></****action****>**
**<****Action**** Name****="****browserupdateform****"**** Event****="****onload****"></****action****>**
**<****Action**** Name****="****browserupdateform****"**** Event****="****onsubmit****">**
**   ****<****OP**** Type****="****sign****"**** Keys****=“****recipientcert**** "></****op****>**
**   ****<****Op**** Type****="****encrypt****"></****op****>**
**</****Action****> **
**<****Action**** Name****="****serverunprotectform****"**** Event****="****onload****"></****action****>**
**    ****</****Actionset****>**
**    ****<****Actionset**** Name****=“****workflowProcessPart3****“/>**
**    ****<****Keytable****>**
**<****KEYID**** Name****="****recipientcert****"**** Type****="****recipient****"/>**
**    ****</****Keytable****>**
**</****Actions****>**

**Our approach is to define the cryptographic sequencing in XML as <Actions>. Each <Action> is a cryptographic operation associated to a specific HTTP event. These are collected into an <Actionset> that describes a complete interactive sequence. **

**Internal Sequence**

**Interactive Sequence**

**Workflow Sequence**

- This is a simplified extract from an XML document with much of the detail removed

## Protection of <Actions>

**The <Actions> XML is itself cryptographically protected to ensure its integrity. <Actions>, and all TrustLogic XML objects, are stored in a database where each record is signed and verified at run time. Objects that fail signature verification will not be processed**

**Record **
**Integrity**

**Each record is signed and signature verified at run time**

**Form Name**

**Presentation Layer Integrity**

**XML Crypto Actions Define Cryptographic Operations on Form throughout its life cycle**

**Form Presentation**

**Form **
**URI**

**Form **
**Hash**

**[Interface to table shown here is MySQL Control Center]**

- This is a partial view of the Forms table from TLData, the metadata database of TrustLogic.

##  Object Manager Interface to <Actions>

**“****Object Manager” the TrustLogic interface to <Actions>, and all TL objects, uses certificate based authentication and role-based access to control the modification of <Actions>. (Approve Payment shown)**

**Internal Sequence**

**Interactive Sequence**

**Workflow Sequence**

**Detail of a specific XML cryptographic operation**

**Protected objects for **
**E-PAY application**

**Other applications**

**Global objects**

- The TrustLogic database protects all security related XML objects: Authority, User and Role profiles, Actions and Rules, at both the application and global level.

## Rationale for <Actionset>

**We intentionally define the cryptography on collections of data elements. Processing data elements one-by-one would:**
**Be excessively onerous on the processor**
**Make cryptographic sequencing very difficult **
**Result in very large XML documents **
**Each of XML DSIG and XML ENC structures add up to 20 to 30 lines of XML for each element signed or encrypted**

## <Actions> and <Keys> in XML structure

**The <Actions>, and their associated <Keys> needed for role encryption, complete the structure of our protected XML document. They are an integral part of the document to ensure the protection of the XML at all times.**

**<!--**** Example of structure for an XML payload ****-->**
**<****Transaction****>**
**<****Header/****>  <!–**** includes Context ****-->**
** ****<****Body****>**
**    ****<****BodyContent****>**
** ****<****SecureForm****>**
**    ****<****Data/****> <!–**** Content ****-->**
**    ****<****Actions/****> <!–**** Cryptographic instructions ****-->**
**    ****<****Keys/****> <!–**** Keys for role encryption ****-->**
**   ****<****/SecureForm****>**
**       ****<****Presentation/****>  <!–**** Presentation layer ****-->**
**    ****<****/BodyContent****>**
**<****/Body****>**
**<****/Transaction****>**

**Presentation**

**Content**

**Context**

## Putting it Together

**At run time, the protected XML is put together from the <Context/> created during user authentication, the <Content/> provided by the application and  <Actions/> and <Presentation/> stored by TrustLogic. The complete XML can be preserved in the Audit Vault.**

**Authenticate User and Authorize to a Role**

**User **

**1**

**App **

**<Context/>**

**<Actions/>**
**<Keys/>**

**<Presentation/>**

**TL Secure**
**Database **

**3**

**App **

**Return Protected XML**

**Create Context**

**Create Protected XML**

**<Context/>**

**<Content/>**

**<Actions/>**
**<Keys/>**

**<Presentation/>**

**<XML> **

**</XML> **

**User **

**App **

**2**

**User Requests Data**

**Data Request**

**User **

- In TrustLogic all XML objects needed by the application are stored in a database where they are signed by TrustLogic and the signature is verified at run-time to ensure their integrity

**App**
**Database **

**<Content/>**

## Attachments

**To support existing document formats, TrustLogic provides for attached files, of any format, within the XML document, and extends to these attachments the same signature and encryption as on the XML. TrustLogic provides a standard, non-proprietary means to “sign” any file regardless of format. **

-  <File>
-  </File>

- ---------
- --------
- ---------
- ---------

**U.1**

**Binary **
**File**

**base64 encoded**
**XML signature & encryption**

**---------**
**--------**
**---------**
**---------**

**XML**

**Any **
**Format**

**The embedded file becomes part of the protected XML document, the XML can be used as “metadata” to describe the attachment.**

## Redaction

**Role based encryption, and the ability to save the document as XML or searchable PDF, delivers “built-in” redaction capabilities.**

**<****SecureForm****>**
**<****EncryptedData****>**
**   ****<****CipherData****/> ****<!-- role A -->**** **
**   ****<****CipherData****/> ****<!-- role A -->**
**   ****<****CipherData****/> ****<!-- role B -->**
**   ****<****CipherData****/> ****<!-- role A -->**
**   ****<****CipherData****/> ****<!-- role B -->**
**</****EncryptedData****>**
**</****SecureForm**** >**

- “”
- “”
- Clear Text
- “”
- Clear Text

**Key Translation**
**for User **
**Role = B**

**Encrypted XML Content**

**XML or PDF Output for Role B**

**To generate a “redacted” document that exposes data as defined by the data privileges of Role B is simply a case of retrieving the document as Role B. The document can be saved (as XML or PDF as appropriate) for distribution. **
**A community of users with different data access privileges can exploit an XML document repository, each retrieving only those specific data elements from each XML document to which they are authorized.**

## Demo: Data Confidentiality

**Now we can review the demo again to see how data confidentiality is maintained.**

- Each user, depending on the location of their role in the role hierarchy has a different “view” of the XML data in the saved form,  consistent with their role privileges.
- Each will have access to data elements encrypted for their role or a subsidiary role. and will see the signatures on the data they have access to.
- The <Actions> in this form first sign and then encrypt the data, including the signature (the sequence is defined by the application in the <Actions/>.
- As the signature on encrypted data is also encrypted, signatures on data to which the user is not authorized will not be shown to that user.

**Retrieve XML document**
**Client side operations**
** ****Log as HR-A and issue payment**
**Log on as Clerk-A and review payment issuance**
**Log on as Manager B and review payment issuance**
**Log on as Treasury and review payment issuance**
**Server side views**
** ****Sequential records**
**Verify signature on payment issuance**

## Standards Based

**TrustLogic, and all the XML it creates and uses, conforms to the following:**
**XML**
**W3C Schema, W3C Digital Signature, W3C Encryption**
**The cryptography supports the following:**
**Algorithms**
**AES, 3DES, DES, RC2, RC4  /  RSA  / SHA-1, MD5**
**PKI**
**Tokens: PCKS#12, PKCS#11 (Smartcards & Biometrics), SC/PC (Smartcards), Entrust, MS Windows Registry**
**Certificate Processing: US DOD (Certificate processing is based on issuer and will conform to issuer’s certificate profile and policies)**

## Related Issues

**There are other issues that may have to be managed to achieve trustworthy digitally signed XML in a web application:**
**Cross-domain trust domain management (PKI)**
**Cross-domain identity and user key management (PKI)**
**Support of multiple client side Token interfaces (PKI)**
**Session security on XML transport between browser and server**
**XML <> browser interaction**
**XML <> application data interface**
**These have been addressed but are out of scope of today’s presentation.**

## Summary

**We demonstrated today a COTS product, using a COTS browser as the user interface, to interactively create, modify, store and retrieve XML documents that have been signed and encrypted.**
**The technology is: **
**Consistent with NARA guidelines for creating “trustworthy” digitally signed documents in XML**
**Consistent with NARA guidelines for the preservation and retrieval of such documents**
**Consistent with Federal requirements for privacy and confidentiality of records within workflow processes through role based XML encryption**
**Capable of inter-agency workflow through cross-domain authentication, identity management, and multiple token support**
**Capable of on-line and off-line XML document editing while preserving data security (signature and encryption) at all times.**
**Designed to allow multiple presentations of the same XML content according to the user interface (PC, Telephone, Print, Fax, etc.) while ensuring presentation integrity **
**Capable of attaching files of any type, to the XML document. Attachments are signed and encrypted as any XML element**

## Complementary Functionality - Authentication

**To support secure inter-agency workflow on XML documents TrustLogic provides comprehensive cross-domain authentication, authorization, and policy services.**
** **
**Authentication**
**Cross-domain identity management and credential validation**
**Key based, cross-domain identity management**
**Support for leading credential validation technologies**
**Application specific cross-domain trust management **
**Define which CA’s are recognized**
**Define what assurance level attached to each**
**Apply CA specific certificate policy and profile processing at run time**
**Support for multiple client side token technologies**
**Participants in different domains can use different tokens**
**Same participant can simultaneously use different tokens**

## Complementary Functionality - Authorization

**Authorization**
**Hierarchical role-based authorization, cryptographically enforced**
**All users given a role in the application when authenticated**
**Role has cryptographic profile (which algorithm, key length)**
**Access to data elements and application processes can be associated to possession of a specific role**
**Data elements will be encrypted under role keys at point of origin and while at rest**
**Application centric (not network centric)**
**Each application can have one or more role hierarchies**
**Users can have multiple roles in the same application and different roles in different applications**

## Complementary Functionality - Policy

**Policy**
**Hierarchical, role based rules **
**Rules associated to a role, applied to all subsidiary roles unless subsidiary role has its own rule**
**Multiple rule types **
**Boolean: to control execution of operations**
**String: for comparison type rules**
**Number: for comparison type rules**
**Java: to execute specific code, including integration with non-web based applications**
**GUI interface provides single point of control for managing rules across all applications **

## Thank you

**Thank you.**
**Matthew McKennirey**
_**[mmckennirey@conclusive.com](mailto:mmckennirey@conclusive.com)**_
**703 734 3000 ext 120**
**Appendix**
**Demo technical details**
**Current Activities : Encrypted XML database**
**Key Translation Detail**
**Run Time Data Request Flow of Events**
**Low Lifetime Cost**
**Trust Domain Policy**

## Demo Technical Details

**For the technologists, today’s demo used the following technologies:**
**Server side**
**TrustLogic Server 2.0 (J2EE application)**
**OS: Windows 2000 + ver. 1.3.1 Java Runtime Environment**
**TrustLogic can run on MS NT/W2000 / Solaris / Linux servers**
**Web Server: Tomcat 4.0.6 (open source - stand alone mode) running JSP**
**TrustLogic can support any web application language that provides for remote procedure calls**
**Database: MySQL ver. 4.0 (open source)**
**TrustLogic can run on any SQL database with JDBC driver**
**Directory: Sun iPlanet ver. 5.0 (not required by TrustLogic, used to store CRLs and some CA certs for demo)**
**TrustLogic can interact with any LDAP ver. 2.0 directory**
**User side**
**TrustLogic Agent 2.0 (Java app, includes open source XSLT , XFO)**
**OS: Windows 2000 + ver. 1.3.1 JRE (client & server on same machine today)**
**Browser: IE 6.0 (Agent requires ver. 5+ browser, or ver. 6+ for XSL support)**
**Tokens**
**User A: Entrust *.pdf  (Entrust CA)**
**User B: PKCS#12  (*.pfx)  (Sun iPlanet CA)**
**TrustLogic supports all leading software and hardware tokens**

## Current Activities

**The focus of our current activities, funded by NIST, is an encrypted XML database which supports searching encrypted XML.**
- [Yes, searching encrypted data appears to be an oxymoron. We specialize in “can’t be done”.]
**Activity 1: (NIST) Future Secure XML Database**
**Sensitive XML data is stored encrypted in the XML database under hierarchical role based crypto access**
**Encrypted XML can be searched, and matches returned encrypted specifically for the authorized user**
**Constraint: Supports complete value match only (no partial element search)**
**Activity 2: (DOD) Secure XML Across Domain Boundaries**
**Transfer Secure XML between physically distinct domains of different security levels through non-XML aware accredited guard devices**
**Constraint: Coherent  role structure and access to role keys in applications in physically distinct domains**

## Key Translation Detail

**The marriage of symmetric and asymmetric cryptography.**

- Generate a symmetric key

- Encrypt Data under symmetric key

- Encrypt symmetric key under asymmetric key

**1**

- Assign role to user at logon

- Compare user’s role name to encrypted data role key name

- If match decrypt symmetric key and re-encrypt under user’s key for data transmitted to user

**2**

**3**

**4**

**5**

**6**

## Run Time Data Request

**TrustLogic manages all aspects of moving protected XML back and forth using  standard HTML as transport. **

**Internet**

**Notes:**
In a TrustLogic enabled web application, the web forms presented to the user are defined as XML and the appropriate encryption information stored with the XML file.  When a process calls for a form to be sent, the XML is retrieved from the LDAP and passed to the web server where XSL renders it into HTML for the browser.  Any XML is encrypted.

At the browser end the TrustLogic client software decrypts the XML, making it available for the browser to display.  Only a user that can access the private key that will decrypt the XML will be able to see the data in clear.  The HTML is encrypted and if saved to the browser machine will remain encrypted.

On the server side the web server processes the encrypted data (to render it in HTML and on receipt) but cannot decrypt the data.  Data is decrypted at the TrustLogic server which is not exposed to the Internet.

## Low Lifetime Cost

**TrustLogic’s architecture is designed to minimize deployment cost and for a low lifetime cost.**
**Highly modular, high degree of reusable modules with extensive templates for rapid integration; each successive application builds on previous applications and is less expensive to deploy**
**Application is separated from PKI technologies and policy such that these can change / updated without touching the application**
**Uses standard Java to define security tasks (“processes”) that define behavior (no proprietary scripting languages to master)**
**Tools generate secure XML forms from existing HTML / JSP pages**

## Trust Domain Policy: No CA Required

**TrustLogic’s ability to define a trust domain in 2 dimensions; “horizontally” in terms of which CAs are recognized, and “vertically” in terms of the assurance level associated to each CA and its support for leading tokens means organizations do not need to operate their own CA and can accept certificates from any CA it decides to “recognize”. **
**Organization does not have to operate its own CA and issue certificates.**
**Organizations can extend “trust” to any CA it wishes to recognize**
**Applications create their own sub-set of recognized CAs from those recognized at organization level**
**Applications apply their own assurance levels to each CA which can be used within rules to determine privileges of users from each CA **
**Can use token type as additional criteria for establishing privileges**