Extend FPC Shim support #637
Conversation
|
TBD what to do with the transient data? |
transient data support will be separate PR. |
There was a problem hiding this comment.
Two parts: 1) shim extensions and 2) shim internals.
- Overall, the shim extensions look good. Those can provide the chaincode with useful information which was either previously attested, or extracted from the signed proposal.
Missing: comments and documentation regarding the channel id and, particularly, the creator. The creator is not (and cannot be) validated against the ledger/MSP -- the enclave does not have trustworthy data to do so.
- The shim internals need some more work.
First, some data is extracted from the signed proposal, but the signed-proposal signature is not checked. Although documented, this could open to unintended consequences.
Second, the channel id and creator are extracted from the proposal, but the former is already passed to (and attested by) the enclave at init time, while the latter already has a shim API for the name. In both cases, consistency is not checked. Again, this could open to unintended consequences.
| tx_id = ctx->tx_id; | ||
| } | ||
|
|
||
| void get_creator(ByteArray& creator, shim_ctx_ptr_t ctx) |
There was a problem hiding this comment.
There is already a get_creator_name API above.
I believe these two functions return different yet related things. Is there any check for consistency?
There was a problem hiding this comment.
I changed the implementation of get_creator_name to extract the dn directly from the creator cert provided with the signed proposal instead of performing the ocall.
| COND2LOGERR(!b, PB_GET_ERROR(&istream)); | ||
|
|
||
| ctx.tx_id = std::string(channel_header.tx_id); | ||
| ctx.channel_id = std::string(channel_header.channel_id); |
There was a problem hiding this comment.
The channel id is already available in the cc_params blob that is passed at init time, and attested!
Here there is no consistency check with that value -- they must be the same.
There was a problem hiding this comment.
right! added
ecc_enclave/enclave/enclave.cpp
Outdated
| ctx.creator = ByteArray(signature_header.creator->bytes, | ||
| signature_header.creator->bytes + signature_header.creator->size); | ||
|
|
||
| // TODO check signed proposal signature |
There was a problem hiding this comment.
This missing signature check is a major missing part, giving that this code accepts input data from the signed proposal.
There was a problem hiding this comment.
signature check added
| b = pb_decode(&istream, common_SignatureHeader_fields, &signature_header); | ||
| COND2LOGERR(!b, PB_GET_ERROR(&istream)); | ||
|
|
||
| ctx.creator = ByteArray(signature_header.creator->bytes, |
There was a problem hiding this comment.
Here creator is not checked for consistency with the get_creator_name -- see also other comment.
There was a problem hiding this comment.
right - I figured out how to extract creator_name directly from the signed proposal, so I jusggest just to remove the ocall. WIP
01d3acd to
af2a914
Compare
- add get_signed_proposal - add get_tx_id - add get_channel_id - add get_transient_data Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>
Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>
Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>
Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>
Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>
Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>
Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>
af2a914 to
d25bf2b
Compare
Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>
|
I just experienced that this code is not compatible with Idemix. With current FPC, Idemix is working as long as you not call That is, the code in this PR fails when it tries to parse the x509 as it is actually an idemix identity. |
Maybe not an issue for now! I suggest to tackel this in a follow-up PR. |
|
@bvavala are you still looking at this? |
|
comments addressed - not tested in hw mode |
Signed-off-by: Marcus Brandenburger bur@zurich.ibm.com