mirror of https://github.com/ethereum/go-ethereum
documentation about clef (#19383)
Martin Holst Swende
6 years ago
committed by
GitHub
parent
7539bd1d5b
commit
ab26ca1167
@ -0,0 +1,300 @@ |
||||
Clef |
||||
=== |
||||
_A reasonably secure wallet_ |
||||
|
||||
Goal: Accommodate arbitrary high requirements for security (through _isolation_ and _separation_), while still providing _usability_. |
||||
|
||||
Clef can be used to sign transactions and data and is meant as a replacement for geth's account management. |
||||
This allows DApps not to depend on geth's account management. When a DApp wants to sign data it can send the data to |
||||
the signer, the signer will then provide the user with context and asks the user for permission to sign the data. If |
||||
the users grants the signing request the signer 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 a remote node because a local Ethereum node is not available, not |
||||
synchronised with the chain or a particular Ethereum node that has no built-in (or limited) account management. |
||||
|
||||
Clef can run as a daemon on the same machine, or off a usb-stick like [usb armory](https://inversepath.com/usbarmory), |
||||
or a separate VM in a [QubesOS](https://www.qubes-os.org/) type os setup. |
||||
|
||||
|
||||
## More info |
||||
|
||||
Check out |
||||
|
||||
* the [tutorial](Tutorial.md) for some concrete examples on how the signer works. |
||||
* the [setup docs](Setup.md) for some information on how to configure it to work on QubesOS or USBArmory. |
||||
* more info about [rules](Rules.md) |
||||
* the [data types](datatypes.md) for detailed information on the json types used in the communication between |
||||
clef and an external UI |
||||
|
||||
## Security model |
||||
|
||||
The security model of the signer is as follows: |
||||
|
||||
* One critical binary is responsible for all cryptographic ops. |
||||
* The signer has a well-defined 'external' API - **UNTRUSTED**. |
||||
* The signer also has bidirectional APIs with whoever invoked it, via stdin/stdout -- considered **TRUSTED**. |
||||
* `clef` exposes API for the UI to consume, |
||||
* `ui` exposes API for `clef` to consume |
||||
|
||||
|
||||
The basic premise being, |
||||
|
||||
* A small(ish) binary without dependencies, |
||||
* that is deployed on a trusted (secure) machine, |
||||
* which serves untrusted requests, |
||||
* in a hostile (network) environment |
||||
|
||||
|
||||
The general flow for signing a transaction using e.g. geth is as follows: |
||||
|
||||
 |
||||
|
||||
|
||||
Clef relies on __sign-what-you-see__. To provide as much context as possible, |
||||
|
||||
- It parses calldata against 4byte database of method signatures. |
||||
- It alerts the user about the origin of the request (ip, `user-agent`,`transport`, `Origin`) |
||||
|
||||
|
||||
# Setup scenarios |
||||
|
||||
One setup scenario is to use virtualization, e.g. within QubesOS, where to |
||||
Clef is deployed on a non-networked machine (`ethvault` below) |
||||
|
||||
 |
||||
|
||||
|
||||
Another option is to deploy Clef on a separate physical device, e.g. USB Armory, |
||||
and access the CLI-UI via SSH on the interface provided by the USB ethernet |
||||
adapter, and expose HTTP interface via tunneling. |
||||
|
||||
 |
||||
|
||||
|
||||
## Multi-user setup |
||||
|
||||
Clef can also be used in a situation where several people need to make transactions, |
||||
and some other person (finance) does approval. |
||||
|
||||
|
||||
## Architecture |
||||
|
||||
Clef is divided into two parts |
||||
|
||||
- Clef |
||||
- UI |
||||
|
||||
Clef has a CLI natively, but a more refined UI can start `clef` in _standard-input-output-IO mode_. |
||||
|
||||
--- |
||||
|
||||
Clef _native_ CLI user interface example: |
||||
``` |
||||
--------- Transaction request------------- |
||||
to: 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 |
||||
from: 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 [chksum ok] |
||||
value: 1 wei |
||||
gas: 0x1 (1) |
||||
gasprice: 1 wei |
||||
nonce: 0x1 (1) |
||||
|
||||
Request context: |
||||
127.0.0.1:59870 -> HTTP/1.1 -> localhost:8550 |
||||
|
||||
Additional HTTP header data, provided by the external caller: |
||||
User-Agent: Go-http-client/1.1 |
||||
Origin: |
||||
------------------------------------------- |
||||
Approve? [y/N]: |
||||
> y |
||||
Enter password to approve: |
||||
``` |
||||
|
||||
`clef` will invoke API-methods on the UI whenever an action is required. |
||||
|
||||
- `ui_ApproveTx` |
||||
- `ui_ApproveListing` |
||||
- ... |
||||
|
||||
This is called the `internal api`, or `ui-api`. |
||||
|
||||
 |
||||
|
||||
 |
||||
|
||||
### Rules |
||||
|
||||
Historically, a user who wanted an easy way to sign transactions repeatedly, would |
||||
use some variant of `personal.unlock`. That is a very insecure way of managing |
||||
accounts, and is not present in Clef. Clef instead implements Rules, which can |
||||
be customized to provide the same type of ease of use, but with much higher |
||||
security-guarantees. |
||||
|
||||
Examples of rules: |
||||
|
||||
* "I want to allow transactions with contract `CasinoDapp`, with up to `0.05 ether` in value to maximum `1 ether` per 24h period" |
||||
* "I want to allow transaction to contract `EthAlarmClock` with `data`=`0xdeadbeef`, if `value=0`, `gas < 44k` and `gasPrice < 40Gwei`" |
||||
|
||||
Clef comes with a Javascript VM which can evaluate a ruleset file. The ruleset |
||||
file has access to the same interface that an external UI would have. |
||||
|
||||
#### Example 1: Allow listing |
||||
|
||||
```javascript |
||||
function ApproveListing(){ |
||||
return "Approve" |
||||
} |
||||
``` |
||||
|
||||
--- |
||||
|
||||
#### Example 2: Allow destination |
||||
|
||||
```javascript |
||||
function ApproveTx(r){ |
||||
var ok = "0x0000000000000000000000000000000000001337"; |
||||
var nope = "0x000000000000000000000000000000000000dead"; |
||||
if(r.transaction.from.toLowerCase()== ok){ |
||||
return "Approve" |
||||
} |
||||
if(r.transaction.from.toLowerCase()==nope){ |
||||
return "Reject" |
||||
} |
||||
// Otherwise goes to manual processing |
||||
} |
||||
``` |
||||
|
||||
--- |
||||
|
||||
#### Example 3: a rate-limited window |
||||
|
||||
|
||||
```javascript |
||||
function big(str){ |
||||
if(str.slice(0,2) == "0x"){ return new BigNumber(str.slice(2),16)} |
||||
return new BigNumber(str) |
||||
} |
||||
|
||||
// Time window: 1 week |
||||
var window = 1000* 3600*24*7; |
||||
// Limit : 1 ether |
||||
var limit = new BigNumber("1e18"); |
||||
|
||||
function isLimitOk(transaction){ |
||||
var value = big(transaction.value) |
||||
// Start of our window function |
||||
var windowstart = new Date().getTime() - window; |
||||
|
||||
var txs = []; |
||||
var stored = storage.Get('txs'); |
||||
|
||||
if(stored != ""){ |
||||
txs = JSON.parse(stored) |
||||
} |
||||
// First, remove all that have passed out of the time-window |
||||
var newtxs = txs.filter(function(tx){return tx.tstamp > windowstart}); |
||||
console.log(txs, newtxs.length); |
||||
// Secondly, aggregate the current sum |
||||
sum = new BigNumber(0) |
||||
sum = newtxs.reduce(function(agg, tx){ return big(tx.value).plus(agg)}, sum); |
||||
// Would we exceed weekly limit ? |
||||
return sum.plus(value).lt(limit) |
||||
|
||||
} |
||||
function ApproveTx(r){ |
||||
if (isLimitOk(r.transaction)){ |
||||
return "Approve" |
||||
} |
||||
return "Nope" |
||||
} |
||||
|
||||
/** |
||||
* OnApprovedTx(str) is called when a transaction has been approved and signed. |
||||
*/ |
||||
function OnApprovedTx(resp){ |
||||
var value = big(resp.tx.value) |
||||
var txs = [] |
||||
// Load stored transactions |
||||
var stored = storage.Get('txs'); |
||||
if(stored != ""){ |
||||
txs = JSON.parse(stored) |
||||
} |
||||
// Add this to the storage |
||||
txs.push({tstamp: new Date().getTime(), value: value}); |
||||
storage.Put("txs", JSON.stringify(txs)); |
||||
} |
||||
|
||||
``` |
||||
|
||||
### A note about passwords... |
||||
|
||||
In normal mode, passwords are supplied via UI. |
||||
In order to use rules, keystore passwords must be stored in `clef`. Clef uses an encrypted container to store |
||||
|
||||
- Keystore passwords |
||||
- SHA256 hash of ruleset file |
||||
- Key/value pairs accessible to the Javascript ruleset implementation |
||||
- This, in turn, enables the ruleset files to save data and thus implement |
||||
things like the rate-limited window. |
||||
|
||||
--- |
||||
## External UIs |
||||
|
||||
The `clef` daemon can be wrapped by an external process, which can then take |
||||
the part of a UI. |
||||
|
||||
 |
||||
QT UI on Ubuntu |
||||
 |
||||
|
||||
GTK UI on Qubes |
||||
|
||||
 |
||||
|
||||
### Rules for UI apis |
||||
|
||||
A UI should conform to the following rules. |
||||
|
||||
* A UI MUST NOT load any external resources that were not embedded/part of the UI package. |
||||
* For example, not load icons, stylesheets from the internet |
||||
* Not load files from the filesystem, unless they reside in the same local directory (e.g. config files) |
||||
* A Graphical UI MUST show the blocky-identicon for ethereum addresses. |
||||
* A UI MUST warn display approproate warning if the destination-account is formatted with invalid checksum. |
||||
* A UI MUST NOT open any ports or services |
||||
* The signer opens the public port |
||||
* A UI SHOULD verify the permissions on the signer binary, and refuse to execute or warn if permissions allow non-user write. |
||||
* A UI SHOULD inform the user about the `SHA256` or `MD5` hash of the binary being executed |
||||
* A UI SHOULD NOT maintain a secondary storage of data, e.g. list of accounts |
||||
* The signer provides accounts |
||||
* A UI SHOULD, to the best extent possible, use static linking / bundling, so that required libraries are bundled |
||||
along with the UI. |
||||
|
||||
|
||||
### UI Implementations |
||||
|
||||
There are a couple of implementation for a UI. We'll try to keep this list up to date. Currently, none of these are finished. |
||||
|
||||
| Name | Repo | UI type| No external resources| Blocky support| Verifies permissions | Hash information | No secondary storage | Statically linked| Can modify parameters| |
||||
| ---- | ---- | -------| ---- | ---- | ---- |---- | ---- | ---- | ---- | |
||||
| QtSigner| https://github.com/holiman/qtsigner/| Python3/QT-based| :+1:| :+1:| :+1:| :+1:| :+1:| :x: | :+1: (partially)| |
||||
| GtkSigner| https://github.com/holiman/gtksigner| Python3/GTK-based| :+1:| :x:| :x:| :+1:| :+1:| :x: | :x: | |
||||
| Frame | https://github.com/floating/frame/commits/go-signer| Electron-based| :x:| :x:| :x:| :x:| ?| :x: | :x: | |
||||
| Clef UI| https://github.com/ethereum/clef-ui| Golang/QT-based| :+1:| :+1:| :x:| :+1:| :+1:| :x: | :+1: (approve tx only)| |
||||
|
||||
|
||||
## Geth integration |
||||
|
||||
The `--signer` CLI option for `geth` means that `geth` can use `clef` as a |
||||
backend signer. |
||||
|
||||
Although some things, like `personal.unlock` disappears, `clef` has otherwise |
||||
a corresponding (or exceeding) feature set: |
||||
|
||||
* Full set of options for hardware interaction (derivation etc) via UI |
||||
* EIP 191/712 - signing typed data |
||||
|
||||
Clef can even sign Clique headers in a private network |
||||
 |
||||
|
||||
|
||||
@ -0,0 +1,236 @@ |
||||
# Rules |
||||
|
||||
The `signer` binary contains a ruleset engine, implemented with [OttoVM](https://github.com/robertkrimen/otto) |
||||
|
||||
It enables usecases like the following: |
||||
|
||||
* I want to auto-approve transactions with contract `CasinoDapp`, with up to `0.05 ether` in value to maximum `1 ether` per 24h period |
||||
* I want to auto-approve transaction to contract `EthAlarmClock` with `data`=`0xdeadbeef`, if `value=0`, `gas < 44k` and `gasPrice < 40Gwei` |
||||
|
||||
The two main features that are required for this to work well are; |
||||
|
||||
1. Rule Implementation: how to create, manage and interpret rules in a flexible but secure manner |
||||
2. Credential managements and credentials; how to provide auto-unlock without exposing keys unnecessarily. |
||||
|
||||
The section below deals with both of them |
||||
|
||||
## Rule Implementation |
||||
|
||||
A ruleset file is implemented as a `js` file. Under the hood, the ruleset-engine is a `SignerUI`, implementing the same methods as the `json-rpc` methods |
||||
defined in the UI protocol. Example: |
||||
|
||||
```javascript |
||||
|
||||
function asBig(str){ |
||||
if(str.slice(0,2) == "0x"){ return new BigNumber(str.slice(2),16)} |
||||
return new BigNumber(str) |
||||
} |
||||
|
||||
// Approve transactions to a certain contract if value is below a certain limit |
||||
function ApproveTx(req){ |
||||
|
||||
var limit = big.Newint("0xb1a2bc2ec50000") |
||||
var value = asBig(req.transaction.value); |
||||
|
||||
if(req.transaction.to.toLowerCase()=="0xae967917c465db8578ca9024c205720b1a3651a9") |
||||
&& value.lt(limit) ){ |
||||
return "Approve" |
||||
} |
||||
// If we return "Reject", it will be rejected. |
||||
// By not returning anything, it will be passed to the next UI, for manual processing |
||||
} |
||||
|
||||
//Approve listings if request made from IPC |
||||
function ApproveListing(req){ |
||||
if (req.metadata.scheme == "ipc"){ return "Approve"} |
||||
} |
||||
|
||||
``` |
||||
|
||||
Whenever the external API is called (and the ruleset is enabled), the `signer` calls the UI, which is an instance of a ruleset-engine. The ruleset-engine |
||||
invokes the corresponding method. In doing so, there are three possible outcomes: |
||||
|
||||
1. JS returns "Approve" |
||||
* Auto-approve request |
||||
2. JS returns "Reject" |
||||
* Auto-reject request |
||||
3. Error occurs, or something else is returned |
||||
* Pass on to `next` ui: the regular UI channel. |
||||
|
||||
A more advanced example can be found below, "Example 1: ruleset for a rate-limited window", using `storage` to `Put` and `Get` `string`s by key. |
||||
|
||||
* At the time of writing, storage only exists as an ephemeral unencrypted implementation, to be used during testing. |
||||
|
||||
### Things to note |
||||
|
||||
The Otto vm has a few [caveats](https://github.com/robertkrimen/otto): |
||||
|
||||
* "use strict" will parse, but does nothing. |
||||
* The regular expression engine (re2/regexp) is not fully compatible with the ECMA5 specification. |
||||
* Otto targets ES5. ES6 features (eg: Typed Arrays) are not supported. |
||||
|
||||
Additionally, a few more have been added |
||||
|
||||
* The rule execution cannot load external javascript files. |
||||
* The only preloaded libary is [`bignumber.js`](https://github.com/MikeMcl/bignumber.js) version `2.0.3`. This one is fairly old, and is not aligned with the documentation at the github repository. |
||||
* Each invocation is made in a fresh virtual machine. This means that you cannot store data in global variables between invocations. This is a deliberate choice -- if you want to store data, use the disk-backed `storage`, since rules should not rely on ephemeral data. |
||||
* Javascript API parameters are _always_ an object. This is also a design choice, to ensure that parameters are accessed by _key_ and not by order. This is to prevent mistakes due to missing parameters or parameter changes. |
||||
* The JS engine has access to `storage` and `console`. |
||||
|
||||
#### Security considerations |
||||
|
||||
##### Security of ruleset |
||||
|
||||
Some security precautions can be made, such as: |
||||
|
||||
* Never load `ruleset.js` unless the file is `readonly` (`r-??-??-?`). If the user wishes to modify the ruleset, he must make it writeable and then set back to readonly. |
||||
* This is to prevent attacks where files are dropped on the users disk. |
||||
* Since we're going to have to have some form of secure storage (not defined in this section), we could also store the `sha3` of the `ruleset.js` file in there. |
||||
* If the user wishes to modify the ruleset, he'd then have to perform e.g. `signer --attest /path/to/ruleset --credential <creds>` |
||||
|
||||
##### Security of implementation |
||||
|
||||
The drawbacks of this very flexible solution is that the `signer` needs to contain a javascript engine. This is pretty simple to implement, since it's already |
||||
implemented for `geth`. There are no known security vulnerabilities in, nor have we had any security-problems with it so far. |
||||
|
||||
The javascript engine would be an added attack surface; but if the validation of `rulesets` is made good (with hash-based attestation), the actual javascript cannot be considered |
||||
an attack surface -- if an attacker can control the ruleset, a much simpler attack would be to implement an "always-approve" rule instead of exploiting the js vm. The only benefit |
||||
to be gained from attacking the actual `signer` process from the `js` side would be if it could somehow extract cryptographic keys from memory. |
||||
|
||||
##### Security in usability |
||||
|
||||
Javascript is flexible, but also easy to get wrong, especially when users assume that `js` can handle large integers natively. Typical errors |
||||
include trying to multiply `gasCost` with `gas` without using `bigint`:s. |
||||
|
||||
It's unclear whether any other DSL could be more secure; since there's always the possibility of erroneously implementing a rule. |
||||
|
||||
|
||||
## Credential management |
||||
|
||||
The ability to auto-approve transaction means that the signer needs to have necessary credentials to decrypt keyfiles. These passwords are hereafter called `ksp` (keystore pass). |
||||
|
||||
### Example implementation |
||||
|
||||
Upon startup of the signer, the signer is given a switch: `--seed <path/to/masterseed>` |
||||
The `seed` contains a blob of bytes, which is the master seed for the `signer`. |
||||
|
||||
The `signer` uses the `seed` to: |
||||
|
||||
* Generate the `path` where the settings are stored. |
||||
* `./settings/1df094eb-c2b1-4689-90dd-790046d38025/vault.dat` |
||||
* `./settings/1df094eb-c2b1-4689-90dd-790046d38025/rules.js` |
||||
* Generate the encryption password for `vault.dat`. |
||||
|
||||
The `vault.dat` would be an encrypted container storing the following information: |
||||
|
||||
* `ksp` entries |
||||
* `sha256` hash of `rules.js` |
||||
* Information about pair:ed callers (not yet specified) |
||||
|
||||
### Security considerations |
||||
|
||||
This would leave it up to the user to ensure that the `path/to/masterseed` is handled in a secure way. It's difficult to get around this, although one could |
||||
imagine leveraging OS-level keychains where supported. The setup is however in general similar to how ssh-keys are stored in `.ssh/`. |
||||
|
||||
|
||||
# Implementation status |
||||
|
||||
This is now implemented (with ephemeral non-encrypted storage for now, so not yet enabled). |
||||
|
||||
## Example 1: ruleset for a rate-limited window |
||||
|
||||
|
||||
```javascript |
||||
|
||||
function big(str){ |
||||
if(str.slice(0,2) == "0x"){ return new BigNumber(str.slice(2),16)} |
||||
return new BigNumber(str) |
||||
} |
||||
|
||||
// Time window: 1 week |
||||
var window = 1000* 3600*24*7; |
||||
|
||||
// Limit : 1 ether |
||||
var limit = new BigNumber("1e18"); |
||||
|
||||
function isLimitOk(transaction){ |
||||
var value = big(transaction.value) |
||||
// Start of our window function |
||||
var windowstart = new Date().getTime() - window; |
||||
|
||||
var txs = []; |
||||
var stored = storage.Get('txs'); |
||||
|
||||
if(stored != ""){ |
||||
txs = JSON.parse(stored) |
||||
} |
||||
// First, remove all that have passed out of the time-window |
||||
var newtxs = txs.filter(function(tx){return tx.tstamp > windowstart}); |
||||
console.log(txs, newtxs.length); |
||||
|
||||
// Secondly, aggregate the current sum |
||||
sum = new BigNumber(0) |
||||
|
||||
sum = newtxs.reduce(function(agg, tx){ return big(tx.value).plus(agg)}, sum); |
||||
console.log("ApproveTx > Sum so far", sum); |
||||
console.log("ApproveTx > Requested", value.toNumber()); |
||||
|
||||
// Would we exceed weekly limit ? |
||||
return sum.plus(value).lt(limit) |
||||
|
||||
} |
||||
function ApproveTx(r){ |
||||
if (isLimitOk(r.transaction)){ |
||||
return "Approve" |
||||
} |
||||
return "Nope" |
||||
} |
||||
|
||||
/** |
||||
* OnApprovedTx(str) is called when a transaction has been approved and signed. The parameter |
||||
* 'response_str' contains the return value that will be sent to the external caller. |
||||
* The return value from this method is ignore - the reason for having this callback is to allow the |
||||
* ruleset to keep track of approved transactions. |
||||
* |
||||
* When implementing rate-limited rules, this callback should be used. |
||||
* If a rule responds with neither 'Approve' nor 'Reject' - the tx goes to manual processing. If the user |
||||
* then accepts the transaction, this method will be called. |
||||
* |
||||
* TLDR; Use this method to keep track of signed transactions, instead of using the data in ApproveTx. |
||||
*/ |
||||
function OnApprovedTx(resp){ |
||||
var value = big(resp.tx.value) |
||||
var txs = [] |
||||
// Load stored transactions |
||||
var stored = storage.Get('txs'); |
||||
if(stored != ""){ |
||||
txs = JSON.parse(stored) |
||||
} |
||||
// Add this to the storage |
||||
txs.push({tstamp: new Date().getTime(), value: value}); |
||||
storage.Put("txs", JSON.stringify(txs)); |
||||
} |
||||
|
||||
``` |
||||
|
||||
## Example 2: allow destination |
||||
|
||||
```javascript |
||||
|
||||
function ApproveTx(r){ |
||||
if(r.transaction.from.toLowerCase()=="0x0000000000000000000000000000000000001337"){ return "Approve"} |
||||
if(r.transaction.from.toLowerCase()=="0x000000000000000000000000000000000000dead"){ return "Reject"} |
||||
// Otherwise goes to manual processing |
||||
} |
||||
|
||||
``` |
||||
|
||||
## Example 3: Allow listing |
||||
|
||||
```javascript |
||||
|
||||
function ApproveListing(){ |
||||
return "Approve" |
||||
} |
||||
|
||||
``` |
||||
@ -0,0 +1,198 @@ |
||||
# Setting up Clef |
||||
|
||||
This document describes how Clef can be used in a more secure manner than executing it from your everyday laptop, |
||||
in order to ensure that the keys remain safe in the event that your computer should get compromised. |
||||
|
||||
## Qubes OS |
||||
|
||||
|
||||
### Background |
||||
|
||||
The Qubes operating system is based around virtual machines (qubes), where a set of virtual machines are configured, typically for |
||||
different purposes such as: |
||||
|
||||
- personal |
||||
- Your personal email, browsing etc |
||||
- work |
||||
- Work email etc |
||||
- vault |
||||
- a VM without network access, where gpg-keys and/or keepass credentials are stored. |
||||
|
||||
A couple of dedicated virtual machines handle externalities: |
||||
|
||||
- sys-net provides networking to all other (network-enabled) machines |
||||
- sys-firewall handles firewall rules |
||||
- sys-usb handles USB devices, and can map usb-devices to certain qubes. |
||||
|
||||
The goal of this document is to describe how we can set up clef to provide secure transaction |
||||
signing from a `vault` vm, to another networked qube which runs Dapps. |
||||
|
||||
### Setup |
||||
|
||||
There are two ways that this can be achieved: integrated via Qubes or integrated via networking. |
||||
|
||||
|
||||
#### 1. Qubes Integrated |
||||
|
||||
Qubes provdes a facility for inter-qubes communication via `qrexec`. A qube can request to make a cross-qube RPC request |
||||
to another qube. The OS then asks the user if the call is permitted. |
||||
|
||||
 |
||||
|
||||
A policy-file can be created to allow such interaction. On the `target` domain, a service is invoked which can read the |
||||
`stdin` from the `client` qube. |
||||
|
||||
This is how [Split GPG](https://www.qubes-os.org/doc/split-gpg/) is implemented. We can set up Clef the same way: |
||||
|
||||
##### Server |
||||
|
||||
 |
||||
|
||||
On the `target` qubes, we need to define the rpc service. |
||||
|
||||
[qubes.Clefsign](qubes/qubes.Clefsign): |
||||
|
||||
```bash |
||||
#!/bin/bash |
||||
|
||||
SIGNER_BIN="/home/user/tools/clef/clef" |
||||
SIGNER_CMD="/home/user/tools/gtksigner/gtkui.py -s $SIGNER_BIN" |
||||
|
||||
# Start clef if not already started |
||||
if [ ! -S /home/user/.clef/clef.ipc ]; then |
||||
$SIGNER_CMD & |
||||
sleep 1 |
||||
fi |
||||
|
||||
# Should be started by now |
||||
if [ -S /home/user/.clef/clef.ipc ]; then |
||||
# Post incoming request to HTTP channel |
||||
curl -H "Content-Type: application/json" -X POST -d @- http://localhost:8550 2>/dev/null |
||||
fi |
||||
|
||||
``` |
||||
This RPC service is not complete (see notes about HTTP headers below), but works as a proof-of-concept. |
||||
It will forward the data received on `stdin` (forwarded by the OS) to Clef's HTTP channel. |
||||
|
||||
It would have been possible to send data directly to the `/home/user/.clef/.clef.ipc` |
||||
socket via e.g `nc -U /home/user/.clef/clef.ipc`, but the reason for sending the request |
||||
data over `HTTP` instead of `IPC` is that we want the ability to forward `HTTP` headers. |
||||
|
||||
To enable the service: |
||||
|
||||
``` bash |
||||
sudo cp qubes.Clefsign /etc/qubes-rpc/ |
||||
sudo chmod +x /etc/qubes-rpc/ qubes.Clefsign |
||||
``` |
||||
|
||||
This setup uses [gtksigner](https://github.com/holiman/gtksigner), which is a very minimal GTK-based UI that works well |
||||
with minimal requirements. |
||||
|
||||
##### Client |
||||
|
||||
|
||||
On the `client` qube, we need to create a listener which will receive the request from the Dapp, and proxy it. |
||||
|
||||
|
||||
[qubes-client.py](qubes/client/qubes-client.py): |
||||
|
||||
```python |
||||
|
||||
""" |
||||
This implements a dispatcher which listens to localhost:8550, and proxies |
||||
requests via qrexec to the service qubes.EthSign on a target domain |
||||
""" |
||||
|
||||
import http.server |
||||
import socketserver,subprocess |
||||
|
||||
PORT=8550 |
||||
TARGET_DOMAIN= 'debian-work' |
||||
|
||||
class Dispatcher(http.server.BaseHTTPRequestHandler): |
||||
def do_POST(self): |
||||
post_data = self.rfile.read(int(self.headers['Content-Length'])) |
||||
p = subprocess.Popen(['/usr/bin/qrexec-client-vm',TARGET_DOMAIN,'qubes.Clefsign'],stdin=subprocess.PIPE, stdout=subprocess.PIPE) |
||||
output = p.communicate(post_data)[0] |
||||
self.wfile.write(output) |
||||
|
||||
|
||||
with socketserver.TCPServer(("",PORT), Dispatcher) as httpd: |
||||
print("Serving at port", PORT) |
||||
httpd.serve_forever() |
||||
|
||||
|
||||
``` |
||||
|
||||
#### Testing |
||||
|
||||
To test the flow, if we have set up `debian-work` as the `target`, we can do |
||||
|
||||
```bash |
||||
$ cat newaccnt.json |
||||
{ "id": 0, "jsonrpc": "2.0","method": "account_new","params": []} |
||||
|
||||
$ cat newaccnt.json| qrexec-client-vm debian-work qubes.Clefsign |
||||
``` |
||||
|
||||
This should pop up first a dialog to allow the IPC call: |
||||
|
||||
 |
||||
|
||||
Followed by a GTK-dialog to approve the operation |
||||
|
||||
 |
||||
|
||||
To test the full flow, we use the client wrapper. Start it on the `client` qube: |
||||
``` |
||||
[user@work qubes]$ python3 qubes-client.py |
||||
``` |
||||
|
||||
Make the request over http (`client` qube): |
||||
``` |
||||
[user@work clef]$ cat newaccnt.json | curl -X POST -d @- http://localhost:8550 |
||||
``` |
||||
And it should show the same popups again. |
||||
|
||||
##### Pros and cons |
||||
|
||||
The benefits of this setup are: |
||||
|
||||
- This is the qubes-os intended model for inter-qube communication, |
||||
- and thus benefits from qubes-os dialogs and policies for user approval |
||||
|
||||
However, it comes with a couple of drawbacks: |
||||
|
||||
- The `qubes-gpg-client` must forward the http request via RPC to the `target` qube. When doing so, the proxy |
||||
will either drop important headers, or replace them. |
||||
- The `Host` header is most likely `localhost` |
||||
- The `Origin` header must be forwarded |
||||
- Information about the remote ip must be added as a `X-Forwarded-For`. However, Clef cannot always trust an `XFF` header, |
||||
since malicious clients may lie about `XFF` in order to fool the http server into believing it comes from another address. |
||||
- Even with a policy in place to allow rpc-calls between `caller` and `target`, there will be several popups: |
||||
- One qubes-specific where the user specifies the `target` vm |
||||
- One clef-specific to approve the transaction |
||||
|
||||
|
||||
#### 2. Network integrated |
||||
|
||||
The second way to set up Clef on a qubes system is to allow networking, and have Clef listen to a port which is accessible |
||||
form other qubes. |
||||
|
||||
 |
||||
|
||||
|
||||
|
||||
|
||||
## USBArmory |
||||
|
||||
The [USB armory](https://inversepath.com/usbarmory) is an open source hardware design with an 800 Mhz ARM processor. It is a pocket-size |
||||
computer. When inserted into a laptop, it identifies itself as a USB network interface, basically adding another network |
||||
to your computer. Over this new network interface, you can SSH into the device. |
||||
|
||||
Running Clef off a USB armory means that you can use the armory as a very versatile offline computer, which only |
||||
ever connects to a local network between your computer and the device itself. |
||||
|
||||
Needless to say, the while this model should be fairly secure against remote attacks, an attacker with physical access |
||||
to the USB Armory would trivially be able to extract the contents of the device filesystem. |
||||
|
||||
@ -0,0 +1,211 @@ |
||||
## Initializing the signer |
||||
|
||||
First, initialize the master seed. |
||||
|
||||
```text |
||||
#./signer init |
||||
|
||||
WARNING! |
||||
|
||||
The signer is alpha software, and not yet publically released. This software has _not_ been audited, and there |
||||
are no guarantees about the workings of this software. It may contain severe flaws. You should not use this software |
||||
unless you agree to take full responsibility for doing so, and know what you are doing. |
||||
|
||||
TLDR; THIS IS NOT PRODUCTION-READY SOFTWARE! |
||||
|
||||
|
||||
Enter 'ok' to proceed: |
||||
>ok |
||||
A master seed has been generated into /home/martin/.signer/secrets.dat |
||||
|
||||
This is required to be able to store credentials, such as : |
||||
* Passwords for keystores (used by rule engine) |
||||
* Storage for javascript rules |
||||
* Hash of rule-file |
||||
|
||||
You should treat that file with utmost secrecy, and make a backup of it. |
||||
NOTE: This file does not contain your accounts. Those need to be backed up separately! |
||||
``` |
||||
|
||||
(for readability purposes, we'll remove the WARNING printout in the rest of this document) |
||||
|
||||
## Creating rules |
||||
|
||||
Now, you can create a rule-file. Note that it is not mandatory to use predefined rules, but it's really handy. |
||||
|
||||
```javascript |
||||
function ApproveListing(){ |
||||
return "Approve" |
||||
} |
||||
``` |
||||
|
||||
Get the `sha256` hash. If you have openssl, you can do `openssl sha256 rules.js`... |
||||
```text |
||||
#sha256sum rules.js |
||||
6c21d1737429d6d4f2e55146da0797782f3c0a0355227f19d702df377c165d72 rules.js |
||||
``` |
||||
...now `attest` the file... |
||||
```text |
||||
#./signer attest 6c21d1737429d6d4f2e55146da0797782f3c0a0355227f19d702df377c165d72 |
||||
|
||||
INFO [02-21|12:14:38] Ruleset attestation updated sha256=6c21d1737429d6d4f2e55146da0797782f3c0a0355227f19d702df377c165d72 |
||||
``` |
||||
|
||||
...and (this is required only for non-production versions) load a mock-up `4byte.json` by copying the file from the source to your current working directory: |
||||
```text |
||||
#cp $GOPATH/src/github.com/ethereum/go-ethereum/cmd/clef/4byte.json $PWD |
||||
``` |
||||
|
||||
At this point, we can start the signer with the rule-file: |
||||
```text |
||||
#./signer --rules rules.js --rpc |
||||
|
||||
INFO [09-25|20:28:11.866] Using CLI as UI-channel |
||||
INFO [09-25|20:28:11.876] Loaded 4byte db signatures=5509 file=./4byte.json |
||||
INFO [09-25|20:28:11.877] Rule engine configured file=./rules.js |
||||
DEBUG[09-25|20:28:11.877] FS scan times list=100.781µs set=13.253µs diff=5.761µs |
||||
DEBUG[09-25|20:28:11.884] Ledger support enabled |
||||
DEBUG[09-25|20:28:11.888] Trezor support enabled |
||||
INFO [09-25|20:28:11.888] Audit logs configured file=audit.log |
||||
DEBUG[09-25|20:28:11.888] HTTP registered namespace=account |
||||
INFO [09-25|20:28:11.890] HTTP endpoint opened url=http://localhost:8550 |
||||
DEBUG[09-25|20:28:11.890] IPC registered namespace=account |
||||
INFO [09-25|20:28:11.890] IPC endpoint opened url=<nil> |
||||
------- Signer info ------- |
||||
* extapi_version : 2.0.0 |
||||
* intapi_version : 2.0.0 |
||||
* extapi_http : http://localhost:8550 |
||||
* extapi_ipc : <nil> |
||||
``` |
||||
|
||||
Any list-requests will now be auto-approved by our rule-file. |
||||
|
||||
## Under the hood |
||||
|
||||
While doing the operations above, these files have been created: |
||||
|
||||
```text |
||||
#ls -laR ~/.signer/ |
||||
/home/martin/.signer/: |
||||
total 16 |
||||
drwx------ 3 martin martin 4096 feb 21 12:14 . |
||||
drwxr-xr-x 71 martin martin 4096 feb 21 12:12 .. |
||||
drwx------ 2 martin martin 4096 feb 21 12:14 43f73718397aa54d1b22 |
||||
-rwx------ 1 martin martin 256 feb 21 12:12 secrets.dat |
||||
|
||||
/home/martin/.signer/43f73718397aa54d1b22: |
||||
total 12 |
||||
drwx------ 2 martin martin 4096 feb 21 12:14 . |
||||
drwx------ 3 martin martin 4096 feb 21 12:14 .. |
||||
-rw------- 1 martin martin 159 feb 21 12:14 config.json |
||||
|
||||
#cat /home/martin/.signer/43f73718397aa54d1b22/config.json |
||||
{"ruleset_sha256":{"iv":"6v4W4tfJxj3zZFbl","c":"6dt5RTDiTq93yh1qDEjpsat/tsKG7cb+vr3sza26IPL2fvsQ6ZoqFx++CPUa8yy6fD9Bbq41L01ehkKHTG3pOAeqTW6zc/+t0wv3AB6xPmU="}} |
||||
|
||||
``` |
||||
|
||||
In `~/.signer`, the `secrets.dat` file was created, containing the `master_seed`. |
||||
The `master_seed` was then used to derive a few other things: |
||||
|
||||
- `vault_location` : in this case `43f73718397aa54d1b22` . |
||||
- Thus, if you use a different `master_seed`, another `vault_location` will be used that does not conflict with each other. |
||||
- Example: `signer --signersecret /path/to/afile ...` |
||||
- `config.json` which is the encrypted key/value storage for configuration data, containing the key `ruleset_sha256`. |
||||
|
||||
|
||||
## Adding credentials |
||||
|
||||
In order to make more useful rules like signing transactions, the signer needs access to the passwords needed to unlock keystores. |
||||
|
||||
```text |
||||
#./signer addpw "0x694267f14675d7e1b9494fd8d72fefe1755710fa" "test_password" |
||||
|
||||
INFO [02-21|13:43:21] Credential store updated key=0x694267f14675d7e1b9494fd8d72fefe1755710fa |
||||
``` |
||||
## More advanced rules |
||||
|
||||
Now let's update the rules to make use of credentials: |
||||
|
||||
```javascript |
||||
function ApproveListing(){ |
||||
return "Approve" |
||||
} |
||||
function ApproveSignData(r){ |
||||
if( r.address.toLowerCase() == "0x694267f14675d7e1b9494fd8d72fefe1755710fa") |
||||
{ |
||||
if(r.message.indexOf("bazonk") >= 0){ |
||||
return "Approve" |
||||
} |
||||
return "Reject" |
||||
} |
||||
// Otherwise goes to manual processing |
||||
} |
||||
|
||||
``` |
||||
In this example: |
||||
* Any requests to sign data with the account `0x694...` will be |
||||
* auto-approved if the message contains with `bazonk` |
||||
* auto-rejected if it does not. |
||||
* Any other signing-requests will be passed along for manual approve/reject. |
||||
|
||||
_Note: make sure that `0x694...` is an account you have access to. You can create it either via the clef or the traditional account cli tool. If the latter was chosen, make sure both clef and geth use the same keystore by specifing `--keystore path/to/your/keystore` when running clef._ |
||||
|
||||
Attest the new file... |
||||
```text |
||||
#sha256sum rules.js |
||||
2a0cb661dacfc804b6e95d935d813fd17c0997a7170e4092ffbc34ca976acd9f rules.js |
||||
|
||||
#./signer attest 2a0cb661dacfc804b6e95d935d813fd17c0997a7170e4092ffbc34ca976acd9f |
||||
|
||||
INFO [02-21|14:36:30] Ruleset attestation updated sha256=2a0cb661dacfc804b6e95d935d813fd17c0997a7170e4092ffbc34ca976acd9f |
||||
``` |
||||
|
||||
And start the signer: |
||||
|
||||
``` |
||||
#./signer --rules rules.js --rpc |
||||
|
||||
INFO [09-25|21:02:16.450] Using CLI as UI-channel |
||||
INFO [09-25|21:02:16.466] Loaded 4byte db signatures=5509 file=./4byte.json |
||||
INFO [09-25|21:02:16.467] Rule engine configured file=./rules.js |
||||
DEBUG[09-25|21:02:16.468] FS scan times list=1.45262ms set=21.926µs diff=6.944µs |
||||
DEBUG[09-25|21:02:16.473] Ledger support enabled |
||||
DEBUG[09-25|21:02:16.475] Trezor support enabled |
||||
INFO [09-25|21:02:16.476] Audit logs configured file=audit.log |
||||
DEBUG[09-25|21:02:16.476] HTTP registered namespace=account |
||||
INFO [09-25|21:02:16.478] HTTP endpoint opened url=http://localhost:8550 |
||||
DEBUG[09-25|21:02:16.478] IPC registered namespace=account |
||||
INFO [09-25|21:02:16.478] IPC endpoint opened url=<nil> |
||||
------- Signer info ------- |
||||
* extapi_version : 2.0.0 |
||||
* intapi_version : 2.0.0 |
||||
* extapi_http : http://localhost:8550 |
||||
* extapi_ipc : <nil> |
||||
``` |
||||
|
||||
And then test signing, once with `bazonk` and once without: |
||||
|
||||
``` |
||||
#curl -H "Content-Type: application/json" -X POST --data "{\"jsonrpc\":\"2.0\",\"method\":\"account_sign\",\"params\":[\"0x694267f14675d7e1b9494fd8d72fefe1755710fa\",\"0x$(xxd -pu <<< ' bazonk baz gaz')\"],\"id\":67}" http://localhost:8550/ |
||||
{"jsonrpc":"2.0","id":67,"result":"0x93e6161840c3ae1efc26dc68dedab6e8fc233bb3fefa1b4645dbf6609b93dace160572ea4ab33240256bb6d3dadb60dcd9c515d6374d3cf614ee897408d41d541c"} |
||||
|
||||
#curl -H "Content-Type: application/json" -X POST --data "{\"jsonrpc\":\"2.0\",\"method\":\"account_sign\",\"params\":[\"0x694267f14675d7e1b9494fd8d72fefe1755710fa\",\"0x$(xxd -pu <<< ' bonk baz gaz')\"],\"id\":67}" http://localhost:8550/ |
||||
{"jsonrpc":"2.0","id":67,"error":{"code":-32000,"message":"Request denied"}} |
||||
|
||||
``` |
||||
|
||||
Meanwhile, in the signer output: |
||||
```text |
||||
INFO [02-21|14:42:41] Op approved |
||||
INFO [02-21|14:42:56] Op rejected |
||||
``` |
||||
|
||||
The signer also stores all traffic over the external API in a log file. The last 4 lines shows the two requests and their responses: |
||||
|
||||
```text |
||||
#tail -n 4 audit.log |
||||
t=2018-02-21T14:42:41+0100 lvl=info msg=Sign api=signer type=request metadata="{\"remote\":\"127.0.0.1:49706\",\"local\":\"localhost:8550\",\"scheme\":\"HTTP/1.1\"}" addr="0x694267f14675d7e1b9494fd8d72fefe1755710fa [chksum INVALID]" data=202062617a6f6e6b2062617a2067617a0a |
||||
t=2018-02-21T14:42:42+0100 lvl=info msg=Sign api=signer type=response data=93e6161840c3ae1efc26dc68dedab6e8fc233bb3fefa1b4645dbf6609b93dace160572ea4ab33240256bb6d3dadb60dcd9c515d6374d3cf614ee897408d41d541c error=nil |
||||
t=2018-02-21T14:42:56+0100 lvl=info msg=Sign api=signer type=request metadata="{\"remote\":\"127.0.0.1:49708\",\"local\":\"localhost:8550\",\"scheme\":\"HTTP/1.1\"}" addr="0x694267f14675d7e1b9494fd8d72fefe1755710fa [chksum INVALID]" data=2020626f6e6b2062617a2067617a0a |
||||
t=2018-02-21T14:42:56+0100 lvl=info msg=Sign api=signer type=response data= error="Request denied" |
||||
``` |
||||
@ -0,0 +1,805 @@ |
||||
## Communication |
||||
|
||||
### External API |
||||
|
||||
The signer listens to HTTP requests on `rpcaddr`:`rpcport`, with the same JSONRPC standard as Geth. The messages are |
||||
expected to be JSON [jsonrpc 2.0 standard](http://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 confirmation request. |
||||
|
||||
The External API is **untrusted** : it does not accept credentials over this api, nor does it expect |
||||
that requests have any authority. |
||||
|
||||
### UI API |
||||
|
||||
The signer has one native console-based UI, for operation without any standalone tools. |
||||
However, there is also an API to communicate with an external UI. To enable that UI, |
||||
the signer needs to be executed with the `--stdio-ui` option, which allocates the |
||||
`stdin`/`stdout` for the UI-api. |
||||
|
||||
An example (insecure) proof-of-concept of has been implemented in `pythonsigner.py`. |
||||
|
||||
The model is as follows: |
||||
|
||||
* The user starts the UI app (`pythonsigner.py`). |
||||
* The UI app starts the `signer` with `--stdio-ui`, and listens to the |
||||
process output for confirmation-requests. |
||||
* The `signer` opens the external http api. |
||||
* When the `signer` receives requests, it sends a `jsonrpc` request via `stdout`. |
||||
* The UI app prompts the user accordingly, and responds to the `signer` |
||||
* The `signer` signs (or not), and responds to the original request. |
||||
|
||||
## External API |
||||
|
||||
See the [external api changelog](extapi_changelog.md) for information about changes to this API. |
||||
|
||||
### Encoding |
||||
- number: positive integers that are hex encoded |
||||
- data: hex encoded data |
||||
- string: ASCII string |
||||
|
||||
All hex encoded values must be prefixed with `0x`. |
||||
|
||||
## Methods |
||||
|
||||
### account_new |
||||
|
||||
#### Create new password protected account |
||||
|
||||
The signer will generate a new private key, encrypts it according to [web3 keystore spec](https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition) and stores it in the keystore directory. |
||||
The client is responsible for creating a backup of the keystore. If the keystore is lost there is no method of retrieving lost accounts. |
||||
|
||||
#### Arguments |
||||
|
||||
None |
||||
|
||||
#### Result |
||||
- address [string]: account address that is derived from the generated key |
||||
- url [string]: location of the keyfile |
||||
|
||||
#### Sample call |
||||
```json |
||||
{ |
||||
"id": 0, |
||||
"jsonrpc": "2.0", |
||||
"method": "account_new", |
||||
"params": [] |
||||
} |
||||
``` |
||||
Response |
||||
``` |
||||
{ |
||||
"id": 0, |
||||
"jsonrpc": "2.0", |
||||
"result": { |
||||
"address": "0xbea9183f8f4f03d427f6bcea17388bdff1cab133", |
||||
"url": "keystore:///my/keystore/UTC--2017-08-24T08-40-15.419655028Z--bea9183f8f4f03d427f6bcea17388bdff1cab133" |
||||
} |
||||
} |
||||
``` |
||||
|
||||
### account_list |
||||
|
||||
#### List available accounts |
||||
List all accounts that this signer currently manages |
||||
|
||||
#### Arguments |
||||
|
||||
None |
||||
|
||||
#### Result |
||||
- array with account records: |
||||
- account.address [string]: account address that is derived from the generated key |
||||
- account.type [string]: type of the |
||||
- account.url [string]: location of the account |
||||
|
||||
#### Sample call |
||||
```json |
||||
{ |
||||
"id": 1, |
||||
"jsonrpc": "2.0", |
||||
"method": "account_list" |
||||
} |
||||
``` |
||||
Response |
||||
``` |
||||
{ |
||||
"id": 1, |
||||
"jsonrpc": "2.0", |
||||
"result": [ |
||||
{ |
||||
"address": "0xafb2f771f58513609765698f65d3f2f0224a956f", |
||||
"type": "account", |
||||
"url": "keystore:///tmp/keystore/UTC--2017-08-24T07-26-47.162109726Z--afb2f771f58513609765698f65d3f2f0224a956f" |
||||
}, |
||||
{ |
||||
"address": "0xbea9183f8f4f03d427f6bcea17388bdff1cab133", |
||||
"type": "account", |
||||
"url": "keystore:///tmp/keystore/UTC--2017-08-24T08-40-15.419655028Z--bea9183f8f4f03d427f6bcea17388bdff1cab133" |
||||
} |
||||
] |
||||
} |
||||
``` |
||||
|
||||
### account_signTransaction |
||||
|
||||
#### Sign transactions |
||||
Signs a transactions and responds with the signed transaction in RLP encoded form. |
||||
|
||||
#### Arguments |
||||
2. transaction object: |
||||
- `from` [address]: account to send the transaction from |
||||
- `to` [address]: receiver account. If omitted or `0x`, will cause contract creation. |
||||
- `gas` [number]: maximum amount of gas to burn |
||||
- `gasPrice` [number]: gas price |
||||
- `value` [number:optional]: amount of Wei to send with the transaction |
||||
- `data` [data:optional]: input data |
||||
- `nonce` [number]: account nonce |
||||
3. method signature [string:optional] |
||||
- The method signature, if present, is to aid decoding the calldata. Should consist of `methodname(paramtype,...)`, e.g. `transfer(uint256,address)`. The signer may use this data to parse the supplied calldata, and show the user. The data, however, is considered totally untrusted, and reliability is not expected. |
||||
|
||||
|
||||
#### Result |
||||
- signed transaction in RLP encoded form [data] |
||||
|
||||
#### Sample call |
||||
```json |
||||
{ |
||||
"id": 2, |
||||
"jsonrpc": "2.0", |
||||
"method": "account_signTransaction", |
||||
"params": [ |
||||
{ |
||||
"from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db", |
||||
"gas": "0x55555", |
||||
"gasPrice": "0x1234", |
||||
"input": "0xabcd", |
||||
"nonce": "0x0", |
||||
"to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", |
||||
"value": "0x1234" |
||||
} |
||||
] |
||||
} |
||||
``` |
||||
Response |
||||
|
||||
```json |
||||
{ |
||||
"id": 2, |
||||
"jsonrpc": "2.0", |
||||
"error": { |
||||
"code": -32000, |
||||
"message": "Request denied" |
||||
} |
||||
} |
||||
``` |
||||
#### Sample call with ABI-data |
||||
|
||||
|
||||
```json |
||||
{ |
||||
"id": 67, |
||||
"jsonrpc": "2.0", |
||||
"method": "account_signTransaction", |
||||
"params": [ |
||||
{ |
||||
"from": "0x694267f14675d7e1b9494fd8d72fefe1755710fa", |
||||
"gas": "0x333", |
||||
"gasPrice": "0x1", |
||||
"nonce": "0x0", |
||||
"to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", |
||||
"value": "0x0", |
||||
"data": "0x4401a6e40000000000000000000000000000000000000000000000000000000000000012" |
||||
}, |
||||
"safeSend(address)" |
||||
] |
||||
} |
||||
``` |
||||
Response |
||||
|
||||
```json |
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 67, |
||||
"result": { |
||||
"raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663", |
||||
"tx": { |
||||
"nonce": "0x0", |
||||
"gasPrice": "0x1", |
||||
"gas": "0x333", |
||||
"to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", |
||||
"value": "0x0", |
||||
"input": "0x4401a6e40000000000000000000000000000000000000000000000000000000000000012", |
||||
"v": "0x26", |
||||
"r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e", |
||||
"s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663", |
||||
"hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e" |
||||
} |
||||
} |
||||
} |
||||
``` |
||||
|
||||
Bash example: |
||||
```bash |
||||
#curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"account_signTransaction","params":[{"from":"0x694267f14675d7e1b9494fd8d72fefe1755710fa","gas":"0x333","gasPrice":"0x1","nonce":"0x0","to":"0x07a565b7ed7d7a678680a4c162885bedbb695fe0", "value":"0x0", "data":"0x4401a6e40000000000000000000000000000000000000000000000000000000000000012"},"safeSend(address)"],"id":67}' http://localhost:8550/ |
||||
|
||||
{"jsonrpc":"2.0","id":67,"result":{"raw":"0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663","tx":{"nonce":"0x0","gasPrice":"0x1","gas":"0x333","to":"0x07a565b7ed7d7a678680a4c162885bedbb695fe0","value":"0x0","input":"0x4401a6e40000000000000000000000000000000000000000000000000000000000000012","v":"0x26","r":"0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e","s":"0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663","hash":"0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"}}} |
||||
``` |
||||
|
||||
### account_signData |
||||
|
||||
#### Sign data |
||||
Signs a chunk of data and returns the calculated signature. |
||||
|
||||
#### Arguments |
||||
- content type [string]: type of signed data |
||||
- `text/validator`: hex data with custom validator defined in a contract |
||||
- `application/clique`: [clique](https://github.com/ethereum/EIPs/issues/225) headers |
||||
- `text/plain`: simple hex data validated by `account_ecRecover` |
||||
- account [address]: account to sign with |
||||
- data [object]: data to sign |
||||
|
||||
#### Result |
||||
- calculated signature [data] |
||||
|
||||
#### Sample call |
||||
```json |
||||
{ |
||||
"id": 3, |
||||
"jsonrpc": "2.0", |
||||
"method": "account_signData", |
||||
"params": [ |
||||
"data/plain", |
||||
"0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db", |
||||
"0xaabbccdd" |
||||
] |
||||
} |
||||
``` |
||||
Response |
||||
|
||||
```json |
||||
{ |
||||
"id": 3, |
||||
"jsonrpc": "2.0", |
||||
"result": "0x5b6693f153b48ec1c706ba4169960386dbaa6903e249cc79a8e6ddc434451d417e1e57327872c7f538beeb323c300afa9999a3d4a5de6caf3be0d5ef832b67ef1c" |
||||
} |
||||
``` |
||||
|
||||
### account_signTypedData |
||||
|
||||
#### Sign data |
||||
Signs a chunk of structured data conformant to [EIP712]([EIP-712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md)) and returns the calculated signature. |
||||
|
||||
#### Arguments |
||||
- account [address]: account to sign with |
||||
- data [object]: data to sign |
||||
|
||||
#### Result |
||||
- calculated signature [data] |
||||
|
||||
#### Sample call |
||||
```json |
||||
{ |
||||
"id": 68, |
||||
"jsonrpc": "2.0", |
||||
"method": "account_signTypedData", |
||||
"params": [ |
||||
"0xcd2a3d9f938e13cd947ec05abc7fe734df8dd826", |
||||
{ |
||||
"types": { |
||||
"EIP712Domain": [ |
||||
{ |
||||
"name": "name", |
||||
"type": "string" |
||||
}, |
||||
{ |
||||
"name": "version", |
||||
"type": "string" |
||||
}, |
||||
{ |
||||
"name": "chainId", |
||||
"type": "uint256" |
||||
}, |
||||
{ |
||||
"name": "verifyingContract", |
||||
"type": "address" |
||||
} |
||||
], |
||||
"Person": [ |
||||
{ |
||||
"name": "name", |
||||
"type": "string" |
||||
}, |
||||
{ |
||||
"name": "wallet", |
||||
"type": "address" |
||||
} |
||||
], |
||||
"Mail": [ |
||||
{ |
||||
"name": "from", |
||||
"type": "Person" |
||||
}, |
||||
{ |
||||
"name": "to", |
||||
"type": "Person" |
||||
}, |
||||
{ |
||||
"name": "contents", |
||||
"type": "string" |
||||
} |
||||
] |
||||
}, |
||||
"primaryType": "Mail", |
||||
"domain": { |
||||
"name": "Ether Mail", |
||||
"version": "1", |
||||
"chainId": 1, |
||||
"verifyingContract": "0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC" |
||||
}, |
||||
"message": { |
||||
"from": { |
||||
"name": "Cow", |
||||
"wallet": "0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826" |
||||
}, |
||||
"to": { |
||||
"name": "Bob", |
||||
"wallet": "0xbBbBBBBbbBBBbbbBbbBbbbbBBbBbbbbBbBbbBBbB" |
||||
}, |
||||
"contents": "Hello, Bob!" |
||||
} |
||||
} |
||||
] |
||||
} |
||||
``` |
||||
Response |
||||
|
||||
```json |
||||
{ |
||||
"id": 1, |
||||
"jsonrpc": "2.0", |
||||
"result": "0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b915621c" |
||||
} |
||||
``` |
||||
|
||||
### account_ecRecover |
||||
|
||||
#### Sign data |
||||
|
||||
Derive the address from the account that was used to sign data with content type `text/plain` and the signature. |
||||
|
||||
#### Arguments |
||||
- data [data]: data that was signed |
||||
- signature [data]: the signature to verify |
||||
|
||||
#### Result |
||||
- derived account [address] |
||||
|
||||
#### Sample call |
||||
```json |
||||
{ |
||||
"id": 4, |
||||
"jsonrpc": "2.0", |
||||
"method": "account_ecRecover", |
||||
"params": [ |
||||
"data/plain", |
||||
"0xaabbccdd", |
||||
"0x5b6693f153b48ec1c706ba4169960386dbaa6903e249cc79a8e6ddc434451d417e1e57327872c7f538beeb323c300afa9999a3d4a5de6caf3be0d5ef832b67ef1c" |
||||
] |
||||
} |
||||
``` |
||||
Response |
||||
|
||||
```json |
||||
{ |
||||
"id": 4, |
||||
"jsonrpc": "2.0", |
||||
"result": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db" |
||||
} |
||||
``` |
||||
|
||||
### account_import |
||||
|
||||
#### Import account |
||||
Import a private key into the keystore. The imported key is expected to be encrypted according to the web3 keystore |
||||
format. |
||||
|
||||
#### Arguments |
||||
- account [object]: key in [web3 keystore format](https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition) (retrieved with account_export) |
||||
|
||||
#### Result |
||||
- imported key [object]: |
||||
- key.address [address]: address of the imported key |
||||
- key.type [string]: type of the account |
||||
- key.url [string]: key URL |
||||
|
||||
#### Sample call |
||||
```json |
||||
{ |
||||
"id": 6, |
||||
"jsonrpc": "2.0", |
||||
"method": "account_import", |
||||
"params": [ |
||||
{ |
||||
"address": "c7412fc59930fd90099c917a50e5f11d0934b2f5", |
||||
"crypto": { |
||||
"cipher": "aes-128-ctr", |
||||
"cipherparams": { |
||||
"iv": "401c39a7c7af0388491c3d3ecb39f532" |
||||
}, |
||||
"ciphertext": "eb045260b18dd35cd0e6d99ead52f8fa1e63a6b0af2d52a8de198e59ad783204", |
||||
"kdf": "scrypt", |
||||
"kdfparams": { |
||||
"dklen": 32, |
||||
"n": 262144, |
||||
"p": 1, |
||||
"r": 8, |
||||
"salt": "9a657e3618527c9b5580ded60c12092e5038922667b7b76b906496f021bb841a" |
||||
}, |
||||
"mac": "880dc10bc06e9cec78eb9830aeb1e7a4a26b4c2c19615c94acb632992b952806" |
||||
}, |
||||
"id": "09bccb61-b8d3-4e93-bf4f-205a8194f0b9", |
||||
"version": 3 |
||||
} |
||||
] |
||||
} |
||||
``` |
||||
Response |
||||
|
||||
```json |
||||
{ |
||||
"id": 6, |
||||
"jsonrpc": "2.0", |
||||
"result": { |
||||
"address": "0xc7412fc59930fd90099c917a50e5f11d0934b2f5", |
||||
"type": "account", |
||||
"url": "keystore:///tmp/keystore/UTC--2017-08-24T11-00-42.032024108Z--c7412fc59930fd90099c917a50e5f11d0934b2f5" |
||||
} |
||||
} |
||||
``` |
||||
|
||||
### account_export |
||||
|
||||
#### Export account from keystore |
||||
Export a private key from the keystore. The exported private key is encrypted with the original passphrase. When the |
||||
key is imported later this passphrase is required. |
||||
|
||||
#### Arguments |
||||
- account [address]: export private key that is associated with this account |
||||
|
||||
#### Result |
||||
- exported key, see [web3 keystore format](https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition) for |
||||
more information |
||||
|
||||
#### Sample call |
||||
```json |
||||
{ |
||||
"id": 5, |
||||
"jsonrpc": "2.0", |
||||
"method": "account_export", |
||||
"params": [ |
||||
"0xc7412fc59930fd90099c917a50e5f11d0934b2f5" |
||||
] |
||||
} |
||||
``` |
||||
Response |
||||
|
||||
```json |
||||
{ |
||||
"id": 5, |
||||
"jsonrpc": "2.0", |
||||
"result": { |
||||
"address": "c7412fc59930fd90099c917a50e5f11d0934b2f5", |
||||
"crypto": { |
||||
"cipher": "aes-128-ctr", |
||||
"cipherparams": { |
||||
"iv": "401c39a7c7af0388491c3d3ecb39f532" |
||||
}, |
||||
"ciphertext": "eb045260b18dd35cd0e6d99ead52f8fa1e63a6b0af2d52a8de198e59ad783204", |
||||
"kdf": "scrypt", |
||||
"kdfparams": { |
||||
"dklen": 32, |
||||
"n": 262144, |
||||
"p": 1, |
||||
"r": 8, |
||||
"salt": "9a657e3618527c9b5580ded60c12092e5038922667b7b76b906496f021bb841a" |
||||
}, |
||||
"mac": "880dc10bc06e9cec78eb9830aeb1e7a4a26b4c2c19615c94acb632992b952806" |
||||
}, |
||||
"id": "09bccb61-b8d3-4e93-bf4f-205a8194f0b9", |
||||
"version": 3 |
||||
} |
||||
} |
||||
``` |
||||
|
||||
|
||||
|
||||
## UI API |
||||
|
||||
These methods needs to be implemented by a UI listener. |
||||
|
||||
By starting the signer with the switch `--stdio-ui-test`, the signer will invoke all known methods, and expect the UI to respond with |
||||
denials. This can be used during development to ensure that the API is (at least somewhat) correctly implemented. |
||||
See `pythonsigner`, which can be invoked via `python3 pythonsigner.py test` to perform the 'denial-handshake-test'. |
||||
|
||||
All methods in this API uses object-based parameters, so that there can be no mixups of parameters: each piece of data is accessed by key. |
||||
|
||||
See the [ui api changelog](intapi_changelog.md) for information about changes to this API. |
||||
|
||||
OBS! A slight deviation from `json` standard is in place: every request and response should be confined to a single line. |
||||
Whereas the `json` specification allows for linebreaks, linebreaks __should not__ be used in this communication channel, to make |
||||
things simpler for both parties. |
||||
|
||||
### ApproveTx / `ui_approveTx` |
||||
|
||||
Invoked when there's a transaction for approval. |
||||
|
||||
|
||||
#### Sample call |
||||
|
||||
Here's a method invocation: |
||||
```bash |
||||
|
||||
curl -i -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"account_signTransaction","params":[{"from":"0x694267f14675d7e1b9494fd8d72fefe1755710fa","gas":"0x333","gasPrice":"0x1","nonce":"0x0","to":"0x07a565b7ed7d7a678680a4c162885bedbb695fe0", "value":"0x0", "data":"0x4401a6e40000000000000000000000000000000000000000000000000000000000000012"},"safeSend(address)"],"id":67}' http://localhost:8550/ |
||||
``` |
||||
Results in the following invocation on the UI: |
||||
```json |
||||
|
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 1, |
||||
"method": "ui_approveTx", |
||||
"params": [ |
||||
{ |
||||
"transaction": { |
||||
"from": "0x0x694267f14675d7e1b9494fd8d72fefe1755710fa", |
||||
"to": "0x0x07a565b7ed7d7a678680a4c162885bedbb695fe0", |
||||
"gas": "0x333", |
||||
"gasPrice": "0x1", |
||||
"value": "0x0", |
||||
"nonce": "0x0", |
||||
"data": "0x4401a6e40000000000000000000000000000000000000000000000000000000000000012", |
||||
"input": null |
||||
}, |
||||
"call_info": [ |
||||
{ |
||||
"type": "WARNING", |
||||
"message": "Invalid checksum on to-address" |
||||
}, |
||||
{ |
||||
"type": "Info", |
||||
"message": "safeSend(address: 0x0000000000000000000000000000000000000012)" |
||||
} |
||||
], |
||||
"meta": { |
||||
"remote": "127.0.0.1:48486", |
||||
"local": "localhost:8550", |
||||
"scheme": "HTTP/1.1" |
||||
} |
||||
} |
||||
] |
||||
} |
||||
|
||||
``` |
||||
|
||||
The same method invocation, but with invalid data: |
||||
```bash |
||||
|
||||
curl -i -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"account_signTransaction","params":[{"from":"0x694267f14675d7e1b9494fd8d72fefe1755710fa","gas":"0x333","gasPrice":"0x1","nonce":"0x0","to":"0x07a565b7ed7d7a678680a4c162885bedbb695fe0", "value":"0x0", "data":"0x4401a6e40000000000000002000000000000000000000000000000000000000000000012"},"safeSend(address)"],"id":67}' http://localhost:8550/ |
||||
``` |
||||
|
||||
```json |
||||
|
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 1, |
||||
"method": "ui_approveTx", |
||||
"params": [ |
||||
{ |
||||
"transaction": { |
||||
"from": "0x0x694267f14675d7e1b9494fd8d72fefe1755710fa", |
||||
"to": "0x0x07a565b7ed7d7a678680a4c162885bedbb695fe0", |
||||
"gas": "0x333", |
||||
"gasPrice": "0x1", |
||||
"value": "0x0", |
||||
"nonce": "0x0", |
||||
"data": "0x4401a6e40000000000000002000000000000000000000000000000000000000000000012", |
||||
"input": null |
||||
}, |
||||
"call_info": [ |
||||
{ |
||||
"type": "WARNING", |
||||
"message": "Invalid checksum on to-address" |
||||
}, |
||||
{ |
||||
"type": "WARNING", |
||||
"message": "Transaction data did not match ABI-interface: WARNING: Supplied data is stuffed with extra data. \nWant 0000000000000002000000000000000000000000000000000000000000000012\nHave 0000000000000000000000000000000000000000000000000000000000000012\nfor method safeSend(address)" |
||||
} |
||||
], |
||||
"meta": { |
||||
"remote": "127.0.0.1:48492", |
||||
"local": "localhost:8550", |
||||
"scheme": "HTTP/1.1" |
||||
} |
||||
} |
||||
] |
||||
} |
||||
|
||||
|
||||
``` |
||||
|
||||
One which has missing `to`, but with no `data`: |
||||
|
||||
|
||||
```json |
||||
|
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 3, |
||||
"method": "ui_approveTx", |
||||
"params": [ |
||||
{ |
||||
"transaction": { |
||||
"from": "", |
||||
"to": null, |
||||
"gas": "0x0", |
||||
"gasPrice": "0x0", |
||||
"value": "0x0", |
||||
"nonce": "0x0", |
||||
"data": null, |
||||
"input": null |
||||
}, |
||||
"call_info": [ |
||||
{ |
||||
"type": "CRITICAL", |
||||
"message": "Tx will create contract with empty code!" |
||||
} |
||||
], |
||||
"meta": { |
||||
"remote": "signer binary", |
||||
"local": "main", |
||||
"scheme": "in-proc" |
||||
} |
||||
} |
||||
] |
||||
} |
||||
``` |
||||
|
||||
### ApproveListing / `ui_approveListing` |
||||
|
||||
Invoked when a request for account listing has been made. |
||||
|
||||
#### Sample call |
||||
|
||||
```json |
||||
|
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 5, |
||||
"method": "ui_approveListing", |
||||
"params": [ |
||||
{ |
||||
"accounts": [ |
||||
{ |
||||
"type": "Account", |
||||
"url": "keystore:///home/bazonk/.ethereum/keystore/UTC--2017-11-20T14-44-54.089682944Z--123409812340981234098123409812deadbeef42", |
||||
"address": "0x123409812340981234098123409812deadbeef42" |
||||
}, |
||||
{ |
||||
"type": "Account", |
||||
"url": "keystore:///home/bazonk/.ethereum/keystore/UTC--2017-11-23T21-59-03.199240693Z--cafebabedeadbeef34098123409812deadbeef42", |
||||
"address": "0xcafebabedeadbeef34098123409812deadbeef42" |
||||
} |
||||
], |
||||
"meta": { |
||||
"remote": "signer binary", |
||||
"local": "main", |
||||
"scheme": "in-proc" |
||||
} |
||||
} |
||||
] |
||||
} |
||||
|
||||
``` |
||||
|
||||
|
||||
### ApproveSignData / `ui_approveSignData` |
||||
|
||||
#### Sample call |
||||
|
||||
```json |
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 4, |
||||
"method": "ui_approveSignData", |
||||
"params": [ |
||||
{ |
||||
"address": "0x123409812340981234098123409812deadbeef42", |
||||
"raw_data": "0x01020304", |
||||
"message": "\u0019Ethereum Signed Message:\n4\u0001\u0002\u0003\u0004", |
||||
"hash": "0x7e3a4e7a9d1744bc5c675c25e1234ca8ed9162bd17f78b9085e48047c15ac310", |
||||
"meta": { |
||||
"remote": "signer binary", |
||||
"local": "main", |
||||
"scheme": "in-proc" |
||||
} |
||||
} |
||||
] |
||||
} |
||||
|
||||
``` |
||||
|
||||
### ShowInfo / `ui_showInfo` |
||||
|
||||
The UI should show the info to the user. Does not expect response. |
||||
|
||||
#### Sample call |
||||
|
||||
```json |
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 9, |
||||
"method": "ui_showInfo", |
||||
"params": [ |
||||
{ |
||||
"text": "Tests completed" |
||||
} |
||||
] |
||||
} |
||||
|
||||
``` |
||||
|
||||
### ShowError / `ui_showError` |
||||
|
||||
The UI should show the info to the user. Does not expect response. |
||||
|
||||
```json |
||||
|
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 2, |
||||
"method": "ShowError", |
||||
"params": [ |
||||
{ |
||||
"text": "Testing 'ShowError'" |
||||
} |
||||
] |
||||
} |
||||
|
||||
``` |
||||
|
||||
### OnApprovedTx / `ui_onApprovedTx` |
||||
|
||||
`OnApprovedTx` is called when a transaction has been approved and signed. The call contains the return value that will be sent to the external caller. The return value from this method is ignored - the reason for having this callback is to allow the ruleset to keep track of approved transactions. |
||||
|
||||
When implementing rate-limited rules, this callback should be used. |
||||
|
||||
TLDR; Use this method to keep track of signed transactions, instead of using the data in `ApproveTx`. |
||||
|
||||
### OnSignerStartup / `ui_onSignerStartup` |
||||
|
||||
This method provide the UI with information about what API version the signer uses (both internal and external) aswell as build-info and external api, |
||||
in k/v-form. |
||||
|
||||
Example call: |
||||
```json |
||||
|
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 1, |
||||
"method": "ui_onSignerStartup", |
||||
"params": [ |
||||
{ |
||||
"info": { |
||||
"extapi_http": "http://localhost:8550", |
||||
"extapi_ipc": null, |
||||
"extapi_version": "2.0.0", |
||||
"intapi_version": "1.2.0" |
||||
} |
||||
} |
||||
] |
||||
} |
||||
|
||||
``` |
||||
|
||||
|
After Width: | Height: | Size: 68 KiB |
|
After Width: | Height: | Size: 80 KiB |
|
After Width: | Height: | Size: 99 KiB |
|
After Width: | Height: | Size: 115 KiB |
@ -0,0 +1,224 @@ |
||||
## UI Client interface |
||||
|
||||
These data types are defined in the channel between clef and the UI |
||||
### SignDataRequest |
||||
|
||||
SignDataRequest contains information about a pending request to sign some data. The data to be signed can be of various types, defined by content-type. Clef has done most of the work in canonicalizing and making sense of the data, and it's up to the UI to presentthe user with the contents of the `message` |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"content_type": "text/plain", |
||||
"address": "0xDEADbEeF000000000000000000000000DeaDbeEf", |
||||
"raw_data": "GUV0aGVyZXVtIFNpZ25lZCBNZXNzYWdlOgoxMWhlbGxvIHdvcmxk", |
||||
"message": [ |
||||
{ |
||||
"name": "message", |
||||
"value": "\u0019Ethereum Signed Message:\n11hello world", |
||||
"type": "text/plain" |
||||
} |
||||
], |
||||
"hash": "0xd9eba16ed0ecae432b71fe008c98cc872bb4cc214d3220a36f365326cf807d68", |
||||
"meta": { |
||||
"remote": "localhost:9999", |
||||
"local": "localhost:8545", |
||||
"scheme": "http", |
||||
"User-Agent": "Firefox 3.2", |
||||
"Origin": "www.malicious.ru" |
||||
} |
||||
} |
||||
``` |
||||
### SignDataResponse - approve |
||||
|
||||
Response to SignDataRequest |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"approved": true |
||||
} |
||||
``` |
||||
### SignDataResponse - deny |
||||
|
||||
Response to SignDataRequest |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"approved": false |
||||
} |
||||
``` |
||||
### SignTxRequest |
||||
|
||||
SignTxRequest contains information about a pending request to sign a transaction. Aside from the transaction itself, there is also a `call_info`-struct. That struct contains messages of various types, that the user should be informed of. |
||||
|
||||
As in any request, it's important to consider that the `meta` info also contains untrusted data. |
||||
|
||||
The `transaction` (on input into clef) can have either `data` or `input` -- if both are set, they must be identical, otherwise an error is generated. However, Clef will always use `data` when passing this struct on (if Clef does otherwise, please file a ticket) |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"transaction": { |
||||
"from": "0xDEADbEeF000000000000000000000000DeaDbeEf", |
||||
"to": null, |
||||
"gas": "0x3e8", |
||||
"gasPrice": "0x5", |
||||
"value": "0x6", |
||||
"nonce": "0x1", |
||||
"data": "0x01020304" |
||||
}, |
||||
"call_info": [ |
||||
{ |
||||
"type": "Warning", |
||||
"message": "Something looks odd, show this message as a warning" |
||||
}, |
||||
{ |
||||
"type": "Info", |
||||
"message": "User should see this aswell" |
||||
} |
||||
], |
||||
"meta": { |
||||
"remote": "localhost:9999", |
||||
"local": "localhost:8545", |
||||
"scheme": "http", |
||||
"User-Agent": "Firefox 3.2", |
||||
"Origin": "www.malicious.ru" |
||||
} |
||||
} |
||||
``` |
||||
### SignTxResponse - approve |
||||
|
||||
Response to request to sign a transaction. This response needs to contain the `transaction`, because the UI is free to make modifications to the transaction. |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"transaction": { |
||||
"from": "0xDEADbEeF000000000000000000000000DeaDbeEf", |
||||
"to": null, |
||||
"gas": "0x3e8", |
||||
"gasPrice": "0x5", |
||||
"value": "0x6", |
||||
"nonce": "0x4", |
||||
"data": "0x04030201" |
||||
}, |
||||
"approved": true |
||||
} |
||||
``` |
||||
### SignTxResponse - deny |
||||
|
||||
Response to SignTxRequest. When denying a request, there's no need to provide the transaction in return |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"transaction": { |
||||
"from": "0x", |
||||
"to": null, |
||||
"gas": "0x0", |
||||
"gasPrice": "0x0", |
||||
"value": "0x0", |
||||
"nonce": "0x0", |
||||
"data": null |
||||
}, |
||||
"approved": false |
||||
} |
||||
``` |
||||
### OnApproved - SignTransactionResult |
||||
|
||||
SignTransactionResult is used in the call `clef` -> `OnApprovedTx(result)` |
||||
|
||||
This occurs _after_ successful completion of the entire signing procedure, but right before the signed transaction is passed to the external caller. This method (and data) can be used by the UI to signal to the user that the transaction was signed, but it is primarily useful for ruleset implementations. |
||||
|
||||
A ruleset that implements a rate limitation needs to know what transactions are sent out to the external interface. By hooking into this methods, the ruleset can maintain track of that count. |
||||
|
||||
**OBS:** Note that if an attacker can restore your `clef` data to a previous point in time (e.g through a backup), the attacker can reset such windows, even if he/she is unable to decrypt the content. |
||||
|
||||
The `OnApproved` method cannot be responded to, it's purely informative |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"raw": "0xf85d640101948a8eafb1cf62bfbeb1741769dae1a9dd47996192018026a0716bd90515acb1e68e5ac5867aa11a1e65399c3349d479f5fb698554ebc6f293a04e8a4ebfff434e971e0ef12c5bf3a881b06fd04fc3f8b8a7291fb67a26a1d4ed", |
||||
"tx": { |
||||
"nonce": "0x64", |
||||
"gasPrice": "0x1", |
||||
"gas": "0x1", |
||||
"to": "0x8a8eafb1cf62bfbeb1741769dae1a9dd47996192", |
||||
"value": "0x1", |
||||
"input": "0x", |
||||
"v": "0x26", |
||||
"r": "0x716bd90515acb1e68e5ac5867aa11a1e65399c3349d479f5fb698554ebc6f293", |
||||
"s": "0x4e8a4ebfff434e971e0ef12c5bf3a881b06fd04fc3f8b8a7291fb67a26a1d4ed", |
||||
"hash": "0x662f6d772692dd692f1b5e8baa77a9ff95bbd909362df3fc3d301aafebde5441" |
||||
} |
||||
} |
||||
``` |
||||
### UserInputRequest |
||||
|
||||
Sent when clef needs the user to provide data. If 'password' is true, the input field should be treated accordingly (echo-free) |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"prompt": "The question to ask the user", |
||||
"title": "The title here", |
||||
"isPassword": true |
||||
} |
||||
``` |
||||
### UserInputResponse |
||||
|
||||
Response to UserInputRequest |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"text": "The textual response from user" |
||||
} |
||||
``` |
||||
### ListRequest |
||||
|
||||
Sent when a request has been made to list addresses. The UI is provided with the full `account`s, including local directory names. Note: this information is not passed back to the external caller, who only sees the `address`es. |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"accounts": [ |
||||
{ |
||||
"address": "0xdeadbeef000000000000000000000000deadbeef", |
||||
"url": "keystore:///path/to/keyfile/a" |
||||
}, |
||||
{ |
||||
"address": "0x1111111122222222222233333333334444444444", |
||||
"url": "keystore:///path/to/keyfile/b" |
||||
} |
||||
], |
||||
"meta": { |
||||
"remote": "localhost:9999", |
||||
"local": "localhost:8545", |
||||
"scheme": "http", |
||||
"User-Agent": "Firefox 3.2", |
||||
"Origin": "www.malicious.ru" |
||||
} |
||||
} |
||||
``` |
||||
### ListResponse |
||||
|
||||
Response to list request. The response contains a list of all addresses to show to the caller. Note: the UI is free to respond with any address the caller, regardless of whether it exists or not |
||||
|
||||
Example: |
||||
```json |
||||
{ |
||||
"accounts": [ |
||||
{ |
||||
"address": "0x0000000000000000000000000000000000000000", |
||||
"url": ".. ignored .." |
||||
}, |
||||
{ |
||||
"address": "0xffffffffffffffffffffffffffffffffffffffff", |
||||
"url": "" |
||||
} |
||||
] |
||||
} |
||||
``` |
||||
@ -0,0 +1,47 @@ |
||||
### Changelog for external API |
||||
|
||||
### 6.0.0 |
||||
|
||||
* `New` was changed to deliver only an address, not the full `Account` data |
||||
* `Export` was moved from External API to the UI Server API |
||||
|
||||
#### 5.0.0 |
||||
|
||||
* The external `account_EcRecover`-method was reimplemented. |
||||
* The external method `account_sign(address, data)` was replaced with `account_signData(contentType, address, data)`. |
||||
The addition of `contentType` makes it possible to use the method for different types of objects, such as: |
||||
* signing data with an intended validator (not yet implemented) |
||||
* signing clique headers, |
||||
* signing plain personal messages, |
||||
* The external method `account_signTypedData` implements [EIP-712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md) and makes it possible to sign typed data. |
||||
|
||||
#### 4.0.0 |
||||
|
||||
* The external `account_Ecrecover`-method was removed. |
||||
* The external `account_Import`-method was removed. |
||||
|
||||
#### 3.0.0 |
||||
|
||||
* The external `account_List`-method was changed to not expose `url`, which contained info about the local filesystem. It now returns only a list of addresses. |
||||
|
||||
#### 2.0.0 |
||||
|
||||
* Commit `73abaf04b1372fa4c43201fb1b8019fe6b0a6f8d`, move `from` into `transaction` object in `signTransaction`. This |
||||
makes the `accounts_signTransaction` identical to the old `eth_signTransaction`. |
||||
|
||||
|
||||
#### 1.0.0 |
||||
|
||||
Initial release. |
||||
|
||||
### Versioning |
||||
|
||||
The API uses [semantic versioning](https://semver.org/). |
||||
|
||||
TLDR; Given a version number MAJOR.MINOR.PATCH, increment the: |
||||
|
||||
* MAJOR version when you make incompatible API changes, |
||||
* MINOR version when you add functionality in a backwards-compatible manner, and |
||||
* PATCH version when you make backwards-compatible bug fixes. |
||||
|
||||
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. |
||||
@ -0,0 +1,175 @@ |
||||
### Changelog for internal API (ui-api) |
||||
|
||||
### 6.0.0 |
||||
|
||||
Removed `password` from responses to operations which require them. This is for two reasons, |
||||
|
||||
- Consistency between how rulesets operate and how manual processing works. A rule can `Approve` but require the actual password to be stored in the clef storage. |
||||
With this change, the same stored password can be used even if rulesets are not enabled, but storage is. |
||||
- It also removes the usability-shortcut that a UI might otherwise want to implement; remembering passwords. Since we now will not require the |
||||
password on every `Approve`, there's no need for the UI to cache it locally. |
||||
- In a future update, we'll likely add `clef_storePassword` to the internal API, so the user can store it via his UI (currently only CLI works). |
||||
|
||||
Affected datatypes: |
||||
- `SignTxResponse` |
||||
- `SignDataResponse` |
||||
- `NewAccountResponse` |
||||
|
||||
If `clef` requires a password, the `OnInputRequired` will be used to collect it. |
||||
|
||||
|
||||
### 5.0.0 |
||||
|
||||
Changed the namespace format to adhere to the legacy ethereum format: `name_methodName`. Changes: |
||||
|
||||
* `ApproveTx` -> `ui_approveTx` |
||||
* `ApproveSignData` -> `ui_approveSignData` |
||||
* `ApproveExport` -> `removed` |
||||
* `ApproveImport` -> `removed` |
||||
* `ApproveListing` -> `ui_approveListing` |
||||
* `ApproveNewAccount` -> `ui_approveNewAccount` |
||||
* `ShowError` -> `ui_showError` |
||||
* `ShowInfo` -> `ui_showInfo` |
||||
* `OnApprovedTx` -> `ui_onApprovedTx` |
||||
* `OnSignerStartup` -> `ui_onSignerStartup` |
||||
* `OnInputRequired` -> `ui_onInputRequired` |
||||
|
||||
|
||||
### 4.0.0 |
||||
|
||||
* Bidirectional communication implemented, so the UI can query `clef` via the stdin/stdout RPC channel. Methods implemented are: |
||||
- `clef_listWallets` |
||||
- `clef_listAccounts` |
||||
- `clef_listWallets` |
||||
- `clef_deriveAccount` |
||||
- `clef_importRawKey` |
||||
- `clef_openWallet` |
||||
- `clef_chainId` |
||||
- `clef_setChainId` |
||||
- `clef_export` |
||||
- `clef_import` |
||||
|
||||
* The type `Account` was modified (the json-field `type` was removed), to consist of |
||||
|
||||
```golang |
||||
type Account struct { |
||||
Address common.Address `json:"address"` // Ethereum account address derived from the key |
||||
URL URL `json:"url"` // Optional resource locator within a backend |
||||
} |
||||
``` |
||||
|
||||
|
||||
### 3.2.0 |
||||
|
||||
* Make `ShowError`, `OnApprovedTx`, `OnSignerStartup` be json-rpc [notifications](https://www.jsonrpc.org/specification#notification): |
||||
|
||||
> A Notification is a Request object without an "id" member. A Request object that is a Notification signifies the Client's lack of interest in the corresponding Response object, and as such no Response object needs to be returned to the client. The Server MUST NOT reply to a Notification, including those that are within a batch request. |
||||
> |
||||
> Notifications are not confirmable by definition, since they do not have a Response object to be returned. As such, the Client would not be aware of any errors (like e.g. "Invalid params","Internal error" |
||||
### 3.1.0 |
||||
|
||||
* Add `ContentType` `string` to `SignDataRequest` to accommodate the latest EIP-191 and EIP-712 implementations. |
||||
|
||||
### 3.0.0 |
||||
|
||||
* Make use of `OnInputRequired(info UserInputRequest)` for obtaining master password during startup |
||||
|
||||
### 2.1.0 |
||||
|
||||
* Add `OnInputRequired(info UserInputRequest)` to internal API. This method is used when Clef needs user input, e.g. passwords. |
||||
|
||||
The following structures are used: |
||||
```golang |
||||
UserInputRequest struct { |
||||
Prompt string `json:"prompt"` |
||||
Title string `json:"title"` |
||||
IsPassword bool `json:"isPassword"` |
||||
} |
||||
UserInputResponse struct { |
||||
Text string `json:"text"` |
||||
} |
||||
|
||||
### 2.0.0 |
||||
|
||||
* Modify how `call_info` on a transaction is conveyed. New format: |
||||
|
||||
``` |
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 2, |
||||
"method": "ApproveTx", |
||||
"params": [ |
||||
{ |
||||
"transaction": { |
||||
"from": "0x82A2A876D39022B3019932D30Cd9c97ad5616813", |
||||
"to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", |
||||
"gas": "0x333", |
||||
"gasPrice": "0x123", |
||||
"value": "0x10", |
||||
"nonce": "0x0", |
||||
"data": "0x4401a6e40000000000000000000000000000000000000000000000000000000000000012", |
||||
"input": null |
||||
}, |
||||
"call_info": [ |
||||
{ |
||||
"type": "WARNING", |
||||
"message": "Invalid checksum on to-address" |
||||
}, |
||||
{ |
||||
"type": "WARNING", |
||||
"message": "Tx contains data, but provided ABI signature could not be matched: Did not match: test (0 matches)" |
||||
} |
||||
], |
||||
"meta": { |
||||
"remote": "127.0.0.1:54286", |
||||
"local": "localhost:8550", |
||||
"scheme": "HTTP/1.1" |
||||
} |
||||
} |
||||
] |
||||
} |
||||
``` |
||||
|
||||
#### 1.2.0 |
||||
|
||||
* Add `OnStartup` method, to provide the UI with information about what API version |
||||
the signer uses (both internal and external) aswell as build-info and external api. |
||||
|
||||
Example call: |
||||
```json |
||||
{ |
||||
"jsonrpc": "2.0", |
||||
"id": 1, |
||||
"method": "OnSignerStartup", |
||||
"params": [ |
||||
{ |
||||
"info": { |
||||
"extapi_http": "http://localhost:8550", |
||||
"extapi_ipc": null, |
||||
"extapi_version": "2.0.0", |
||||
"intapi_version": "1.2.0" |
||||
} |
||||
} |
||||
] |
||||
} |
||||
``` |
||||
|
||||
#### 1.1.0 |
||||
|
||||
* Add `OnApproved` method |
||||
|
||||
#### 1.0.0 |
||||
|
||||
Initial release. |
||||
|
||||
### Versioning |
||||
|
||||
The API uses [semantic versioning](https://semver.org/). |
||||
|
||||
TLDR; Given a version number MAJOR.MINOR.PATCH, increment the: |
||||
|
||||
* MAJOR version when you make incompatible API changes, |
||||
* MINOR version when you add functionality in a backwards-compatible manner, and |
||||
* PATCH version when you make backwards-compatible bug fixes. |
||||
|
||||
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. |
||||
|
After Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 16 KiB |
@ -0,0 +1,23 @@ |
||||
""" |
||||
This implements a dispatcher which listens to localhost:8550, and proxies |
||||
requests via qrexec to the service qubes.EthSign on a target domain |
||||
""" |
||||
|
||||
import http.server |
||||
import socketserver,subprocess |
||||
|
||||
PORT=8550 |
||||
TARGET_DOMAIN= 'debian-work' |
||||
|
||||
class Dispatcher(http.server.BaseHTTPRequestHandler): |
||||
def do_POST(self): |
||||
post_data = self.rfile.read(int(self.headers['Content-Length'])) |
||||
p = subprocess.Popen(['/usr/bin/qrexec-client-vm',TARGET_DOMAIN,'qubes.Clefsign'],stdin=subprocess.PIPE, stdout=subprocess.PIPE) |
||||
output = p.communicate(post_data)[0] |
||||
self.wfile.write(output) |
||||
|
||||
|
||||
with socketserver.TCPServer(("",PORT), Dispatcher) as httpd: |
||||
print("Serving at port", PORT) |
||||
httpd.serve_forever() |
||||
|
||||
@ -0,0 +1,16 @@ |
||||
#!/bin/bash |
||||
|
||||
SIGNER_BIN="/home/user/tools/clef/clef" |
||||
SIGNER_CMD="/home/user/tools/gtksigner/gtkui.py -s $SIGNER_BIN" |
||||
|
||||
# Start clef if not already started |
||||
if [ ! -S /home/user/.clef/clef.ipc ]; then |
||||
$SIGNER_CMD & |
||||
sleep 1 |
||||
fi |
||||
|
||||
# Should be started by now |
||||
if [ -S /home/user/.clef/clef.ipc ]; then |
||||
# Post incoming request to HTTP channel |
||||
curl -H "Content-Type: application/json" -X POST -d @- http://localhost:8550 2>/dev/null |
||||
fi |
||||
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 20 KiB |
Loading…
Reference in new issue