Blockchain Technology



Blockchain Technology

Financial technology (Fintech) has a long history of innovation, but there have been interesting changes now that Bitcoin has demonstrated the possibility of having a trustworthy system even when dealing with untrusted parties. It has taken Bitcoin quite a few years to earn the level of trust and acceptance it has today, but it serves as an existence proof that this level of trust is both technical and socially possible. This is what the altcoins and other blockchain technologies are banking on. They want to be viewed as being secure and trustworthy just because they share some things in common with Bitcoin, such as a distributed ledger.
Filecoin allegedly raised over $257 million despite the fact that Storj, Sia and MaidSafe already had working products for distributed data storage on a blockchain. It’s unclear why investors chose Filecoin. Perhaps they feel that there needs to be big money behind a technology so it can be promoted and become the dominant solution in the marketplace. Maybe they have looked into the others and saw technical issues and believe the team behind Filecoin won’t fall victim to the same. Whatever the reason, there’s clearly a lot of excitement about “the blockchain.”
With all this excitement comes risk. The Securities and Exchange Commission (SEC) has already warned of the pump-and-dump and market manipulation scams. However, there’s more risk than just intentional fraud. There is also the risk that the security of these blockchain technologies are not up to snuff. As seen with the DAO exploit, there are subtle technical issues which can drain $50 million in a matter of hours. While that was rolled back in a highly controversial rewriting of history known as a hard fork, the problem of contracts being incredibly complicated and difficult to write as well as analyze continue to cause problems in Ethereum, such as the $31 million multi-signature hack (which would have been $150 million had benevolent hackers not jumped in to mitigate the damage). Whether these bugs are intentional, as a way to steal money, or just accidents which are exploited by others, it’s clear that determining if these smart contracts are secure or not is still a difficult task.
Another cryptocurrency, IOTA, which has a market cap over $1 billion, was vulnerable due to the fact that they developed their own hashing algorithm which did not stand up to differential cryptanalysis. In this case, it was discovered by researchers at Boston University and MIT, so it was kept secret until a fix was deployed. Had it been a malicious attacker who had discovered that they could forge signatures and steal people’s money first, it may have been another headline about millions stolen due to security issues.
Meanwhile the CoinDash hack was just a website being hacked with the attacker changing the address to send funds to themselves. The result was a $7 million payout for defacing a website. Similarly, there have been many exchanges which have been compromised over the years whose vulnerabilities had nothing to do with the cryptocurrencies being stolen.  Mt. GoxBithumbBitstampBitfinex, and Bitcoinica are just some of the examples of the theft of wallets.
So if you’re interested in either developing or investing in these new blockchain companies, how do you figure out which ones are secure and which ones are not? Unfortunately, it’s not an easy task, as is evident by the stream of news of successful attacks.
For investors, first, heed the warnings of the SEC. Research the company and the key personnel. Beware of vague or nonsensical terms or using undefined technical or legal jargon. For example, if you are told to “accept these features as given, [so] you do not have to worry about the underlying technology” when discussing security critical features, it should be a warning sign. Maybe it’s legitimate, but either way it probably warrants further investigation before taking a risk on it.
For the people pioneering these projects, make sure both the design and implementation have been reviewed by security professionals who have a wide variety of experience. Getting the world’s best cryptographers will not save you from a Cross Site Request Forgery (CSRF) which allows an attacker to empty users’ wallets. Only getting an expert on web attacks might yield the opposite problem, such as the hash collisions and signature forging from IOTA. Having the design reviewed before anything is built results in less re-work, so this should be done early if that is an option. The people reviewing your system should be mapping out all the different ways that your security objectives can be violated. In other words, how money can be stolen, property can be transferred, people can store files without paying and so forth. All of this analysis should be run by you as it is in progress. It should be a collaboration, with everyone working towards the same goal: to get the security guarantees that the product owner desires.
It’s also good to keep in mind that this doesn’t necessarily mean “perfectly secure.” For example, most Bitcoin wallets do not intend to be secure from someone stealing your device (computer, phone, tablet, etc.). They acknowledge this and generally inform the user that it’s their responsibility to keep their wallet file safe. At the same time, there are wallets which require a password to unlock the wallet, for those who feel this is a threat they need to protect against. The point is to make sure that the security guarantees are understood and explained to end users in a manner which makes sense.
It will be interesting to see if people start crowdsourcing security audits of these systems. This is something we’ve seen with the TrueCrypt audit and to some degree with testing the security of Apple’s TouchID (which was slightly different in that it was only paying someone if they break it, not to determine whether or not it was secure). While large investment firms can just hire people to look into the security of a product before investing in it, this would give the same option to smaller investors.

Popular posts from this blog

New Old Bugs in the Linux Kernel

Automated Struct Identification with Ghidra

SOHO Device Exploitation