基于以太坊geth客户端的keccak256算法并开放出JSON-RPC接口实现功能全部资料+详细文档.zip

# Clef Clef can be used to sign transactions and data and is meant as a(n eventual) replacement for Geth's account management. This allows DApps to not depend on Geth's account management. When a DApp wants to sign data (or a transaction), it can send the content to Clef, which will then provide the user with context and asks for permission to sign the content. If the users grants the signing request, Clef will send the signature back to the DApp. This setup allows a DApp to connect to a remote Ethereum node and send transactions that are locally signed. This can help in situations when a DApp is connected to an untrusted remote Ethereum node, because a local one is not available, not synchronised with the chain, or is a node that has no built-in (or limited) account management. Clef can run as a daemon on the same machine, off a usb-stick like [USB armory](https://inversepath.com/usbarmory), or even a separate VM in a [QubesOS](https://www.qubes-os.org/) type setup. Check out the * [CLI tutorial](tutorial.md) for some concrete examples on how Clef works. * [Setup docs](docs/setup.md) for infos on how to configure Clef on QubesOS or USB Armory. * [Data types](datatypes.md) for details on the communication messages between Clef and an external UI. ## Command line flags Clef accepts the following command line options: ``` COMMANDS: init Initialize the signer, generate secret storage attest Attest that a js-file is to be used setpw Store a credential for a keystore file delpw Remove a credential for a keystore file gendoc Generate documentation about json-rpc format help Shows a list of commands or help for one command GLOBAL OPTIONS: --loglevel value log level to emit to the screen (default: 4) --keystore value Directory for the keystore (default: "$HOME/.ethereum/keystore") --configdir value Directory for Clef configuration (default: "$HOME/.clef") --chainid value Chain id to use for signing (1=mainnet, 3=Ropsten, 4=Rinkeby, 5=Goerli) (default: 1) --lightkdf Reduce key-derivation RAM & CPU usage at some expense of KDF strength --nousb Disables monitoring for and managing USB hardware wallets --pcscdpath value Path to the smartcard daemon (pcscd) socket file (default: "/run/pcscd/pcscd.comm") --rpcaddr value HTTP-RPC server listening interface (default: "localhost") --rpcvhosts value Comma separated list of virtual hostnames from which to accept requests (server enforced). Accepts '*' wildcard. (default: "localhost") --ipcdisable Disable the IPC-RPC server --ipcpath Filename for IPC socket/pipe within the datadir (explicit paths escape it) --rpc Enable the HTTP-RPC server --rpcport value HTTP-RPC server listening port (default: 8550) --signersecret value A file containing the (encrypted) master seed to encrypt Clef data, e.g. keystore credentials and ruleset hash --4bytedb-custom value File used for writing new 4byte-identifiers submitted via API (default: "./4byte-custom.json") --auditlog value File used to emit audit logs. Set to "" to disable (default: "audit.log") --rules value Path to the rule file to auto-authorize requests with --stdio-ui Use STDIN/STDOUT as a channel for an external UI. This means that an STDIN/STDOUT is used for RPC-communication with a e.g. a graphical user interface, and can be used when Clef is started by an external process. --stdio-ui-test Mechanism to test interface between Clef and UI. Requires 'stdio-ui'. --advanced If enabled, issues warnings instead of rejections for suspicious requests. Default off --help, -h show help --version, -v print the version ``` Example: ``` $ clef -keystore /my/keystore -chainid 4 ``` ## Security model The security model of Clef is as follows: * One critical component (the Clef binary / daemon) is responsible for handling cryptographic operations: signing, private keys, encryption/decryption of keystore files. * Clef has a well-defined 'external' API. * The 'external' API is considered UNTRUSTED. * Clef also communicates with whatever process that invoked the binary, via stdin/stdout. * This channel is considered 'trusted'. Over this channel, approvals and passwords are communicated. The general flow for signing a transaction using e.g. Geth is as follows:  In this case, `geth` would be started with `--signer http://localhost:8550` and would relay requests to `eth.sendTransaction`. ## TODOs Some snags and todos * [ ] Clef should take a startup param "--no-change", for UIs that do not contain the capability to perform changes to things, only approve/deny. Such a UI should be able to start the signer in a more secure mode by telling it that it only wants approve/deny capabilities. * [x] It would be nice if Clef could collect new 4byte-id:s/method selectors, and have a secondary database for those (`4byte_custom.json`). Users could then (optionally) submit their collections for inclusion upstream. * [ ] It should be possible to configure Clef to check if an account is indeed known to it, before passing on to the UI. The reason it currently does not, is that it would make it possible to enumerate accounts if it immediately returned "unknown account" (side channel attack). * [x] It should be possible to configure Clef to auto-allow listing (certain) accounts, instead of asking every time. * [x] Done Upon startup, Clef should spit out some info to the caller (particularly important when executed in `stdio-ui`-mode), invoking methods with the following info: * [x] Version info about the signer * [x] Address of API (HTTP/IPC) * [ ] List of known accounts * [ ] Have a default timeout on signing operations, so that if the user has not answered within e.g. 60 seconds, the request is rejected. * [ ] `account_signRawTransaction` * [ ] `account_bulkSignTransactions([] transactions)` should * only exist if enabled via config/flag * only allow non-data-sending transactions * all txs must use the same `from`-account * let the user confirm, showing * the total amount * the number of unique recipients * Geth todos - The signer should pass the `Origin` header as call-info to the UI. As of right now, the way that info about the request is put together is a bit of a hack into the HTTP server. This could probably be greatly improved. - Relay: Geth should be started in `geth --signer localhost:8550`. - Currently, the Geth APIs use `common.Address` in the arguments to transaction submission (e.g `to` field). This type is 20 `bytes`, and is incapable of carrying checksum information. The signer uses `common.MixedcaseAddress`, which retains the original input. - The Geth API should switch to use the same type, and relay `to`-account verbatim to the external API. * [x] Storage * [x] An encrypted key-value storage should be implemented. * See [rules.md](rules.md) for more info about this. * Another potential thing to introduce is pairing. * To prevent spurious requests which users just accept, implement a way to "pair" the caller with the signer (external API). * Thus Geth/cpp would cryptographically handshake and afterwards the caller would be allowed to make signing requests. * This feature would make the addition of rules less dangerous. * Wallets / accounts. Add API methods for wallets. ## Communication ### External API Clef listens to HTTP requests on `rpcaddr`:`rpcport` (or to IPC on `ipcpath`), with the same JSON-RPC standard as Geth. The messages are expected to be [JSON-RPC 2.0 standard](https://www.jsonrpc.org/specification). Some of these call can require user interaction. Clients must be aware that responses may be delayed significantly or may never be received if a users decides to ignore the confirm