Prof. Dr. Karim Zerhouni, UPMC Chief Information Officer Dean of Science, American University of Central Asia kzerhouni@ieee.org
Using proof-of-work, transaction blockchains, and a web of trust built by rumor to secure services in a decentralized manner Summary: In this concept service users use a decentralized P2P network of transaction verifications side by side with a rumor-based web-of-trust to ensure secure use of online services. The originally considered service for this network is secure program running/installs, although the system should be scalable to other kinds of network interactions. Scenario for Software installs: In this scenario executables are signed by a publisher, once a user finds and downloads an executable (from whatever source) they should first request proof of work (PoW) from the publisher. Once the publisher receives a PoW request they should first query their neighbors to verify the install that the PoW is being requested on (this helps ensure their own database of this program has not been corrupted and adds to the establishment of this software into a public blockchain as a legitimate program). As long as they receive sufficient verification from their neighbors, the publisher then responds to the user with the PoW. Then the user should add the program hash into a public blockchain which is then passed on to their neighbor nodes for verification. In order to trust the program the user must receive a sufficiently long verifiable blockchain with the program embedded in it (indicating it has been safely installed many times by neutral or reputable entities). If insufficient verification is received, the user should then either reject the program or re-query the network to establish the trustworthiness of the publisher themselves rather than the program. A user can differentiate blockchain verification from good versus hostile nodes by the length of the blockchain and the report of the blockchain from established, well-connected neighbor nodes. Proof-of-work: For blockchain verification and other protocol maintenance operations, PoW should probably be in the form of CPU cycles (i.e. solving some hash-based numerical puzzle in the manner of hashcash). This should minimize the vulnerability of the system to denial of service and make other brute force attacks more difficult. For publisher-recipient PoW, a more trusted and robust system can exist by using cryptocurrency (i.e. bitcoin) micropayments instead of just CPU cycles. Micropayments should significantly erode the profit margin for malware. They will however also set a certain financial bar for program distribution. One possible modification is that the micropayment system should only be used with unknown/insufficiently-verified programs. The sum of initial micropayments then becomes a de-facto trustworthiness-audit cost of new program distribution. To bypass the need to protect against client-side monetary attacks, it may be useful to just charge the publisher this micropayment without paying the end user – essentially a system tax. General technical details: • Merkle trees used to transfer and verify integrity of blockchains • Proof of work can be used to ensure transactions verifications are legit • Public key exchange without a centralized hierarchy can support all operations with trustworthiness of keyed entities established based on number of nodes and longevity of nodes. Trust connections may be dynamic (the result of shared transactions and verifications) or fixed
•
•
based on known real-world connections (i.e. friends, family, coworkers, etc). Fixed connections should allow new legitimate entities to established some basic 'credit' in the system. The system protocols should run at a very low level preferably on hardware chip on the motherboard (just like TPM). If a hardware chip is not available then a software solution that loads before the OS would be best. At the bare minimum the protocols should run at a level similar to anti-virus software although this higher level will open the system some attacks. A user's transaction record can provide an idea of a user's activity on the network and trustworthiness by rumor can establish whether than user is active on the “real” network or just within some hostile pseudo-network with tenuous connections to the primary web of nodes.
Other scenarios: • Should all documents be verified or just programs? Many types of documents can have scripts or other embedded sections that can exploit bugs to run as code. In a similar manner to how anti-virus “realtime” protection works, verifying all files should add another level of security to the system. The drawback is the additional network traffic as well as the question of PoW. If PoW is CPU cycles then puzzles should not be sufficiently difficult to degrade the user experience. (Users would not be happy if every word document took 2 minutes to load.) If PoW is micropayments, then lag may not be an issue, but it would encourage 'lurking' behavior (i.e. users who consume documents/programs but don't publish or send out documents). Assuming emails are considered documents in this model as is intended, PoW for documents does quickly solve the problem of spam. The financial return on spam is isolated to so few users compared to the number of users the spam is sent to that spam will immediately become very unprofitable. Another way for documents to be handled is that programs should be expected as part of being considered good programs to sandbox any dynamic scriptable content and/or submit that content to the underlying program verification mechanism for the normal network evaluation process. • How should stream data be handled? Should stream data be verified in some way as well? The stream of data from online games or other interactive systems could be highly variable and unique from minute to minute thus expecting community blockchains to exist for this minute to minute stream block is not logical. Thus perhaps stream data should be verified just upon the identity of the endpoint and that verification held for the time span of the stream connection. Or the stream could be re-verified based on endpoint identity at given intervals. Other new thoughts: • The dynamic reputation / trust of an individual can be based on a blockchain of their transactions. So essentially you would have a blockchain for each user. • Each user blockchain would hash (using a hash tree) into a master user blockchain. • Each program / update / discrete-code-grouping could have its own transaction blockchain, but this blockchain hashes into a blockchain of all program blockchains (made up of all the root hashes of individual program blockchains). • Another global block chain could establish all transactions regardless of the program / document. This could be useful in establishing that one is part of the legit network as the total transaction block chain will be much larger than any hostile pseudo network webs. • Should user and program blockchains have a negative block flag? Thus others could flag users or programs as untrustworthy (a statement that would be trusted based on that flagger's own blockchain). This way someone could traverse a transaction ledger (blockchain) and get an idea about the negative and positive interactions the user has had about the system.