RE: How secure is Infopath? Was RE: How secure is XForms?

Hi John,

See inline comments below...

-----Original Message-----
From: jmessing [mailto:jmessing@law-on-line.com]
Sent: Friday, October 10, 2003 5:51 PM
To: AndrewWatt2001@aol.com; John Boyer
Cc: jmessing@law-on-line.com; www-forms@w3.org; XForms@yahoogroups.com;
w3c-ietf-xmldsig@w3.org
Subject: Re: How secure is Infopath? Was RE: How secure is XForms?

John:

Thank you for your confirmation of my tentative suggestions. I greatly respect your opinions and work.

<johnboyer>Thanks!</johnboyer>

Were the tests with InfoPath conducted solely with client side PKI signatures?

<johnboyer>Yes.</johnboyer>

To the extent that servers can sign data on behalf of signers either via an XKMS type of architecture, or a single key for a group of users, could either InfoPath or Xforms use of security for XML forms be facilitated by such an architecture? Are they compatible with such an architecture?

Are such server based signatures compatible with PureEdge's proprietary solution? (Cf the DSS TC of OASIS).

<johnboyer>
Well, the InfoPath solution only seemed to allow you to set up 
data-only client-side PKI signatures, and XForms 1.0 has not yet 
addressed integration with digital signatures.

As for server-side generation of signatures, let me begin by
saying that signatures really tend to be more valuable to the
verifier than the signer. This is because most systems are set
up to be point of contact with individuals as signers and a company
as the verifier.  Since the company/verifier is the one running the 
server, it is too self-serving if the verifier has significant
control over the signature generation process.  This is why 
companies tend to use a 3rd party as a certificate authority,
for example.  The problem we are talking about now is another
manifestation of this issue.  If a signature only signs data,
then the verifier's hands are not clean, so to speak, because it 
is possible to change what the user saw after the signature is
generated.

Regarding server-side signature generation, the verifier may use 
3rd party software to create the server-side signature systems, but 
if that software is doing the actual cryptographic calculations
on the verifier's server, then the signer's private key will appear 
in the clear in server memory at some point.  Unless special hardware 
is installed to prevent this or unless the system calls out to a 3rd 
party web service for signature generation, the verifier can still get 
their hands on a signer's private key material. It is true that the 
3rd party software tends to make it harder to do so because the signers' 
private keys are not in the clear in the permanent storage, but it is 
still easier to get the key material than it would be by integer 
factorization.  As the value of the protected transactions increases, 
the volume of such transactions decreases, which seems to make reliance 
on laws pertaining to common practices of a business less tenable.

I've said all of this mainly as a qualifying context for answering
your final question.  Suppose you do have a 'good' system of 
server-side signatures that somehow provides the verifier a level
of plausible deniability regarding tampering (such a system is 
feasible, so the supposition is not degenerate). Then, I see nothing
to prevent that system from using the additional PureEdge
methodologies to secure portions of a form and to prevent partial
form signing from creating additional security risks. 

The main issue is that InfoPath is not architected to be extensible
in this way.  Although the XForms working group has yet to formally
consider signature integration, I believe XForms is more likely to be
easily extended to allow a host language to apply the PureEdge
methods.  Whether the methods are applied by server-side code or
client-side code will likely be up to the implementation.  XForms
typically does not distinguish where certain functionality gets
implemented, so long as it has the specified behaviors (i.e. meets
the defined requirements).

The big problem for XForms is that it is designed to be hosted by
another language, so if the host language has difficulty locking 
down the attributes we want to secure with the PureEdge methods,
then an XForm will be out of luck simply because of the language
used in the host envelope.  We want to position XFDL as a secure
host language for XForms because we think it will be much harder to 
write securable XHTML, in part because of properties of the language 
itself and in part because of expected flexibilities in the 
rendering environment itself (a web browser).

Best regards,
John Boyer, Ph.D.
Senior Product Architect and Research Scientist
PureEdge Solutions Inc.
</johnboyer>

Best regards.

---------- Original Message ----------------------------------
From: "John Boyer" <JBoyer@PureEdge.com>
Date:  Fri, 10 Oct 2003 17:45:41 -0700

>Hi Andrew,
> 
>Yes, I would be happy to follow up on my points.
> 
>It is accurate to conclude XForms implementations do not support any of the 
>'what you see is what you sign' conceptualization presented in my paper because
>XForms has not yet taken on interoperation with XML DSig.  Moreover, some
>implementations have added XML DSig as custom extensions, but they are
>uniformly signing data only because it is difficult or impossible to get access
>to the presentation layer.
> 
>It is not accurate to conclude that InfoPath supports a 'what you see is what you sign'
>conceptualization, such as is described in my 1999 paper.  My prior comments left 
>open a small door in case someone figures out an extremely bizarre way of doing this, 
>but I can find no reasonable way to sign anything but the data.  My conclusion is that 
>in the current release, InfoPath digital signatures have no value in and of themselves.
> 
>To put a fine point on this claim, we used the 'Applicant Rating' demo form and 
>enabled signatures.  We then filled out the form, signed it, and saved
>the data (which included the new signature).  Then, we went into the form template
>and changed the user interface to say ridiculous things like 'prisoner number' instead of 
>'applicant number'.  Finally, we double-clicked our signed data file.  Up came the 
>InfoPath filler.  The processing instruction in the data file caused InfoPath to retrieve our 
>bogus UI, but the signature in the data file does not cover the UI, so it validated.  InfoPath 
>claimed that we signed our own prisoner registration form when this is not at all what we 
>signed.  It is a very compelling demo!
> 
>In the InfoPath design experience, there is very little to be done to add signature, 
>but this also means that there is very little power to set up good signatures.  One 
>simply clicks a checkbox to enable signing in the form.  Then, in fill-out mode, anyone 
>who gets access to the form can add their signature. Here are the problems:
> 
>1) The form author has no control over whether particular individuals (or individuals with
>certain roles) should be allowed to sign, which violates ABA guidelines for what a signature 
>means (message authentication, signer authentication, **and signer authorization**).
>At a minimum, having the ability to restrict the form to only taking one signature would be 
>a nice option for the form author.
> 
>2) The InfoPath filler has hard coded the particular transformations that sign the entire 
>data (less the signatures block).  So, two signers can sign the entire form, but two signers 
>cannot sign different parts of the same form.  It also does not appear possible to allow an 
>'office use only' section of a form to be filled out after the form has been signed.
> 
>3) Since InfoPath signs the data only, it is extremely easy to add things to the user
>interface after the user has signed, like fine print obligating the user to terms and 
>conditions to which the signer did not originally agree.  Indeed, as we showed in the
>demo I described above, it was easy to change the entire context of what was signed.
> 
>This last point means that InfoPath signatures are a significant disservice to any 
>enterprise hoping to secure their transactions with InfoPath because it is so easy for the 
>malicious signer to repudiate a transaction by simply showing that it is hard to conclusively 
>prove what the signer really agreed to.  After all, what you see is what you sign!
> 
>Because this is such a problem, I should note that we tried things that were outside of the
>normal InfoPath design experience to see if we could 'jury-rig' a good signature (I never 
>thought I would see myself use such a turn of phrase).  We added a DSig signature 
>element that had our own <reference> elements in it so that both the data and presentation
>could be signed.  When we did this, the InfoPath filler promptly informed us that there
>was an invalid digital signature in the form.  We tried to add a signature anyway, but
>InfoPath forced us to remove the invalid signature before allowing us to add a
>new signature, which it dutifully hard-coded to sign only the data.
> 
>A secondary problem is that the InfoPath signatures are created with XSLT transforms,
>which are 'optional' according to the XML signature recommendation.  This means that
>not all XML DSig engines will validate the signatures.  Moreover, the particular task they
>are trying to perform is easily accomplished with an XPath filter, which is a 
>'recommended' to implement feature of DSig (recommended means that it is virtually
>ubiquitous since an implementer cannot claim to be spec compliant unless they 
>provide the feature or provide a compelling reason why it isn't there).  I wanted to test 
>whether the Microsoft code even supported XPath filtering, but the system does not
>seem to allow me to set up my own signature references.
> 
>If I were designing the InfoPath signature solution, I would first change the data
>filter to be based on XPath filtering, not XSLT.  I would also get rid of the enveloped
>transform as it seems to be redundant with what the XSLT (and hence the XPath)
>is already trying to do. Then I would add a second reference to the .XSN file (the form 
>template containing, among other things, the .xsl that generates the user interface).  
>Then, I would add a third reference that contained a transform to bind the URI in the 
>second reference above to the value of the href in the mso-infoPathSolution processing 
>instruction.  This is necessary to help ensure that the user interface being secured by 
>the signature is equal to the URI that is actually used to obtain the form template.  
>Maybe this is a hard transform to write, but if the design environment is writing it, then it 
>is not so hard on the form author.
> 
>Of course, we cannot do these things with InfoPath, but if we could, then the system 
>design still seems completely incapable of being extended to partial document signing
>scenarios.  The main problem is that the .XSN file containing the form template is a 
>*compressed* file, so it is opaque to DSig transforms.
> 
>Hopefully, this is enough information to start with.  It does not even begin to touch on
>the issues in PureEdge's more current research because InfoPath does not seem to let 
>the form author set up signature filters.  I would be relieved and pleased to see a post that 
>shows how I can get InfoPath to let me set my own signature filters.  Otherwise, I will be 
>disappointed in InfoPath given the strong presence that Microsoft had on the XML DSig 
>working group.
> 
>Best regards,
>John Boyer, Ph.D.
>Senior Product Architect and Research Scientist
>PureEdge Solutions Inc.
> 
> 
> 
>
>-----Original Message-----
>From: AndrewWatt2001@aol.com [mailto:AndrewWatt2001@aol.com]
>Sent: Friday, October 10, 2003 11:00 AM
>To: John Boyer
>Cc: jmessing@law-on-line.com; www-forms@w3.org; XForms@yahoogroups.com
>Subject: Re: How secure is XForms?
>
>
>In a message dated 10/10/2003 17:59:48 GMT Daylight Time, JBoyer@PureEdge.com writes:
>
>
>
>Hi John and Andrew,
>
><snip/>
>
>As to Andrew's point about Microsoft InfoPath, you may with 
>significant effort be able to create a basic signature for a 
>form that meets the requirements described in our WWW8 paper
>from 1999, but this is 2003 and you will need XFDL to handle 
>many of signing scenarios that arise in practice and that are 
>of greater interest to the security communities at RSA and the ACM.
>
>
>
>John,
>
>I would like to follow up on some other points you made but don't have time to do that at the moment. Hopefully I will over the weekend.
>
>Can I attempt to distill your final paragraph into a take home message?
>
>Is it accurate to conclude that InfoPath currently implements some of your 1999 suggestions and that XForms implements none of them? 
>
>Is that an accurate statement of the position today?
>
>I appreciate that you have hopes of better things for the future but that is one of the issues I would like to explore further later.
>
>Secondly, can you state which non-basic signing scenarios you have tested in InfoPath 2003 which work and which signing scenarios you have tested in InfoPath 2003 which don't work? Alternatively, were your comments about creating a "basic signature" in InfoPath ... and the hints of difficulty and/or inadequacy ... more by way of a general comment than specific testing? Can you clarify what you mean in that context by a "basic signature"?
>
>I am trying to lead you to firm up comments which are capable of more than one interpretation.
>
>Thanks
>
>Andrew Watt
>
>
>
>
>
>

Received on Tuesday, 14 October 2003 19:38:11 UTC