New SGX SDK v2.5 for Linux has been released recently. We should upgrade and test.

When a new chaincode enclave spawns it binds itself to a given tlcc enclave using local attestation. Typically, this includes a key exchange to protect the communication between the chaincode enclave and tlcc later.

However, the current code base has hardcoded shared key. Attestation and key exchange needs a revision.

Steps

• Design of API and high-level architecture
• Library implementation
  • quick'n'dirty mock version
  • secure version
• Library test-cases
• Library integration
  • Session setup
    • from a staging perspective, we might "leak" the key here and stuff it into the place of the currently hard-coded (global) key [note this will prevent concurrent chaincodes with the session lifetime as defined in the UMLs ...)
  • Session request handling

See #410 and #420 for related bigger context.

pro:

• it is only included when the chaincode needs that

cons:

• it's a dependency external to the shim

other question:

• does every chaincode need it? If so, better put it in the shim

• build system with a top-level make and a make file in each module. More details in #56

  • build
  • test
  • check
  • integration (end-to-end-test (just calling run-auction initially?))
  • clean

• config.mk file with global variables like

  • GO
  • GOFLAGS

• code checking target. More details in #55

• refactoring of ecc (SDKization)

  • renaming of component names from trusted to secure, e.g., tlcc -> slcc
  • ecc only includes SDK (with a library)
  • auction goes to examples/auction
    • fabric/sgxconfig might also move to examples?
      • we could also replace all /path/to/fabric by $(FABRIC_SRC_ROOT)/.. with FABRIC_SRC_ROOT as $(SCC_ROOT)/../../hyperledger/fabric/ (ie., assume a single root in GOPATH and then all paths to fabric can be done in relative paths ..
        => delegated to issue #69

• Nanopb refactoring. More details in #55

• update READMEs to match above changes ..

We should upgrade to the current Fabric version 1.4.1.

Also, it might be a good idea to also pin a release tag instead of using the 1.4 release branch.

ercc does not run behind a proxy as it cannot connect to IAS

Currently, our sgx-enabled docker image fabric-ccenv-sgx depends on https://github.com/tozd/docker-sgx. Thanks again for providing this! However, a recent updated led to errors when building the docker image as reported in #29.

We should provide and maintain or own docker file.

@g2flyer has suggested:

For more long-term i propose we eventually dump docker-sgx and go with our own. We could already use the one from PDO but probably better would be to do the switch once i have a docker image for DCAP (which still supports epid) which i plan to do for PDO and try to do it also in a way that it would be easy shareable/copyable for TCC ...

In MVP, we support only designated endorser (#273) which requires exactly a single, fixed endorser. So not endorsement policies, in particular not the default MAJORITY policy will work in that case. Following are the necessary steps:

• define the sub-set of valid fabric endorsement policy expression which we support and what the semantics is
• document above in docs/design/fabric-v2+/fpc-management.md.
• (ideally) check in fabric/bin/peer.sh
  • in approveformyorg that policy is provided explicitly and specified policy as satisfiable (note realistically with designated peer, we can never realistically rely on a default policy as single peer policy would be insecure in the general fabric case)
    • actually, one "cheapo" way to check is to call the createenclave with "invoke .... --waitForEvent". This will actually run the specified endorsement policy and would bail iff that enclave is not from the correct org :-)
  • in createenclave that the peer is consistent with the specified policy.
• update FPC examples (& docu) to use the endorsement policy as specified in this work item.

We also need automated code checks, in particular for linting, as part of our checks target.
This is part of #55 and works torwards CI support #48.
PDO, for instance, uses clang to check code style.

(raised by Michael @g2flyer )
The isgx device may not exist, for instance in non-sgx-capable machines that simply want to use simulation mode.

This project may benefit from a CI for automated testing.

• this depends on #38 (creating global make)
• Travis CI is a good candidate

Currently fabric-secure-chaincode works only with Fabric 1.2.

Update to Fabric 1.4 and prepare for Fabric 2.xx

It actually does "work" (in a sense of that it does not fail) when run with different names but lots of code in tlcc and ercc seems to rely on the ns to be "ecc" for checks which probably are simply skipped if the name is different?

PS: Further qualification to "work". It seems it works in that case somewhat randomly as if there is a race-condition somewhere. Which probably also relates to all the sleeps in our tests which we might have to replace with something less brittle (i.e., checks that async action on ledger really happened correctly)

should be relatively straightforward

• TrustedLedgerCC needs a map channelname -> enclave rather than only enclave
• getMetadata has to do stub.GetChannelID() and then pick correct enclave

Note: a peer though should still be able to have additional channels as long as they do not run or interact with FPC chaincode.

(raised by Michael @g2flyer )
DCAP's sgx device is named 'sgx', so the sgx-enable patch does not provide support for that.

I installed the example chaincode using command –
$peer chaincode install -n $ccid -v 0 -p github.com/hyperledger/fabric/examples/chaincode/go/example02/cmd

But I didn’t see any docker container or image getting created here at this point of time (checked it by running commands – “docker ps -a” and “docker images -a”).

Then I went to “ecc” folder and ran the command –
make docker DOCKER_IMAGE=dev-jdoe-ecc-0
This created a new docker image but I am not sure how should I link this image with the installed chaincode (example chaincode).

Then I instantiated the chaincode using command
$peer chaincode instantiate -o $orderer -C $chanid -n $ccid -v 0 -c '{"args":["init"]}' -V ecc-vscc
This throw an error but at the same time, created a separate docker image and docker container.
The error says –
Error: could not assemble transaction, err Proposal response was not successful, error code 500, msg transaction returned with failure: Incorrect number of arguments. Expecting 4

Question remains -
• How do I rebuild the docker image for the ecc chaincode manually in such a case?
• How will I recreate the ecc docker container?
as there is no image/container getting created post installation of example chaincode.

Please suggest!
Thanks in Advance,
Chandrika

the methods provided by shim.h should be revisited. Error handling is missing, for instance, getState does not return an error when a integrity violation is detected.

The current code base uses SGX HW mode and requires IAS access for remote attestation. This makes developing and getting started with this project hard.

The build process should provide a build switch to build ecc_enclave and tlcc_enclave for SGX simulation mode.

Currently, ecc_enclave and tlcc_enclave use a script to generate mrenclave.go. However, this script is a) duplicated and b) not robust.

