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

Feature/secret keeper and skvs #728

Closed

Conversation

chenchanglew
Copy link
Contributor

What this PR does / why we need it:
Add application SecretKeeper and rollback protection SKVS

Which issue(s) this PR fixes:
Part of the solution for #484

Special notes for your reviewer:
to enable SKVS just need to change your application main.go from fpc.NewPrivateChaincode(xxx) to fpc.NewSkvsChaincode(xx)

// chaincode := fpc.NewPrivateChaincode(secretChaincode)
chaincode := fpc.NewSkvsChaincode(secretChaincode)

@chenchanglew chenchanglew requested a review from a team as a code owner October 10, 2023 14:12
chenchanglew and others added 2 commits October 10, 2023 16:19
Secret Keeper has 5 functions.
InitSecretKeeper:
- This function will initialize the key "AUTH_LIST_KEY" with value ["Alice", "Bob"] and key "SECRET_KEY" with value "DefaultSecret".
- This function should only be called once when the application started.
- Of course a malicious user can call this function to reset the value, but this we will assume this is not what an attacker would want to achieve.
RevealSecret:
- This function allow users that in the Authlist ("AUTH_LIST_KEY") able to reveal the value of secret stored under key "SECRET_KEY".
LockSecret:
- This function allow users that in the Authlist ("AUTH_LIST_KEY") able to store a new value of secret under key "SECRET_KEY".
- The old value will be replaced.
AddUser:
- This function allow users that in the Authlist ("AUTH_LIST_KEY") able to add a new user to the Authlist.
- Then the new user can now perform the following four functions (RevealSecret, LockSecret, AddUser, RemoveUser)
RemoveUser:
- This function allow users that in the Authlist ("AUTH_LIST_KEY") able to add remove an existing user off the Authlist.
- Then the removed user can no longer able to perform the following four functions (RevealSecret, LockSecret, AddUser, RemoveUser)

Example using fpc-simple-client:
./fpcclient invoke initSecretKeeper
./fpcclient query revealSecret Alice
./fpcclient invoke lockSecret Bob NewSecret
./fpcclient query revealSecret Alice
./fpcclient invoke removeUser Alice Bob
./fpcclient query revealSecret Alice
./fpcclient query revealSecret Bob  // (will failed)
./fpcclient invoke addUser Alice Bob
./fpcclient query revealSecret Bob // (will success)

--------
* implement secret keeper demo
* debug
* create unit test mock rollback attack
---------

Co-authored-by: Chen Chang Lew <lew@stromness.zrl.ch.ibm.com>
Co-authored-by: tester <tester@fpc>
Signed-off-by: chenchanglew <chelew@student.ethz.ch>
Signed-off-by: chenchanglew <lewchenchang@gmail.com>
Create a solution for protecting against rollback attack.
Solution: Single Key Value Storage (SKVS)

Just need to apply one line of change in your chaincode main.go to use SKVS solution:
```
secretChaincode, _ := contractapi.NewChaincode(&chaincode.SecretKeeper{})
chaincode := fpc.NewSkvsChaincode(secretChaincode)
```

Skvs solution will store all the key under the main key "SKVS".
before: {"Alice": "DataAlice", "Bob": "DataBob"}
After: {"SKVS": {"Alice": "DataAlice", "Bob": "DataBob"} }

By using this approach we are able to protect against Rollback + key mismatch problem since all the data are now just store under one single key.

Special notes for your reviewer:
This approach is very user friendly because you just need to change one line of your main application to get the properties of rollback protection.
However, which this approach will reduce the performance of FPC a lot because it didn't perform well in concurrent situation because every changes will cause a conflict in their Transactions happened to be in a same block.
Thus if developer would like to use this approach will need to make sure your application doesn't required high throughput and will expected it to update once a while.
----
* add singleKVS wrapper
* able to save into single key
* change to only getState Once
* change storing type and add del state
* refactor part 1 - private can run
* refactor part 2 - skvs run successfully
* remove unnecessary logging change back samples

Signed-off-by: chenchanglew <chelew@student.ethz.ch>
Signed-off-by: chenchanglew <lewchenchang@gmail.com>
@chenchanglew
Copy link
Contributor Author

hi @mbrandenburger, can you help me to review this, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant