Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 067A7200AE1 for ; Mon, 6 Jun 2016 09:02:40 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 05294160A24; Mon, 6 Jun 2016 07:02:40 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id CDC9E160A0E for ; Mon, 6 Jun 2016 09:02:38 +0200 (CEST) Received: (qmail 88911 invoked by uid 500); 6 Jun 2016 07:02:38 -0000 Mailing-List: contact dev-help@santuario.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@santuario.apache.org Delivered-To: mailing list dev@santuario.apache.org Received: (qmail 88901 invoked by uid 99); 6 Jun 2016 07:02:37 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Jun 2016 07:02:37 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 53643C0E26 for ; Mon, 6 Jun 2016 07:02:37 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.999 X-Spam-Level: * X-Spam-Status: No, score=1.999 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id U-JBUdZmEK7l for ; Mon, 6 Jun 2016 07:02:34 +0000 (UTC) Received: from zimbra-mta.fenceit.ch (zimbra-mta.fenceit.ch [212.103.90.69]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 37C985F1E5 for ; Mon, 6 Jun 2016 07:02:34 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-mta.fenceit.ch (Postfix) with ESMTP id 2414AA017 for ; Mon, 6 Jun 2016 09:02:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra-mta.fenceit.ch Received: from zimbra-mta.fenceit.ch ([127.0.0.1]) by localhost (zimbra-mta.fenceit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2RnmJQ1KqoB for ; Mon, 6 Jun 2016 09:02:32 +0200 (CEST) Received: from [192.168.207.21] (unknown [95.143.56.212]) by zimbra-mta.fenceit.ch (Postfix) with ESMTPSA id 7D73EA016 for ; Mon, 6 Jun 2016 09:02:32 +0200 (CEST) Subject: Re: Signing of big XMLs fails on Windows 8/10 using smart cards To: dev@santuario.apache.org References: <57500AA0.70603@e-contract.be> From: Adrian Greiler Message-ID: Date: Mon, 6 Jun 2016 09:02:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <57500AA0.70603@e-contract.be> Content-Type: multipart/alternative; boundary="------------428CCECCEF96E1AE906C0F72" archived-at: Mon, 06 Jun 2016 07:02:40 -0000 This is a multi-part message in MIME format. --------------428CCECCEF96E1AE906C0F72 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I just tested with a way longer delay (more than 5 minutes) and it still worked. We have Siemens CardOS V4.3B (SuisseID) and there it fixes the problem. Thanks for the hint / test case and kind regards Adrian Am 02.06.2016 um 12:29 schrieb Frank Cornelis: > > Sure that this fixes the issue? What happens when the user takes more > than 5 seconds to enter the smart card PIN code? > > > Kind Regards, > Frank. > > Op 02-06-16 om 10:54 schreef Colm O hEigeartaigh: >> Could you create a JIRA here and submit a patch please? >> >> https://issues.apache.org/jira/browse/SANTUARIO >> >> Colm. >> >> On Thu, Jun 2, 2016 at 9:53 AM, Adrian Greiler > > wrote: >> >> When signing XML files with Xades4j (which uses Apache Santuario >> underneath) using a smart card the latter will be reset by >> Windows when the signing process takes more than 5 seconds. This >> issue exists only on Windows 8+. >> >> The problem is that the key store gets initialized before the >> digest values are computed. If this calculation takes more than 5 >> seconds Windows resets the smart card because of an inactive >> transaction. (See the attached screen shot of the log of that >> event). After the calculations are done and the actual signing >> process starts the smartcard is no more available and the task fails. >> >> This behavior is documented here >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa379469%28v=vs.85%29.aspx >> >> The solution is quite simple. The order of calculating the digest >> values and initializing the key store has to be changed. I >> located this in org.apache.xml.security.signature.XmlSignature on >> line 628 in method >> >> public void sign(Key signingKey) throws XMLSignatureException { >> ... >> try { >> //Create a SignatureAlgorithm object >> SignedInfo si = this.getSignedInfo(); >> SignatureAlgorithm sa = si.getSignatureAlgorithm(); >> OutputStream so = null; >> try { >> * // initialize SignatureAlgorithm for signing** >> **sa.initSign(signingKey);** >> **** >> ** // generate digest values for all References in >> this SignedInfo** >> **si.generateDigestValues(); * >> >> so = new UnsyncBufferedOutputStream(new >> SignerOutputStream(sa)); >> // get the canonicalized bytes from SignedInfo >> si.signInOctetStream(so); >> } catch (XMLSecurityException ex) { >> throw ex; >> } finally { >> ... >> >> To solve the problem it should be >> >> public void sign(Key signingKey) throws XMLSignatureException { >> ... >> try { >> //Create a SignatureAlgorithm object >> SignedInfo si = this.getSignedInfo(); >> SignatureAlgorithm sa = si.getSignatureAlgorithm(); >> OutputStream so = null; >> try { >> * // generate digest values for all References in >> this SignedInfo** >> **si.generateDigestValues();** >> **** >> ** // initialize SignatureAlgorithm for signing** >> **sa.initSign(signingKey); * >> >> so = new UnsyncBufferedOutputStream(new >> SignerOutputStream(sa)); >> // get the canonicalized bytes from SignedInfo >> si.signInOctetStream(so); >> } catch (XMLSecurityException ex) { >> throw ex; >> } finally { >> ... >> >> This code works for this particular setup and is able to sign an >> XML of 60GB on a Windows 10 machine. This task takes more than a >> minute and doesn't fail since Windows doesn't reset the smart >> card transaction. >> >> >> Kind regards >> >> Adrian Greiler >> >> >> -- >> Adrian Greiler >> Software Engineer >> >> Glue Software Engineering AG | Schwarztorstrasse 31 | CH-3007 Bern |www.glue.ch >> adrian.greiler@glue.ch | Office :+41 31 385 30 11 | Direkt:+41 31 385 30 34 >> >> >> >> >> -- >> Colm O hEigeartaigh >> >> Talend Community Coder >> http://coders.talend.com > > -- > Frank Cornelis > e-Contract.be BVBA > https://www.e-contract.be --------------428CCECCEF96E1AE906C0F72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I just tested with a way longer delay (more than 5 minutes) and it still worked. We have Siemens CardOS V4.3B (SuisseID) and there it fixes the problem.


Thanks for the hint / test case and kind regards

Adrian


Am 02.06.2016 um 12:29 schrieb Frank Cornelis:

Sure that this fixes the issue? What happens when the user takes more than 5 seconds to enter the smart card PIN code?


Kind Regards,
Frank.

Op 02-06-16 om 10:54 schreef Colm O hEigeartaigh:
Could you create a JIRA here and submit a patch please?

https://issues.apache.org/jira/browse/SANTUARIO

Colm.

On Thu, Jun 2, 2016 at 9:53 AM, Adrian Greiler <ag@glue.ch> wrote:

When signing XML files with Xades4j (which uses Apache Santuario underneath) using a smart card the latter will be reset by Windows when the signing process takes more than 5 seconds. This issue exists only on Windows 8+.

The problem is that the key store gets initialized before the digest values are computed. If this calculation takes more than 5 seconds Windows resets the smart card because of an inactive transaction. (See the attached screen shot of the log of that event). After the calculations are done and the actual signing process starts the smartcard is no more available and the task fails.

This behavior is documented here https://msdn.microsoft.com/en-us/library/windows/desktop/aa379469%28v=vs.85%29.aspx

The solution is quite simple. The order of calculating the digest values and initializing the key store has to be changed. I located this in org.apache.xml.security.signature.XmlSignature on line 628 in method
 
public void sign(Key signingKey) throws XMLSignatureException {
...
 try {
            //Create a SignatureAlgorithm object
            SignedInfo si = this.getSignedInfo();
            SignatureAlgorithm sa = si.getSignatureAlgorithm();
            OutputStream so = null;
            try {
                // initialize SignatureAlgorithm for signing
                sa.initSign(signingKey);
 
                // generate digest values for all References in this SignedInfo
                si.generateDigestValues();       
 
                so = new UnsyncBufferedOutputStream(new SignerOutputStream(sa));
                // get the canonicalized bytes from SignedInfo
                si.signInOctetStream(so);
            } catch (XMLSecurityException ex) {
                throw ex;
            } finally {
...

To solve the problem it should be

public void sign(Key signingKey) throws XMLSignatureException {
...
 try {
            //Create a SignatureAlgorithm object
            SignedInfo si = this.getSignedInfo();
            SignatureAlgorithm sa = si.getSignatureAlgorithm();
            OutputStream so = null;
            try {
                // generate digest values for all References in this SignedInfo
                si.generateDigestValues();
 
                // initialize SignatureAlgorithm for signing
                sa.initSign(signingKey);          
 
                so = new UnsyncBufferedOutputStream(new SignerOutputStream(sa));
                // get the canonicalized bytes from SignedInfo
                si.signInOctetStream(so);
            } catch (XMLSecurityException ex) {
                throw ex;
            } finally {
...

This code works for this particular setup and is able to sign an XML of 60GB on a Windows 10 machine. This task takes more than a minute and doesn't fail since Windows doesn't reset the smart card transaction.
 

Kind regards

Adrian Greiler
 


-- 
Adrian Greiler
Software Engineer

Glue Software Engineering AG | Schwarztorstrasse 31 | CH-3007 Bern | www.glue.ch
adrian.greiler@glue.ch | Office : +41 31 385 30 11 | Direkt: +41 31 385 30 34



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

-- 
Frank Cornelis
e-Contract.be BVBA
https://www.e-contract.be

--------------428CCECCEF96E1AE906C0F72--