Replys do not contain signatures or macs

[RjRDRG]

System.config parameter useSignatures and useMac as no effect on server replys, only on client requests A separate system.config parameter for replys would be ideal

/ replies are not signed in the current JBP version
sm.signed = false;
// produce signature if necessary (never in the current version)
if (sm.signed) {
    byte[] signature = TOMUtil.signMessage(privKey, data);
    sm.serializedMessageSignature = signature;
}

https://github.com/bft-smart/library/blob/master/src/main/java/bftsmart/communication/client/netty/NettyClientServerCommunicationSystemServerSide.java

[bergerch]

Hi, note that the client <---> server connections are secured through the use of TLS (messages are encrypted and their integrity is protected by the use of message authentication codes). In short: messages that come from the server will can be always authenticated and their integrity is protected.

The reason why there is an option to add signatures to client requests is to account for the possibility of malicious clients. Malicious clients could try to prevent that requests are correctly disseminated to all replicas, and in fact, this can lead to enforced leader changes: if a leader has not seen a request, it will not order it, and then be blamed by other replicas that received the request. However, if client requests are signed, then the signature makes sure that this request can be authenticated by all replicas, thus it is possible to forward the request to other replicas that did not receive it.

tldr; signing responses is not necessary; client request signatures protect the system against malicious clients (so this configuration option depends on what your assumptions are in your system)

[RjRDRG]

Hello, in our system, the user client is behind a proxy that communicates with bft-smart. Because the proxy is not in our trust computing base, end-to-end authentication between the client and each bft-smart replica is required.

Furthermore, we do not require encryption for our messages; we simply want integrity, authentication, and non-repudiation assurances. Tls does not entirely address our non-functional requirements and adds unnecessary overhead due to message encryption.

[rvassantlal]

Hi, End-to-end authentication in your case can be provided by signing responses at the service level. Currently, I am not seeing if signing responses are useful in general.

The encryption can be deactivated using this cipher set #system.ssltls.enabled_ciphers = TLS_ECDHE_ECDSA_WITH_NULL_SHA,. However, this might require changing your java configurations to use tls without encryption.