EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Two namespaces appear on Signature line

Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.
#15857
Posted: 02/22/2011 09:31:47
by San P (Standard support level)
Joined: 11/07/2009
Posts: 37

With XmlBlackbox VCL version 8.1.191, I wonder why I always get Signature Element with two namespaces, like this:
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
The green part is OK, but blue part is needless, and I should get rid of it.

My code looks like this:
Code
procedure TForm1.btn1Click(Sender: TObject);
var
  NewDocument: TElXMLDOMDocument;
  TmpElement, AppReqElement: ElXMLDOMElement;
  Refs: TElXMLReferenceList;
  Ref: TElXMLReference;
  X509KeyData: TElXMLKeyInfoX509Data;
  SigNode: TElXMLDOMNode;
  Signer : TElXMLSigner;
  F : TFileStream;
begin
  X509KeyData := nil;
  Ref := nil;
  Refs := TElXMLReferenceList.Create;
  Signer := TElXMLSigner.Create(Self);
  Signer.OnFormatElement := SignerFormatElement;
  Signer.OnFormatText := SignerFormatText;
  NewDocument := TElXMLDOMDocument.Create;
  try
    AppReqElement := NewDocument.CreateElementNS('http://bxd.uk/xmldata/','ApplicationRequest');
    NewDocument.AppendChild(AppReqElement);
    TmpElement := AppReqElement.OwnerDocument.CreateElementNS('', 'CustomerId');
    TmpElement.InnerXML := '123456';
    AppReqElement.AppendChild(TmpElement);
    TmpElement := AppReqElement.OwnerDocument.CreateElementNS('', 'Command');
    TmpElement.InnerXML := 'GetUserInfo';
    AppReqElement.AppendChild(TmpElement);
    Ref := TElXMLReference.Create;
    Ref.URINode := AppReqElement;
    Ref.URI := '';
    Ref.TransformChain.Add(TElXMLEnvelopedSignatureTransform.Create);
    Refs.Add(Ref);
    try
      with Signer do
      begin
        SignatureType := xstEnveloped;
        SignatureMethodType := xmtSig;
        SignatureMethod := xsmRSA_SHA1;
        MACMethod := xmmHMAC_SHA1;
        References := Refs;
        KeyName := '';
        IncludeKey := True;
      end;
      X509KeyData := TElXMLKeyInfoX509Data.Create(True);
      DoLoadCertificate(KeyFNXml, KeyPassword, X509KeyData);
      Signer.KeyData := X509KeyData; // Get X509 key
      Signer.UpdateReferencesDigest;
      Signer.Sign;
      SigNode := AppReqElement;
      Signer.Save(SigNode);

      F := TFileStream.Create('Out.xml', fmCreate or fmOpenWrite);
      NewDocument.SaveToStream(F, xcmNone, 'utf-8');
    finally
      FreeAndNil(X509KeyData);
      F.Free;
     end;
  finally
    FreeAndNil(Refs);
    FreeAndNil(Signer);
    FreeAndNil(NewDocument);
  end;
end;

A larger chunk of the output looks like this:
Code
<ApplicationRequest>
<CustomerId>123456</CustomerId>
<Command>GetUserInfo</Command>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>FvnKSHL6CktxpGikUyeMVX2SqCg=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
...


Also SimpleSigner demo does exactly the same, if I try to sign this kind of document:
Code
<ApplicationRequest>
<CustomerId>123456</CustomerId>
<Command>GetUserInfo</Command>
</ApplicationRequest>

I again get the Signature line having those double Namespaces.

I tried to twiddle SignaturePrefix:
Code
Signer.Signature.SignaturePrefix := '';
Signer.Signature.SignaturePrefix := 'ds';
but the double namespace problem does not go away:

It looks like XMLBlackbox always creates those double namespaces on Signature element. Maybe this conforms to some XML standard or something? Yet my XML server really requires me to send the Signature with only one Namespace like:

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

Any suggestions, or workarounds?

Thanks
SP
#15859
Posted: 02/22/2011 11:57:24
by Dmytro Bogatskyy (EldoS Corp.)

Quote
I tried to twiddle SignaturePrefix:Code
Signer.Signature.SignaturePrefix := '';
Signer.Signature.SignaturePrefix := 'ds';

but the double namespace problem does not go away:

Where did you place this code?
Assigning of the SignaturePrefix property should be placed after a Sign method call. In fact all modification of Signer.Signature object should be done after a Sign method call where it created and filled.
In your case, use:
Code
Signer.Sign();
...
Signer.Signature.SignaturePrefix := '#default';


P.S. Article: https://www.eldos.com/security/articles/6092.php
#15869
Posted: 02/23/2011 12:37:34
by San P (Standard support level)
Joined: 11/07/2009
Posts: 37

