German protocol hackplementation

[pinaraf]

Hello

I'm on my way to hackplement German support in this ebics client.
The bank I'm communicating with does not recognize the keys I send them so far, I'm working on the issue in the letters. It otherwise seems to be fine.
My work is based on oscar's changes.
As soon as my hackplementation is working, I'll publish here for reference purpose only and try to do a proper one afterwards (I don't want to be responsible for any disaster)

[pinaraf]

Hello all

My hackplementation is done and working !
I went through HIA, INI, sending letters, HPB and a few requests with no issue.
I have not uploaded any file so far, but for other reasons (stupid differences between SEPA in france and SEPA in germany it seems).

To sum up the differences :
1) German banks use and want public keys, not certificates
2) France use file upload / file download (blob in, blob out) order types while germany use lots of order types, one per operation, making it far nicer from a protocol point of view.

Attached to this message is the DIRTY DO NOT USE patch.
It breaks the examples (which are broken anyway with german ebics because they rely on FDL/FUL…)
It is based on my maven-based clone of ebics (far far simpler to build, clean…)
It contains a bit more than just supporting DE ebics. For instance, I dropped the org/kopi/ebics/session/OrderType.java class and replaced it with an enum (it was a sanity nightmare).
As you can see, the dirty patch is not that big. The clean one will be much bigger, I hope to send it in the next 10 days.

[pinaraf]

Here is a cleanep up patch.
I added a useCertificate flag to the EbicsBank object. That way, the same code is usable for German and French banks.
I have not translated the letters so far.
Any feedback would be highly welcome on this.
As is, I think this code starts being usable, but could use help, further cleanups…

[mkurz]

Awesome! Thanks for your time!

[pinaraf]

Let me know if this is of some use to you :)

[pinaraf]

Side effect of the patch : if this is applied, as is, it will create issues with everybody who uses the default serialization system for EbicsBank objects. They would have to «update» their objects and set the flag to true.

[zalmolxis]

Hi, I tried
de-support.patch an I was successful on INI/HIA and HPB request but when I'm trying to fetch files using order type of my bank I'm getting authentication error , can you direct me where I can read more about differences between German an France ebics format

Thanks.

[pinaraf]

Hi

Could you try using the pre-patched github fork until the patches are integrated ?
https://github.com/pinaraf/ebics

On my spare time, I started working on a GUI for the ebics client, but there is soo much to do for a GUI that it won't be ready for some time.

[zalmolxis]

Hi,

I have tried this fork (with few modification my bank has the same userid and partenerid) and the result is: HPB request is made with no errors but when I try to fetch files I get
<ebics:ReturnCode>091008</ebics:ReturnCode>
<ebics:ReportText>[EBICS_BANK_PUBKEY_UPDATE_REQUIRED] Bankschlüssel ungültig</ebics:ReportText>

[Design Majelis]

Hi,

I have the same problem.
Did you find a solution ?

[Achilles]

@Design Majelis Did you find a solution to your problem?

[Design Majelis]

Hi,
The bank tells me that library return an another pubkey than the HPB pubkey. I don't know why and I'm still looking.

[Achilles]

@Design Majelis: I actually found a solution to this. Do the following:

Go to: org.kopi.ebics.certificate.KeyUtil. getKeyDigest()

and replace the whole function with the following:
`
public static byte[] getKeyDigest(RSAPublicKey publicKey) throws EbicsException {
String modulus;
String exponent;
String hash;
byte[] digest;

  exponent = Hex.encodeHexString(publicKey.getPublicExponent().toByteArray());
  // modulus = Hex.encodeHexString(removeFirstByte(publicKey.getModulus().toByteArray()));
  modulus = Hex.encodeHexString(publicKey.getModulus().toByteArray());
  if (exponent.charAt(0) == '0') {
     exponent = exponent.substring(1);
  }

  if (modulus.charAt(0) == '0') {
     modulus = modulus.substring(1);
  }
  hash = exponent + " " + modulus;

  if (hash.charAt(0) == '0') {
     hash = hash.substring(1);
  }

  try {
     digest = MessageDigest.getInstance("SHA-256", "BC").digest(hash.getBytes("US-ASCII"));
  } catch (GeneralSecurityException e) {
     throw new EbicsException(e.getMessage());
  } catch (UnsupportedEncodingException e) {
     throw new EbicsException(e.getMessage());
  }

  return new String(Hex.encodeHex(digest, false)).getBytes();

}
`

[Design Majelis]

Your solution seems strange because you delete one of the two characters of an hexa (the first of modulus).
EBICS specification :
"The SHA-256 hash values of the financial institution's public keys for X002 and
E002 are composed by concatenating the exponent with a blank character and the
modulus in hexadecimal representation (using lower case letters) without leading
zero (as to the hexadecimal representation). The resulting string has to be
converted into a byte array based on US ASCII code."

Thanks @Achilles but for me, the problem was elsewhere and the original getKeyDigest() works great.

[Achilles]

But isn't that exactly what my solution does? i.e., concactenate exponentwith blankSpace and modulus-- without leading zeros. The third if(has.charAt(0)) check is probably redundant... and will never execute since we removed the leading zeros beforehand.

Anyhow, it's great that you found a solution.

[Gregor Nikolaus]

I think I found the root cause of the problem.
The above solution worked for me for download operations, however once i tried to upload files I always had bouncycastle tell me that it cannot use the E002 key to encrypt the data (The 16byte nonce) because the key is to short.

What i found out is that my german bank returned the E002 public key modulus without a signum byte and the byte at index 0 was a negative value.

So when simply passing that byte array to the BigInteger constructor it always interpreted it as a negative number, and a RSA key with a negative modulo makes little sense.

I fixed it by using the BigInteger constructor that always treats the passed byte array as a positive number:

// old
// e002PubKey = keystoreManager.getPublicKey(new BigInteger(orderData.getBankE002PublicKeyExponent()), new BigInteger(orderData.getBankE002PublicKeyModulus()));

// new
e002PubKey = keystoreManager.getPublicKey(new BigInteger(orderData.getBankE002PublicKeyExponent()), new BigInteger(1, orderData.getBankE002PublicKeyModulus()));

If you make sure that the modulus is always positive then both the old getKeyDigest as well as your change should produce the same result. (Because removing the signum byte before converting to hex or the leading zeroes after should make no difference)

[Achilles]

@zamolxis Did you find a solution to your problem?

[mascho]

Hi pinaraf,

I would be interested in helping you with a gui i if you want to. I started working on this as well but it is very boring doing this alone :-)