Possible problems in User sign method

[Harro Lissenberg]

We had a problem with sending a PAIN.008 file (CDD order) to our German partner bank. We where using the sign method as defined in class User to sign the content of the PAIN.008 file.

We got the message "Unterschrift is falsch / Invalid signature" message as a response and after some digging found that the User.sign() method does not work for us (it does for a French bank and/or other order types?)

https://sourceforge.net/p/ebics/code-0/16/tree/trunk/src/org/kopi/ebics/client/User.java#l529

2 problems existed:

1.
The removeWhiteSpace method removes spaces, tabs, eol and carriage return chars and references to the specification 2.4.2 paragraph 7.1. However that paragraph is on segmentation of the order data, not signing. Appendix 14 has this to say: "The characters restricted to the operating system (CR, LF and Ctrl-Z) are not included in the calculation of hash values of the A005/A006 ES (analogous to A004 ES)."

2.
The bytearray used to filter the unwanted characters contains trailing 0x00 bytes if the content of the orderdata is less than the buffer size of 4096 bytes. These 0x00 bytes are used in the signature calculation and resulting in invalid signatures.

I ended up rewriting the sign method as follows:

public byte[] sign(byte[] content) throws GeneralSecurityException {
    Signature sig = Signature.getInstance("SHA256withRSA");
    sig.initSign(a005PrivateKey);
    sig.update(removeOSSpecificChars(content));
    return sig.sign();
}
private byte[] removeOSSpecificChars(byte[] content) {
    ByteArrayOutputStream bas = new ByteArrayOutputStream();
    for(byte b : content) {
        switch (b) {
            case '\r':
            case '\n':
            case 0x1A: // CTRL-Z / EOF
                // ignore this characters
                break;
            default:
                bas.write(b);
        }
    }
    return bas.toByteArray();
}

Please note: I also removed the dependency on GNU Crypto in the process but that was not needed to fix the bug.

Not sure if you can use this information; as said before perhaps the signing was legal for a French bank but with our German bank it was not.

[bobi]

Hi Harro,

I have a signature problem that may be related to yours.
Briefly, when parsing a FUL request their server encounters an exception "javax.crypto.BadPaddingException: unknown block type". Is that the error you had with your bank ?

So i wanted to test your fix but it does not compile. Could you please give the full fix ?

Thx Dominique

[Harro Lissenberg]

This particular problem did not manifest itself with a Bad padding exception.

However, German banks do require a certain type of padding during encryption. For that we had to modify the Utils.encryptOrDecrypt method as well:

~~~~~~~~
private static byte[] encryptOrDecrypt(boolean encrypt, byte[] input, Key keySpec) throws EbicsException {
try {
AESEngine engine = new AESEngine();
ISO10126d2Padding padding = new ISO10126d2Padding();
PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(new CBCBlockCipher(engine), padding);
ParametersWithIV parameters = new ParametersWithIV(new KeyParameter(keySpec.getEncoded()), new byte[16]);
cipher.init(encrypt, parameters);
byte[] cipherValue = new byte[cipher.getOutputSize(input.length)];
int outputLen = cipher.processBytes(input, 0, input.length, cipherValue, 0);
cipher.doFinal(cipherValue, outputLen);
return cipherValue;
} catch (DataLengthException | IllegalStateException | InvalidCipherTextException e) {
throw new EbicsException(e.getMessage());
}
}
~~~~~~~~~

Are you communicating with a German EBICS implementation or a French?

What compilation problems are you running into? What are you missing?

[bobi]

I'm communicating with a French bank.

When i try to compile your sign method, i get the following build errors :

[javac.def] ~/ebics-client/src/org/kopi/ebics/client/User.java:530: unreported exception java.security.NoSuchAlgorithmException; must be caught or declared to be thrown

[javac.def] Signature sig = Signature.getInstance("SHA256withRSA");

[javac.def] ~/ebics-client/src/org/kopi/ebics/client/User.java:531: unreported exception java.security.InvalidKeyException; must be caught or declared to be thrown

[javac.def] sig.initSign(a005PrivateKey);

[javac.def] ~/ebics-client/src/org/kopi/ebics/client/User.java:532: unreported exception java.security.SignatureException; must be caught or declared to be thrown

[javac.def] sig.update(removeOSSpecificChars(content));

[javac.def] ~/ebics-client/src/org/kopi/ebics/client/User.java:533: unreported exception java.security.SignatureException; must be caught or declared to be thrown

[javac.def] return (byte[]) sig.sign();

[javac.def] 4 errors

What am i missing ? (my JVM is OpenJDK Runtime Environment 6 running on a linux server)

[Harro Lissenberg]

Are you sure you have the same signature?

public byte[] sign(byte[] content) throws GeneralSecurityException

Since the GeneralSecurityException is the parent of those exceptions you mention.

Anyway, my projects runs with Oracle JDK 7. I personally would prefer this over IcedTea. But I am not sure it makes a difference.

[bobi]

Ok. Understood.

I had kept old sign method signature to conform to its interface. After changing sign signature and its interface accordingly, it builds. \o/

But no effect on my padding problem...

I'll try other JVM (Oracle one, v1.7) to see if it makes a difference. Also, which BouncyCastle version do you use ?

Thx Dominique

[bobi]

Well, Oracle JVM v1.7 did not solve anything for me.

Alas...

[Harro Lissenberg]

Bouncycastle jdk16 v 1.46

<dependency>
<groupid>org.bouncycastle</groupid>
<artifactid>bcprov-jdk16</artifactid>
<version>1.46</version>
</dependency>

[bobi]

Ok same as me. Thx alot for your answers Harro.

As for now, methinks i need seriously help. I'm really opened to contract someone to help me resolve our bug. Hacheni, would it be possible to contact you outside this forum to dicuss further about this ?

Regards, Dominique

[bobi]

In checking everyting to try to fix my bug, i've re-done a complete test against qualif-ebics.fr test server.

I've done it with EBICS client latest svn source AND ALSO with the same version + harro patch (sign method) applied + typo errors (see other topic) applied

1. lastest SVN
   INI+HIA : OK
   HPB : OK
   FUL : ERROR => ES Signature invalide
   FDL : OK

2. latest SVN + patches
   FUL : OK

So it seems, the patch from harro seems mandatory to make it work with qualif-ebics. Hacheni, don't you think you should consider to test and commit those changes from your side ?

Regards,
Dominique

[hacheni]

Hi,

I think that I should consider harro changes cause it seems to be a signature bug in the client.

Can you send me just what changes to be done cause I am not really up to date with your conversations.

I will integrate them, re do the EBICS qualifications test and finally commit them.

Thank you
Hachani

[OSS]

Hi Hacheni,

Could you tell me when it is ok, please?

Thank you in advance.

Regards,
OSS