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

RE: How secure is Infopath? Was RE: How secure is XForms?Hi John, Brian et al!

This was interesting to read.  Particularly in relation to the request I recently
sent to this list regarding Web(browser)-based standards.  The interesting
part is that many existing on-line (web) systems (proprietary but working)
seem to do things quite differently to InfoPath and IMHO, they do so for a
reason.  Or rather for several reasons.

The following approximately describes how the default "Identrus" web-signing
profile works.

1. The user creates a set of data in an arbitrary interactive process.
Typical processes include filling in a purchase order.
2. The last part of that process ends with the provider (signee) sends
a "frozen" (a.k.a "dry") version of the data to the user to take action on.
3.  The users signs this data which is MIME-tagged and supposed to be
viewable.
4.  By default only the (detached) signature is sent back to the provider
(to send back an HTML doc with embedded images does not seem to
be too practical, while hashing such a document is a piece of cake)

That is, there is no distinction between data or UI.

The provider usually checks that the hash in the signature matches its own
calculation of what the "cononicalized" TXT, HTML, DOC or PDF should be,
in order to immediately verify that the user really got the proper data (UI) before
accepting the signature.  As this is a part of an interactive web-session.

How trustworthy is such a scheme?

This scheme is built on the idea that the "provider" is to be trusted
for keeping not only the original data, but also the code used for
transforming the data into a viewable format as well as the user signature.
The provider can then at any time:
- verify the signature by running the process internally
- show the user what he/she got on the screen (which does not
have to be 100% equivalent to the original data, it typically only shows
what the provider believes the user needs to carry out his/her task)
That is, this scheme is neither useful nor intended to be used where
the provider is unknown or maybe even untrusted by the user.


What does this have for consequences?

The most significant is that users' signatures are not mixed into the
transaction data and that the user never signs anything it cannot see.
The latter is important as the data may be EDI, an SQL expression,
an instantiated "business object" etc.  Also, few if any business
systems can handle signatures inside their existing messaging which
makes this scheme easier to introduce than schemes requiring total
rewrite.

To not mix users' signatures in a workflow application may be seen
as a big weakness.  I believe it is the contrary.  If the workflow
application is internal to the organization it should be a part of the
workflow system to keep track not only of the flow, but storing
and verifying individuals' signatures.  The data itself can by that
always be kept in a "clean" state (or secured by internal signatures).
For lawyers this is terrible news but really, the "e-world" <<>> "paper-world".

However, this get much more interesting if we talk about multi-organization
workflow.  I claim that "authorization" is mainly an internal business.
At least in the private sector this is valid.  And privacy issues in many
cases make the distribution of employee signatures a problem 
(remember, a paper signature is just an hardly readable mark of authenticy, 
while an e-signature usually is an identity as well).   Even e-Governments
in some countries have taken a new approach to inter-authority
messaging that I believe is more scalable than the "classical" approach. 

The core of these schemes is that transaction data when leaving the
organization is "stamped" with organization's signature, while possible
references to individuals is a part of the message payload rather than
(often redundantly) being supplied in signatures.  A purchase order is typical:
It identifies a buying party, the individual is secondary if
required at all.  Assuming providers keep their records straight (i.e.
maintaining their IS-systems which you must do anyway...), any error,
authorization question etc. can be answered at anytime and with the
same security as the original PKI/signature approach as the latter is
de-facto equally dependent on the safe storage of data.  I.e. what good
are digital signatures if your data center is dead?

An almost production-level example of this multi-organization workflow
architecture is VISA's 3D secure.  First the consumer creates a
payment request at the merchant's site.  This is routed back to
the consumer's issuer (trusted provider) which after the user have been
authenticated and accepted the request (maybe even using digital signatures),
sends an issuer-signed card-holder assertion to the merchant containing no
user-information (except for the credit-card number which is only needed for
"historical" reasons).  The merchant (or rather the merchant's acquirer) trusts
the issuer but not necessary the customer which it may not know at all.

[much] More information on this last subject is available in case you are
interested.

Regards
Anders Rundgren
Independent Consultant, PKI and e-business
  ----- Original Message ----- 
  From: John Boyer 
  To: Brian LaMacchia ; AndrewWatt2001@aol.com ; jmessing@law-on-line.com 
  Cc: www-forms@w3.org ; XForms@yahoogroups.com ; w3c-ietf-xmldsig@w3.org 
  Sent: Sunday, November 02, 2003 20:34
  Subject: RE: How secure is Infopath? Was RE: How secure is XForms?


  Hi Brian,

  I appreciate the time you have taken to post this clarification, but as 
  one XML DSig co-author to another, I am wondering if you spent 
  any time considering the technical merits of the clarification originally 
  posted by Infopath program manager Alessandro Catorcini to the 
  microsoft.public.infopath newsgroup?

  Your well-respected work on XML DSig pertained mostly to the 
  development of an XML Signature implementation.  However, 
  Mr. Catorcini seems not to have appreciated that InfoPath is a consumer 
  of XML Signature technology, not an implementer of said technology.
  This is a crucial distinction that he seems not to have made when he cites
  from the spec as follows: "XMLDSIG is a method of associating a key with 
  referenced data; it does not normatively specify...the meaning of the data being 
  referenced and signed."  

  Of course XML DSig cannot be responsible for semantics of the 
  consuming application. This is precisely why the consuming application must 
  therefore be responsible or else XML DSig is being misused.  Indeed, the 
  principal reason we allowed multiple references in a single signature was 
  to permit separated data and UI to be brought together in a single signature.  
  In fact, in Section 8.1.2 we directly codified the obligation of consuming 
  applications to include in a signature enough references and transforms to 
  preserve not just the data but also the presentation layer information.  

  Thus, the posted clarification seems to do little but solidify the reality
  of the security problem we have identified with InfoPath signatures, 
  especially when it states that "XMLDSIG digital signatures are most commonly 
  used to ascertain that the XML data underlying the InfoPath form has not been 
  altered since the form was originally signed".  We see clearly that InfoPath 
  provides data-only signatures, and we have not been able to circumvent 
  the design environment to force InfoPath to create secure signatures. It 
  may be that server-to-server communications must secure only data, but 
  InfoPath is a client-to-server application.   

  Unfortunately, an end-user signature over only the data has little or no 
  security value because the end-user does not see the data, but rather
  the end-user sees a presentation layer view of the data, which can be 
  substantially modified by the relying party (the government organizations, 
  insurance companies, financial institutions, etc. that are the usual validators 
  of signature) ** without breaking the InfoPath signature **.

  I would recommend, and I encourage you to recommend to Mr. Catorcini, 
  that InfoPath be patched immediately to remove support for the current 
  insecure signatures so that Microsoft does not have to provide backwards 
  compatibility support for them. Consuming applications of XML DSig
  (such as InfoPath) should neither encourage nor even support the current 
  insecure variety of digital signatures.

  Thanks for your further attention to this important security concern.

  Sincerely,
  John M. Boyer, Ph.D.
  Senior Product Architect and Research Scientist
  PureEdge Solutions Inc.
    -----Original Message----- 
    From: Brian LaMacchia [mailto:bal@exchange.microsoft.com] 
    Sent: Fri 10/31/2003 2:49 PM 
    To: John Boyer; AndrewWatt2001@aol.com; jmessing@law-on-line.com 
    Cc: www-forms@w3.org; XForms@yahoogroups.com; w3c-ietf-xmldsig@w3.org 
    Subject: RE: How secure is Infopath? Was RE: How secure is XForms?


    Hi John, John and Andrew, 

    I just wanted to take a moment to clarify how InfoPath supports the W3C 
    XML Signature standard (XMLDSIG). InfoPath uses XMLDSIG to secure the 
    XML data created by a user via an InfoPath form. Any change to the XML 
    data occurring after the InfoPath form has been digitally signed will 
    invalidate the digital signature, which will be detected by InfoPath 
    when InfoPath attempts to load or otherwise consume the data.  XMLDSIG 
    digital signatures are most commonly used to ascertain that the XML data 
    underlying the InfoPath form has not been altered since the form was 
    originally signed. 

    Applications that attach semantic meanings to digital signatures, which 
    InfoPath does not currently support, relate to making a signed statement 
    about the data that was presented to the user, how it was presented, 
    and/or whether there were any semantic implications to the user making 
    the signature.  In these cases, the presentation of the form itself to 
    the signer needs to be secured along with the data supplied by the 
    signer to the form.  As the XMLDSIG specification states in its 
    introduction: "XMLDSIG is a method of associating a key with referenced 
    data; it does not normatively specify...the meaning of the data being 
    referenced and signed."  Such semantics may be built on top of XMLDSIG 
    but that requires that additional semantic elements be defined on top of 
    the core XMLDSIG syntax.  Based on customer feedback, InfoPath will 
    enable this additional digital signature functionality as a part of a 
    web download expected to be made available in the first half of 2004. 

                                    --Brian LaMacchia 
                                      Microsoft