| fip | title | status | type | author | created | updated |
|---|---|---|---|---|---|---|
14 |
Ensuring API response data integrity. |
Draft |
Functionality |
Pawel Mastalerz <[email protected]> |
2020-08-14 |
2020-08-14 |
Pending
Today, most integrators rely on a single API node (recommended to be hosted and secured by the integrator) to retrieve information from the FIO Chain. As with other chains that is acceptable for most data reads, but is risky when reading information which is then used to execute an irreversible transaction on another blockchain, such as payment public address. Specifically:
- get_pub_address returns public address for specific blockchain mapped to a FIO Address.
- get_pending_fio_requests returns public address for specific blockchain where Payee wants funds to be sent. Even though that information is encrypted, the public key required for decryption is sent along in the request.
It is desirable for payment public address to be returned to the wallet in a way, which can guarantee it has not been tempered with.
- The integrator would hard-code a list of known (BPs) and would regularly update this list with new software releases and upgrades to the SDKs.
- The integrator would query a single API endpoint (new endpoint to be implemented as part of this FIP) to receive a list of BP schedule updates and corresponding block number of when they occurred.
- The integrator would fetch the corresponding block and its transactions as well as X blocks following that block and:
- Verify that the block was part of chain signed by 2/3+1 of known BPs.
- Add any new BP to list of known BPs.
- BPs will post their API node address on-chain as part of BP registration
- The integrator would send API query to 2/3+1 BP API nodes.
- The API node would look-up the data, and return it signed with their BP signing key.
- Once the integrator receives content signed by 2/3+1 known BPs, the data is guaranteed by the consensus of the chain to not had been tampered with.
Will be defined in implementation phase.
Signing payment public address API response is considered equally critical to the FIO Protocol as signing blocks and switching signing keys already requires schedule update, which means it would be identified as part of the schedule discovery. An alternative could be to add API signing key to BP registration, but it would require fetching blocks where it was inserted and blocks following that to ensure it was signed by known BP.
- API node operators, primarily BPs, will publish their API endpoints along with public keys used to sign the Critical Information.
- The wallet developer will manually validate API endpoints and hard-code them into their wallet along with their corresponding public keys. Wallet developer would regularly update this list with new software releases and upgrades to the SDKs.
- When wallet’s user wants to access Critical Information, e.g. resolve FIO Address to public address on BTC blockchain, the wallet would randomly select X API endpoints and send parallel queries to each.
- The API node would look-up the data, sign it using their private key, and return.
- The a wallet would verify the signature using hard-coded public key and compare responses received. If Y responses matched, the information would be presented t otherwise it would not.
- This approach does not give certainty to the wallet that the information is accurate.
- It also has a boot-strapping problem. How do you get the initial API nodes and keys to the wallet. If it's posted on a centralized website, it can be attacked.
Pending
Pending
None
https://fioprotocol.atlassian.net/browse/WP-103 https://fioprotocol.atlassian.net/browse/WP-137