The signing algorithm hashes twice about avalon

[manojgop]

@kubasiemion This is a good catch. This behavior of signMessage() function is due to a legacy code taken from https://github.com/hyperledger-labs/private-data-objects/. Though signMessage() function documents about this behaviour, it's confusing to TCF clients. I've raised a PR #127 to avoid hashing twice.

[arsulegai]

I am curious here and would like to understand in greater detail, why is this done like the way it is there today. Correct me as I am new to this framework

• concatenate the relevant parts of a request

• calculate sha256 of this extract --> h1

• encrypt the resulting hash and include it in the request
  [Arun] I guess the encryption key spoken about here is a symmetric key, and is shared only with the enclave. This is a proof to the enclave about message integrity.

• calculate sha256 of the hash h1 --> h2

• sign the hashed hash h2 with some private key

• include the signature and the public key in the request
  [Arun] Generally public key of the requester should be known to the enclave as a priori. Otherwise, it is possible to attack the enclave (at least DoS) and fail the requests. The signature is sent along with the public key to verify it. It would at least help if the signature is calculated on encrypted(hash(message)) which is encrypted(h1). This way there is link between message -> digest -> encrypted digest -> signature. The final information gained by the enclave is the public key of the requester.

Another question out of curiosity, what is the public key of the requester used for?

[manojgop]

@arsulegai You can refer to https://entethalliance.github.io/trusted-computing/spec.html#work-order-signing.

[arsulegai]

Right! the line "Distribution of the corresponding public keys is outside of the scope of this specification" clarifies. So, in case of HL Avalon/TCF the implementation is to rely on the encryptedSessionKey to share the public key.

i.e. Instead of sign(message), it should be sign(encrypted(hash(message))). In other words sign(encrypted(h1)) from previous comment I pasted. This way public key can be safely shared.

[manojgop]

As mentioned in spec, there are two mechanisms ensuring the integrity of a work order request:

1. encryptedRequestHash contains the hash of the work order request encrypted with a key from encryptedSessionKey. This mechanism ensures the request integrity even in the case of an anonymous requester. The hash value in this case is verified by the worker.

2. requesterSignature is an optional signature that uses the same calculated hash value and signs it with the requester's private signing key