ICWE 2005 Secure Web Forms with Client-Side Signatures Mikko Honkala and Petri Vuorimaa, Finland Mikko.Honkala -at- hut.fi
Outline of the talk Introduction to Secure Web Forms Research Problem and Use Cases Requirements for the Signature Scheme Design and Implementation Use Case Implementation Discussion and Related Work Conclusions
Introduction Commerce and communication tasks are becoming popular in the World Wide Web (WWW) Web is transforming from a platform for information access into a platform for interactive services Secure transactions with client-side authentication and signature are needed in many cases Banking, e-commerce, secure e-mail, contracts Securely tracking workflows
What You See Is What You Sign Capability to express the signature over everything that was represented to the user Important, but often overlooked property of digital signing applications Some schemes go as far as including screen captures with the signature However, this may be impossible to process with subsequent software Better solution is to include everything that affected, what the user saw: Content, Images, stylesheets, etc.
Research Problem How to create legally binding secure services in the WWW? Secure transmission already working (SSL), but does not support the notion of client-side signatures Main problem is to enable WWW services to allow digital signatures over the the user s input Ensure that the user has a clear understanding what she is signing Ensure full reconstruction of the signed form, when validating the signature
Use Cases 1. Single form. The user downloads a form (e.g. an email to be written), interacts with it and then selects a signing key, signs the form and then sends it to the server for processing. 2. Form approving. A signed form is sent to a supervisor, who adds some data, and then signs it. 3. Multiparty form. Multiple parties are filing a single insurance claim. It should be possible to add new parties and attachments, but each of the parties signature must not allow changes in the core information of the claim form.
Use Case 3: Multiparty form
Requirements for Signature Security Client-side: The signature must be generated client-side so that the user can check the signature validity before submitting. Also, support for signing with secure smart card must be supported. Common algorithms: The signature must be generated using common, trusted, algorithms for maximum security. Signed form reconstruction: It must be possible to reconstruct the signed form in case of dispute.
Requirements for Signature Coverage In order to fullfill the WYSIWYS principle, these parts must be signed User input: The data user inputted through the form. UI: The UI document, which describes the layout of the form. All referenced data: Stylesheets, images, objects, applets, scripts, schemas, external instances, etc. The user agent info: Information about the user agent.
Additional Requirements Complex signature support: Support for complex signing scenarios. Partial signature: Support signing only part of the form. Multiple signatures: Support multiple signatures within one form. Form language integration Ease of authoring: Provide as easy syntax as possible for authors. Ease of implementation: Use of off-the-shelf libraries should be possible. Modality and host language independence: The design should beindependent of modality and host language.
Design Decisions XHTML+CSS+XForms was chosen as the form language Good support for the XHTML+CSS layout in browsers XForms is device-independent XForms does not require scripting state of the form is encoded in an XML instance XML Signature was chosen as the signature description, transmission, and processing language Ability to add XML objects inside the signature Ability to sign external URL references (using hash value of the referenced content) Supports different kinds of signatures, hash and signature algorithms
XForms W3C s next-generation Web forms language Based on existing powerful XML technologies Separates model/view The state of the form is preserved in the model Uses a declarative programming approach No scripting needed
XML Signature XML Signature is a W3C specified XML format for describing digital signatures The specification also defines normative processing rules for signature creation and validation
Design Integration of XForms and XML Signatures standards Main design goal was to keep it simple to both authors and implementers Two extensions to XForms language <sign> action element, which is an XML Events handler signature-ready DOM event Procedures for signature creation and validation defined
Process Description
Signature Creation User stylesheets are disabled Only top-level windows can be signed An enveloped signature (with Signature element as root) is created The instance data of XForms is copied and embedded inside Object elements All references to URLs are included in the signature as detached references The host document All referenced URLs separately: images, objects, applets, stylesheets, scripts, XForms external instances, xinclude, xlink, XSLT A valid signature is created over all references
Document With External References
Created Signature Structure
Signature Validation 1. Find the Signature element from the submitted instance data. 2. Check that public key corresponds to the users identity. 3. Validate the Signature element according to the XML Signatures' core validation rules. 4. Do application-specific validation of all resources. For detached references, check that the URL is correct. For enveloped resources, application-specific logic must be included in the validation. 5. The Signature is accepted if none of the checks fails.
XML Example Extremely simple to add a signing action to a form: <trigger> <label>sign message</label> <sign:sign to="instance( signature )/.." ev:event="domactivate"/> </trigger>
Implementation A new signature component was created for the browser That component accesses other components that handle the document to access: The XForms instance data All resources referenced via an URL The XML Signature is created using the Open Source Apache XML Security 1.1 for java library, which was stripped down to 331 KB Other classes size is 25 KB Total storage size 356 KB
Use Case Implementation Use Case 3: Multiparty Form (Insurance claim) was implemented as a proof of concept Consists of Single form Server-side servlet, which filters the current view with simple XPath statements From the client s point of view, the view is signed completely
Use Case 3: Adding a Signer
Use Case 3: Viewing the Claim
Use Case 3: Sign Debug View
Use Case 3: Verify Debug View
Discussion: Security Issues In the Web any user agent can be used to interact with the services Since the user agent creates the signature, the user must trust the user agent fully That is the only software component, that the user must trust The service does not install extra software into the client For maximum security the signature should be created in a smart card Private key cannot be tampered with PKI should be used to authenticate the signer
Discussion: Related work Some commercial form systems support signatures Adobe, PureEdge XFDL, InfoPath Research papers published about XFDL XFDL differs from CSS-based languages Single XML definition, that includes everything: the form description, layout, fonts, colors, form data, and even binary signatures In the Web resources are distributed over multiple resources and fetched from an URL using HTTP The browser puts together the pieces and creates the final presentation Different requirements for the signature scheme
Conclusion The research problem was: How to create legally binding secure services in the WWW 3 representative use cases were described Requirements for secure client-side signatures were derived from the use cases A design, which integrates XForms with XML Signature was created The proposed design was implemented in a open-source user agent, One of the use cases was implemented using the extended user agent
Future Work Propose to adopt the scheme in the W3C XForms Working Group Adding user agent info (CC/PP or a simpler scheme) into the signature Supporting forms, which use HTML+Scripting Already analyzed in the paper XHTML+Scripting is possible by adding the current DOM as an embedded reference HTML+Scripting is more difficult, since browsers fix non-wellformed HTML differently, so serialization would differ between implementations
Thank you!