Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend FPC Shim support #637

Merged
merged 8 commits into from
Dec 7, 2021
Merged

Conversation

mbrandenburger
Copy link
Contributor

@mbrandenburger mbrandenburger commented Nov 8, 2021

  • add get_signed_proposal
  • add get_tx_id
  • add get_channel_id
  • add get_creator

Signed-off-by: Marcus Brandenburger bur@zurich.ibm.com

@mbrandenburger
Copy link
Contributor Author

TBD what to do with the transient data?

@mbrandenburger
Copy link
Contributor Author

TBD what to do with the transient data?

transient data support will be separate PR.

@mbrandenburger mbrandenburger changed the title WIP Extend FPC Shim support Extend FPC Shim support Nov 10, 2021
@mbrandenburger mbrandenburger marked this pull request as ready for review November 10, 2021 08:27
@mbrandenburger mbrandenburger requested a review from a team as a code owner November 10, 2021 08:27
@mbrandenburger mbrandenburger added comp/shim This issue is related to the FPC shim exposed to FPC Chaincode feature labels Nov 10, 2021
Copy link
Contributor

@bvavala bvavala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two parts: 1) shim extensions and 2) shim internals.

  1. 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.

  1. 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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right! added

ctx.creator = ByteArray(signature_header.creator->bytes,
signature_header.creator->bytes + signature_header.creator->size);

// TODO check signed proposal signature
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This missing signature check is a major missing part, giving that this code accepts input data from the signed proposal.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here creator is not checked for consistency with the get_creator_name -- see also other comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right - I figured out how to extract creator_name directly from the signed proposal, so I jusggest just to remove the ocall. WIP

- 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>
Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>
@mbrandenburger
Copy link
Contributor Author

I just experienced that this code is not compatible with Idemix.

With current FPC, Idemix is working as long as you not call get_creator_name. The problem with Idemix is that the serialized identity does not contain a x509 cert (in pem format), instead it contains a serialized idemix identity (as protobuf msg). As said, this is only a problem with get_creator_name, where we try to extract the cert subject.

That is, the code in this PR fails when it tries to parse the x509 as it is actually an idemix identity.

@mbrandenburger
Copy link
Contributor Author

mbrandenburger commented Dec 1, 2021

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.

@mbrandenburger
Copy link
Contributor Author

@bvavala are you still looking at this?

@bvavala
Copy link
Contributor

bvavala commented Dec 7, 2021

comments addressed - not tested in hw mode

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp/shim This issue is related to the FPC shim exposed to FPC Chaincode feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants