[FIP-14] BD-2041 Wallet sync, BP schedule verification, and API query Design for FIO API Security

Owned by Ed Rotthoff
Last updated: Jan 18, 2021 by Eric Butz
4 min read

 

Purpose:

The purpose of this document is to communicate various details associated with the https://fioprotocol.atlassian.net/browse/BD-2041 story. This document will list the various end points necessary to achieve this approach, along with various interaction diagrams intended to illustrate the approach.

 

Overview --

This approach has been created to increase the level of security for read operations within the FIO Protocol. Presently the protocol is vulnerable to man in the middle attacks. The man in the middle could intercept any requests to API nodes (by taking over the API node, or by intercepting the traffic to the api node on the network) the man in the middle could inject any data desirable (funds request public address info, or pub address info for fio address mappings) to redirect funds to the hackers desired addresses, thus stealing funds.

We propose a 2 operation process to be used by clients which should help to ensure the security of read operations on the FIO Protocol.

The first operation is called “syncing the producer schedule”. Clients of the FIO API will collect a list of valid producers offline, this list will be combined with the block number associated with when the list was collected, to permit the client to sync the producer schedule after this block number. Periodically during releases the client will update its list of valid producers as well as this block number, and this will minimize the time spent by the client performing syncing of the producer schedule. Clients of FIO will be able to query, and validate the list of block producers that are active in the FIO Protocol. Clients will query the FIO Protocol history node for the list of BP schedule changes that have been performed. The client will use block info and BP pub key information provided in the response. The client will get the block in question and validate the block information and signing (see below). This will provide validation of the block producer schedule and BP provided api nodes which will be used to query the FIO chain.

The second operation is called “querying the FIO Protocol”. The client will update the list of BPs and BP api nodes as the user interacts with the wallet. For critically important FIO Protocol read operations (like get pub address, get fio requests”, clients will query API nodes published by these block producers. By querying 2/3 + 1 (or 15) of these BP run API nodes, the wallet can then compare the results and determine if the results have integrity, as well as performing the validation of the response by ensuring it is signed with the BPs public key.

We will next describe the FIO state tables, API endpoints, and wallet based structures required to implement this approach.

Added State tables --

producers – add the apinode attribute. this will permit bps to record the url of the api node they are running

History modifications – modify the history node to provide an index of the changes to the producer schedule. also add a new history endpoint get_producer_changes.

get_producer_changes – this history endpoint will return a list of block producer schedule changes that occurred after the specified block number, the block number, api node url, and pub key of the new producers, associated with each block producer schedule change will be returned..

API Endpoints --

Register_BP_API_url – This request will be signed by the BP account, it will set the apiurl attribute on the producer_info record associated with this producer in the producers table.

Contract actions –

regapi – a new action permitting BPs to register the API node url they want users to use.

 

 

History changes --

The FIO history node will be modified to build and maintain an index of BP schedule changes, it will capture the schedule changes and also the block numbers BP pub key, and api node url, associated with these changes (it might also be useful to capture the block info for these schedule changes to save a call for clients performing validations).

 

Client Considerations--

Clients will invoke a new endpoint on the FIO history node to get_producer_schedule_changes.

Clients will then get the list of blocks from this call and they will validate cryptographically that the block is valid using a process similar to this:

The process of verifying is:

  1. Gather information used to build the block digest:

  a. get a hash of the unsigned block header
  b. create a sha256 hash of the producer schedule
  c. get the block merkle root <--- where we run into problems ...

  1. Create the block digest:

  a. First digest: concatenate the header hash, and block merkle root, and get the sha256 sum
  b. Second digest: concatenate the first digest and the schedule hash, and get the sha256 sum

  1. Use the signature and and block digest to derive the signing key.

  2. Check the schedule for the signing keyI’ve tested this and it works fine.The problem is getting the merkle root after finality (stored in forkdb only temporarily) I haven’t figured out how to derive it from other on-chain data yet. This article makes it sound possible: 

https://steemit.com/eos/@dan/inter-blockchain-communication-via-merkle-proofs-with-eos-io, but in contrast it seems that this is a problem for IBC, essentially having the same underlying needs for lightweight verification, eosSweden mentions it here: https://medium.com/@eosswedenorg/provide-up-to-date-snapshots-to-support-ibc-and-history-nodes-3b8f7160f1b8

 

The client will verify the block then use the schedule to update the list of BPs they will use for interactions with the API nodes.

The wallet will then use thequery strategy indicated above in “querying the FIO Protocol” to query information that is deemed sensitive for the FIO Protocol (get pub address, get FIO requests).

TBD – the process of validation listed above needs to be fully defined before this document can be considered completed.