OFTP2 signature uses wrong hash algorithm

We are using mendelson opensource OFTP2 1.0 build 35

We have a partner setting with the following security settings on both sides:
Encrypt outbount message
sign outbound message
Request signed ack
AES 256
SHA-512

Sending outbound works.

For inbound messages we get an error, that the file signature uses SHA-224 while SHA-512 was expected. The partner doesn't use SHA-224.
So the question is: what's going wrong?

Here the complete log:
Preprocessing
[Jan 31, 2019 12:14:56 PM] Set state from "preprocessed" to "in transfer"
[Jan 31, 2019 12:14:56 PM] Ensured existing target dir "C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending"
[Jan 31, 2019 12:14:56 PM] Will move file from "C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending\ZF_TEST201901311214550001" to "C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending\ZF_TEST201901311214550001"
[Jan 31, 2019 12:14:56 PM] File move NOT performed, source file and target file are the same for this processing step

Transmission
[Jan 31, 2019 12:14:56 PM] [Session 20190131121455-5034] Inbound data transmission detected.
Sender: Haru / ZF
Receiver: _RIB Cosinus GmbH
Virtual filename: ZF_TEST
Format: U
Encrypted: Yes
Signed: Yes
Compressed: Yes
Storing data to "C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending\ZF_TEST201901311214550001"
[Jan 31, 2019 12:14:56 PM] [Session 20190131121455-5034] Data fully transmitted. Received 1130 bytes in 0.0s (11.7 kb/s)
[Jan 31, 2019 12:14:56 PM] Set state from "in transfer" to "transmitted"
[Jan 31, 2019 12:14:56 PM] Ensured existing target dir "C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending"
[Jan 31, 2019 12:14:56 PM] Will move file from "C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending\ZF_TEST201901311214550001" to "C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending\ZF_TEST201901311214550001"
[Jan 31, 2019 12:14:56 PM] File move NOT performed, source file and target file are the same for this processing step

Postprocessing
[Jan 31, 2019 12:14:56 PM] Starting data postprocessing [C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending\ZF_TEST201901311214550001], size: 1130 bytes
[Jan 31, 2019 12:14:56 PM] Generating virtual file hash for [C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending\ZF_TEST201901311214550001]
[Jan 31, 2019 12:14:56 PM] Virtual file hash generated successfully [9c 93 12 42 33 18 fe 2d cc 99 a0 cd 81 26 f5 b1 85 c3 29 6e]
[Jan 31, 2019 12:14:56 PM] Decrypting transfer data [C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending\ZF_TEST201901311214550001]
[Jan 31, 2019 12:14:56 PM] The transfer data has been decrypted using the key with the alias "oftp.rib-cosinus.cloud"
[Jan 31, 2019 12:14:56 PM] Uncompressing transfer data [C:\Program Files\mendelson\opensource\oftp2\messages\_RIB_Cosinus_GmbH\inbox\Haru___ZF\pending\ZF_TEST201901311214550001]
[Jan 31, 2019 12:14:56 PM] Transfer data is signed, verifying signature
[Jan 31, 2019 12:14:56 PM] The signature matches the data content (using the certificate "oftp2.zf.com") but uses the wrong hash algorithm. The expected hash algorithm is "SHA-512" but the data has been signed using the algorithm "SHA-224"
[Jan 31, 2019 12:14:56 PM] Data postprocessing failed
[Jan 31, 2019 12:14:57 PM] [ZF_TEST|20190131|1214550001]: A transaction error notification mail has been sent to e-business@rib-cosinus.com.
[Jan 31, 2019 12:14:57 PM] A signed negative acknowledgement (NERP) has been requested
[Jan 31, 2019 12:14:57 PM] The negative acknowledgement (NERP) has been signed using the algorithm SHA-512, transmission file hash has been added

Finish
[Jan 31, 2019 12:15:08 PM] [Session 20190131121507-5035] Negative transmission acknowledgement (NERP) for _RIB Cosinus GmbH (O0013008717COSINUS) has been sent to Haru / ZF

Forum
OFTP2

Comments

Profile picture for user service
Permalink

Hello,

the algorithm is checked using the bouncycastle crypto API.
This seems to work so far - how did you figure out that your partner does not use SHA-224? Could you reproduce this problem using two mendelson OFTP2 installations?

Regards

Permalink

Hello,

our partner told me, that he is not using SHA-224. He showed me a partial screenshot where AES_256_CBC/RSA_PKCS1_15/SHA-512 is selected. I don't know what software he is using. We have several other partners, but this is the first one where we have to use the security settings.
I still have the file with the probably wrong signature. Is it possible to check the signature by hand ouside mendelson OFTP2?

Kind Regards

Profile picture for user service
Permalink

Hello,

that should be possible using openssl. Please web search for "openssl validate file signature", that leads to some examples.

Regards

Permalink

Hello,

tried this validation but as I don't know what to do, I only get errors. I don't have the time to get that running.

So my question is now:
If outbound messsages work without error but inbound messages get a signature error: Is this an error of mendelson OFTP2 or is the partner doing it wrong?

Kind Regards

Permalink

Hello,

found something in addition:
Outbound is working, but in log there is this message:
[Feb 6, 2019 12:09:28 PM] [Session 20190206120927-5800] The computed hash value of the transmitted data differs from the received hash value of the received acknowledgement (EERP/NERP). Generated hash value: [30 0f b9 f1 78 27 97 01 b1 11 74 fa d9 82 42 20 87 40 19 11], received hash value: [b8 2e dc 6f b9 fe 76 ab 2b 4a 83 f1 a4 a8 f1 c5 1f 14 54 a4 09 b1 ba 72 e7 6a b5 92]

Kind Regards

Permalink

Hello again,

again some additional infos:
Our Partner is using Axway TS Integration Manager.
When we both use 3DES and SHA1, it's working without any trouble.
Our partner is using AES256 SHA512 with other partners and other oftp2 software successfully.
It seems, that the combination Mendelson - Axway TS Integration Manager with SHA512 is not working properly.

What additional information do you need to solve this problem?

Profile picture for user service
Permalink

Hello,

sorry but we cannot fix anything if an other OFTP2 vendor seems to use the wrong algorithm? How should we do this?

Please have a look at your first post:

[Jan 31, 2019 12:14:56 PM] The signature matches the data content (using the certificate "oftp2.zf.com") but uses the wrong hash algorithm. The expected hash algorithm is "SHA-512" but the data has been signed using the algorithm "SHA-224"

..this means your partner told you that he uses SHA-512 but uses instead SHA-224. I don't think that our crypto API identified the wrong signature alorithm, I trust this. What is the idea of your partners support regarding this issue? Would they fix this?

And to your idea that this works with other OFTP2 software - well they just seem to check the signature but not if the right algorithm has been used - then you could also stay at SHA-1...

Regards