As suggested by @g2flyer ...

... bigger problem seems that we do no catch any errors and so it was happily running so far (just producing only an empty mrenclave). Easiest fix for that seems to be o just add a 'set -e' in the beginning?

Also, given that the generate_mrenclave.sh is the same in ecc_enclave and tlcc_enclave, maybe we should move that to a common bin directory?

Thinking of it, the method here also seems rather brittle, the way we do it in pdo is more robust:

add to sgx_sign sign the '-dumpfile "${SIGNED_ENCLAVE_METADATA}"' option (see https://github.com/hyperledger-labs/private-data-objects/blob/master/common/CMakeLists.txt) and then
extract it with a more understandable like the ' VAR_MRENCLAVE=$$(perl -0777 -ne 'if (/metadata->enclave_css.body.enclave_hash.m:([a-fx0-9 \n]+)/) { $$eh = $$1; $$eh=~s/0x| |\n//g; $$eh=~tr/a-z/A-Z/; print "$${eh}\n"; }' $(CONTRACT_ENCLAVE_MRENCLAVE_META_FILE))' in target '$(CONTRACT_ENCLAVE_MRENCLAVE_C_FILE)' in pservice/Makefile

Currently we use IAS v2 protocol. Seems this is EOL already and needs to be changed, otherwise ercc can not contact IAS to verify quotes.

part of #15
and necessary for the "one make" milestone, since users that require linkable attestations have to make changes to the code

This is a known and documented issue.
Yet, it should be automated (at least for now) for users and new developers.

IAS has a new api-key based authentication (described in revision 5.0 of IAS spec)

Generalize attestation support to cover linkable and unlinkable EPID as well as DCAP/3rd-party attestation

currently, there is no state which enables tlcc to automatically re-join channels joined on a previous "incarnation" of peer.

PS: It should work, though, by manually calling 'JOIN_CHANNEL' using the peer cli after each peer restart. It just might take a while before tlcc is fully operational if the ledger is large (and not sure whether we ever tested that?)

Also update to most recent sgx ssl version (2.4.1)

• more dev-friendly logging in sgxconfig/core.yaml
  - core.yaml vm->docker->attachStdout = true to get output in peer
  - core.yaml chaincode->logging->level = debug
  - core.yaml chaincode->logging->shim = info

• peer add default definition (if not yet defined) of FABRIC_LOGGING_SPEC to a meaningful default, e.g., vscc,ltcc,tl-encalve=DEBUG:comm.grpc=ERROR:INFO

• some reference to logging config in README

• more long term:

  • replace printf in edl with log-function which has levels so we so C levels also in Go
  • separate in enclave shim log the namespace for user-chaincode log statements from log-statements by the FPC runtime (shim)

-ercc force docker remove
-force rm in ecc_enclave
-force rm sgxcclib
-ecc docker stop check container exists
-docker rmi fails (requires 1 argument)
-tlcc rm enclave/ ... force it
-tlcc rm trustedledger ... force it
-check docker_image in ecc (patch below)
diff --git a/ecc/Makefile b/ecc/Makefile
index 7faef50..d2c0700 100644
--- a/ecc/Makefile
+++ b/ecc/Makefile
@@ -52,6 +52,7 @@ clean: docker-clean

rm enclave/mrenclave.go

docker:

•   @if [ -z "${DOCKER_IMAGE}" ]; then echo "ERROR: you have to run_action.sh first before invoking this target"; exit 1; fi
    $(DOCKER) build -t $(DOCKER_IMAGE) -f Dockerfile ..
  

docker-run:

Remove the requirement to do the xxd hack when creating spid.txt (or at least rename file to spid.bin iff we really insist on this binary format ...)

As we renamed the project and repo we need to change all readme files

make prep fails when applying patches.

patching file /tmp/linux-sgx/linux/installer/common/psw/install.sh
patching file /tmp/linux-sgx/linux/installer/bin/install-sgx-psw.bin.tmpl
Hunk #1 FAILED at 30.

Quick fix would be to pin commit 08c2457.

formatting check, referring to golinter from fabric; potentially separate comment which auto-indents potentially also clangformat related target for C code

update READMEs to match above changes ..

This is needed for CI as well.

This links back to #38

• code check for GO

• code check for c/cpp #76

• spellchecker (optional)

• license #73

IAS credentials should be checked (for existence) upfront

• in in the integration folder (once PR #79 is merged)
• in the fabric/sgxconfig/ias folder

some source files are missing license identifiers.

I propose to follow the Fabric way and use SPDX licence identifiers. They are SHORT, easy to use, machine-readable and language neutral.

Here an example

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0

Moreover, we can add fabric's license checking mechanism to our checks target.

In my opinion, some return statements in the fabric-secure-chaincode/ecc_enclave/enclave/auction/auction_cc.cpp are not correct. For example in the following section of the auction_submit method (line 115-118):

 if (auction_bytes_len == 0) {
        LOG_DEBUG("AuctionCC: Auction does not exist");
        return AUCTION_ALREADY_EXISTS; 
}

Shouldn't it return a AUCTION_DOES_NOT_EXIST? Which would imply the definition of an appropriate #define alias.

Renaming of component names from trusted to private, e.g., tlcc -> plcc

ecc only includes SDK (with a shim library )

auction (fpc-) chaincode goes to examples/auction

fabric/sgxconfig might also move to examples?

we could also replace all /path/to/fabric by $(FABRIC_SRC_ROOT)/.. with FABRIC_SRC_ROOT as $(SCC_ROOT)/../../hyperledger/fabric/ (ie., assume a single root in GOPATH and then all paths to fabric can be done in relative paths ..

make NANOPB include directly from external source (via $NANOPB_PATH so we don't need any cp (or related, currently missing, clean target)?

update READMEs to match above changes ..

this issue was part of #38

We want a build system with a top-level make and a make file in each module

• build
• test
• check
• integration
• clean

This is part of #38

Refactor run-action into a 'quick-fix' integration test

If one creates an auction, closes it and evaluates it (so without having submitted any bits), an error is thrown and the peer stops.
error.txt

I was trying to experiment with Secure Chaincode Execution using Intel SGX for Hyperledger Fabric. I followed all the prerequisites and steps given in the github link - https://github.com/hyperledger-labs/fabric-secure-chaincode .
After executing all the steps, when I tried to instantiate chaincode (ercc) using the command - $peer chaincode instantiate -n ercc -v 0 -c '{"args":["init"]}' -C $chanid -V ercc-vscc, I am getting the below error –
Error: could not assemble transaction, err Proposal response was not successful, error code 500, msg failed to execute transaction 76c60f8238b886375987a7e2a2ff4a366b5fa2e17da32ab2ab9ec251dad8860a: error starting container: error starting container: API error (500): linux runtime spec devices: error gathering device information while adding custom device "/dev/isgx": no such file or directory

Peer log is as mentioned below –

2018-12-20 12:31:34.498 UTC [golang-platform] GenerateDockerBuild -> INFO 030 building chaincode with tags:
2018-12-20 12:32:07.209 UTC [dockercontroller] func2 -> INFO 031 Container dev-jdoe-ercc-1 has closed its IO channel
2018-12-20 12:32:07.362 UTC [dockercontroller] Start -> ERRO 032 start-could not start container: API error (500): linux runtime spec devices: error gathering device information while adding custom device "/dev/isgx": no such file or directory
2018-12-20 12:32:07.467 UTC [chaincode] Launch -> ERRO 033 start failed: API error (500): linux runtime spec devices: error gathering device information while adding custom device "/dev/isgx": no such file or directory
error starting container
error starting container
2018-12-20 12:32:07.467 UTC [endorser] SimulateProposal -> ERRO 034 [mychannel][76c60f82] failed to invoke chaincode name:"lscc" , error: API error (500): linux runtime spec devices: error gathering device information while adding custom device "/dev/isgx": no such file or directory
error starting container
error starting container

I would be really grateful if anyone of you can provide any guidance to resolve this issue.

Thanks in Advance,
With Best Regards,
Chandrika Basak

Need to:

• set TOP to the path of the top level makefile
• export it for the other makefiles
• perhaps call it FPC_TOP_DIRECTORY

Enclave registry should maintain some data to bind an enclave to a specific peer. That way we can map an enclave to an organization in Fabric.

Note that, when an enclave is registered, the endorsing peer is usually the enclave host. The attestation should also reflect this.

possible solution:
create template of core.yaml for fabric with placemarks for ias credentials path
expand the template with environment variable set by user