Quote
Dmytro Bogatskyy wrote:
P.S. Article: https://www.eldos.com/security/articles/6092.php
That article suggests exactly to use SignaturePrefix := 'ds', and that's just what I had tried with no luck.

Quote
Signer.Signature.SignaturePrefix := '#default';
Thanks a lot! This finally works and this does it.

After getting that fixed I still could not make XmlBlackbox to create identical Signatures with my signed reference material. The DigestValues were identical, but no matter what settings I tried to change, the signature was always different. Also the Bank server rejected these with "Digital signature not valid" message.

In these tests I have routinely used the OnFormatElement and OnFormatText procedures that were introduced in SimpleSigner demo. I finally found that it is the OnFormatElement that alters the Signature value.

I was in impression that these formatting routines should not affect to the XML contents in that way that it also changes the Signature value. Yet if this is some well known behavior and side effect with XML signing, then all right. It just got me confused. For a long, long period.

I noticed that using of OnFormatText routine does not affect to Signature value. But using either of those two routines will create a XML file that will be rejected by my Bank server. When I comment those lines out, then Bank will accept my XML file.

Of course other XML/SOAP servers may behave differently, and may quite well also accept XML that has gone through those two routines. Maybe some warning not to use those formatting routines in the final Production app would be good.

I'll include a simple Test app if anyone wants to check if my findings concerning the Signature behavior are proof or not.

Thanks for the answer.
SP


[ Download ]
#15874
Posted: 02/23/2011 15:22:19
by Dmytro Bogatskyy (EldoS Corp.)

Quote
In these tests I have routinely used the OnFormatElement and OnFormatText procedures that were introduced in SimpleSigner demo. I finally found that it is the OnFormatElement that alters the Signature value.

I was in impression that these formatting routines should not affect to the XML contents in that way that it also changes the Signature value. Yet if this is some well known behavior and side effect with XML signing, then all right. It just got me confused. For a long, long period.

OnFormatElement and OnFormatText events changes a generated Signature elements prior signing, because you can't change whitespace formatting of tags in a Signature after signing, as changing them will invalidate it.
Canonicalization algorithm only defines how attributes sorted in element, how empty tags and special characters are rendered, but it doesn't remove trailing whitespace characters between tags.
Quote
The DigestValues were identical, but no matter what settings I tried to change, the signature was always different.

Signature value depends on content of generated SignedInfo element and certificate/key used.

Quote
But using either of those two routines will create a XML file that will be rejected by my Bank server. When I comment those lines out, then Bank will accept my XML file.

It looks like your bank server application removes trailing whitespace characters between tags on loading prior to verifying a signature.
It could be due to some internal standard or badly written code (for example, if they use System.Xml from .Net, they could forget to set XmlDocument.PreserveWhitespace property that is false by default and will lead to the same results).

Just in case, could you please PM or E-mail your Bank name.
#15890
Posted: 02/24/2011 03:15:38
by San P (Standard support level)
Joined: 11/07/2009
Posts: 37

Quote
OnFormatElement and OnFormatText events changes a generated Signature elements prior signing, because you can't change whitespace formatting of tags in a Signature after signing, as changing them will invalidate it.
My example did not contain any whitespacs. I think (at least my earlier thought was..) that it should have created identical signings in both cases.

And finally, it only matters how the receiving party is able to read and interpret the signed XML and check if the signing was right or not. I got rejected by my bank. That's why at least some warning for XML BlackBox developers about FormatElement usage side effects for that sender/receiver succesful interpretation, that would have been entitled.
Quote
Signature value depends on content of generated SignedInfo element and certificate/key used.
Of course it depends about the used key. That's why I included simple working demo with working key to be sure we are talking about the same thing here.
I have been in belief that while the calculated DigestValues for the <SignedInfo> element are identical, then succesful Signing, done with the same key, would also always lead to identical Signatures.

Quote
It could be due to some internal standard or badly written code (for example, if they use System.Xml from .Net,
I am positive that they only use techniques like Java and Net with all these Web Service and SOAP things on the banking side.

I feel I am probably one of the last remaining lonely wolves who is trying to do Soaping communication with these ancient native methods like Pascal or C :)
Technical support at banking side do not even understand any of my questions. They only know about some Java Libraries they use (they don't want to tell the library names though) etc.

Quote
Just in case, could you please PM or E-mail your Bank name.
It is the same European bank and also the same testing site I reported in my earlier Helpdesk request 1833x in January.

Just at this moment I have no open questions, everything works. And I am not writing these just to complain. If these suggestions are in any way useful in getting the coming Secure XMLBlackbox versions better, then that's just fine with me.

Thanks
SP
Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.

Reply

Statistics

Topic viewed 1888 times

Number of guests: 2, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!