Question on transaction signing & backend trust in Fabric

[KALYANI100]

Hi everyone,

I’m currently working on a project involving permissioned blockchains for supply chain and healthcare applications.

While exploring Hyperledger Fabric, I noticed that transaction signing is often handled by backend systems that hold the signing credentials. This raised a concern:

• Scenario: Suppose a patient record or a shipment record is submitted to Fabric via an application. The backend holds the signing credentials and signs transactions on behalf of the users.
• Problem: If the backend is ever compromised, an attacker could potentially submit transactions on behalf of any user. This could result in unauthorized modifications, loss of auditability, or loss of control over user-submitted transactions.

My questions are:

1. How does Hyperledger Fabric mitigate this risk?

   • Are there recommended ways to store credentials or enforce per-user signing without relying entirely on the backend?

2. In sensitive workflows (e.g., healthcare records), how can Fabric ensure that only legitimate users can submit transactions even if the backend is compromised?

I would greatly appreciate any pointers to design documents, architectural discussions, or examples illustrating how Fabric handles backend trust and user key management.

Thank you so much for your time and insights!

Best regards,
Kalyani Gade

[bestbeforetoday]

You could do signing in the frontend using credentials only held by the user and not visible to the backend. A pattern for doing this using the Fabric Gateway client API is described in the API documentation as off-line signing (Node, Go, Java). Here the backend generates the messages that will be sent to Fabric but the client generates the signatures, either based on the whole message generated by the backend, or using just a digest (hash) of the message. The documented off-line signing approach does require the client to either: trust the backend (that will invoke Fabric) to generate a valid transaction, or be prepared to validate the message content before signing.

An even more decentralized approach would be for the client to generate the signed proposal message itself, then send it to the backend for it to forward on to Fabric. The client API does not expose mechanisms for the client to do this today, but the internals of the client API that build the messages could be pretty easily lifted out and reused. For a JavaScript client (for example, a Web browser) there is a prototype client API implementation to provide exactly this workflow in this pull request. The README describes the proposed usage.