Repository navigation
Questions about unattended EBICS 3.0 downloads for ZKB #54
Description
Hi, thanks for maintaining this project.
I’m helping a business download ZKB statements (camt.053 v08) and PDF bank documents over EBICS 3.0. We only need downloads, not payments. I’m evaluating the current master at 9e45631.
I’m not an EBICS expert. An AI-assisted review raised a few concerns worth checking before we run this unattended:
- Private keys saved outside the password-protected keystore — I see this is already reported in (Copy of) private key is stored unencrypted #38.
- How bank keys and incoming bank responses are verified.
- Downloads overwriting an existing file before the new data is checked.
- How to recover safely if the connection drops around the download acknowledgement.
We checked the code paths and reproduced some behaviors locally, without contacting a bank. We may still be missing context about the intended usage.
Would you be open to findings from an AI-assisted review? Happy to share more details and contribute a focused PR if useful. For the security-related details, is there a private reporting channel you’d prefer?
Activity
uwemaurer commentedon Sep 10, 2026
Yes, I am looking forward to your PR and findings in general. We also use it with ZKB.
I agree the way the configuration is saved currently is bad. It is saving everying using java serialization (including the keys). My plan was to switch to regular JSON or XML files for the settings (without the keys) and store the keys in standard file formats (PKCS#12).
It is cleaner and better to deal with than java serialization. However in the end it is the same data just stored differently, so these files need to be kept private.
CooperBigFoot commentedon Nov 11, 2026
Thanks @uwemaurer: I rechecked the EBICS 3.0 paths against 2.2.1 (
40b12ac).I have six months of access to top-tier Google models for research and am using it to
support careful, human-reviewed contributions, rather than sending you a raw AI report.
Two small fixes, with no intended EBICS wire or public-API change:
A failed decryption/decompression no longer truncates an existing file or creates an empty one.
Truncated and preset-dictionary streams fail promptly, and inflater resources are always released.
Both include regression tests and pass
./mvnw verifyon Java 17.Would you welcome small follow-up PRs for these conformance points?
DefaultConfiguration.java:203–205reads bundledH003(config.properties:32),ignoring supplied properties, so the launcher's
EBICS_VERSION=H005has no effect.KeyUtil.java:77–99hashes RSA exponent/modulus text rather than certificate DER.EBICS 3.0.2 §5.6.1.1.1 p120 specifies SHA-256 of DER; Common IG ExtVersion03
§2.4.4 pp23–24 gives a worked example and recommends banks accept both during transition.
Would you try a focused digest fix against ZKB? Persisted bank digests would need
recomputing or a fresh HPB. This is a conformance issue, not a demonstrated live blocker.
ReturnCode(§5.6.1.1.2 p125;§5.6.1.1.3 pp127–129). The CLI also ignores unknown flags, and legacy order flags
with neither input nor output can silently do nothing.
KeyManagement.sendHPBinstalls bank keys without certificate-hash display/comparison(§4.4.2.1 p64; IG §2.4.4 p22), and download/transfer/receipt paths do not verify
AuthSignature(§3.8 pp29–30). I can contribute HPB SHA-256 hash display/pinning,then X002 response verification, with synthetic regression tests alongside the fixes.
I can discuss sensitive details privately first if you prefer.
For #38, I would be happy to help with text settings + PKCS#12, accounting for migration
and #48's
ExternalKeyProvider. Do you prefer dependency-free XML/Properties, or JSONwith a particular library? I can propose a layout on #38 after agreeing that direction.
One ZKB interop observation from my H005 use: a normal Transfer response in a multi-segment
download carried a signed
TimestampBankParameter(authenticate="true", covered byAuthSignature), although the H005 annotation says “may be set during initialisation phase only”.Strict phase/signature validation should account for this without dropping authenticated content.