David Schwed founding director of the Cyber Security Program at the Katz School at Yeshiva University appeared on Episode #83 of Task Force 7 Radio this week, with host George Rettas, president and CEO of Task Force 7 Radio and Task Force 7 Technologies, and Co-host Tom Pageler Chief Security Officer of BitGo, Inc. to talk about security concerns in a blockchain.

The biggest threat to blockchain-based assets is on the client side – either a man in the middle or JavaScript vulnerability, according to David Schwed, a professor and founding director of the Cyber Security Program at the Katz School at Yeshiva University.

“At the end of the day, you have the public key and the private key that's securing this digital asset,’’ said Schwed, who was the guest on episode 83 of Task Force 7 Radio, Monday night with host, George Rettas. “I think there still needs to be a lot of work done on the client side. Whether it's protecting those private keys or whether it's ensuring that the information that is being entered into the transaction is legitimate.”

There are different ways to protect private keys, which are used to sign a transaction and then transmitted to the blockchain, explained Schwed, who has also worked in the financial services sector for a number of banks. That is what effectuates the transfer of those assets, he said. “That private key is really what needs to be protected,’’ and there are different protection methods.

Hot or cold?

Rettas asked Schwed to discuss some of the methods to achieve secure cold transactions versus hot transactions. If time isn't of the essence for a transaction, a cold wallet transaction is the best approach, Schwed said.

At its core, there is a system connected to the internet, someone needs to initiate a transaction, such as if he were to send Rettas 100 bitcoin, for example, Schwed said. “This transaction is not transmitted to the blockchain yet because it needs to be signed by my key, which again, is stored in a wallet.”

Then he would remove the transaction off that system, which, in theory, could be compromised, he said. Continuing the scenario, Schwed said it could be brought over to an air gap machine, which is not connected to the internet. On that machine, Schwed said, he would sign that transaction with his private keys. Once signed, he would remove it from the air gap computer, bring it back to the computer that's connected to the internet, and then transmit that transaction.

“Assuming for the sake of this conversation that all of that has been ritualized, and it's been legitimate,’’ he noted. “There's not a great opportunity for compromise in that sense because that machine is not connected to the internet. That's not always the case where … time is of the essence, and you need to make a transaction.”

See related: "How to Measure Cyber Risk on Your Digital Assets"

This is especially true when looking at institutional trading, he said. “That's where you have to get into different types of hot transactions and that's where the security really comes into play because you're talking about machines that are connected to the internet.”

Personally, Schwed said when he conducts a transaction he “always default to cold” because he can ensure that his private keys are never exposed to an internet-accessible PC.

Rettas and Schwed were also joined by TF 7 cohost, Tom Pageler, the chief security officer of BitGo. Pageler agreed that cold wallets are better for securing transactions but questioned whether it is a matter of having a policy in place to combine the hot and cold – into what he said he’d call “a warm wallet.”

Schwed said he agreed 100% with that premise. “I think a lot of security does come down to policy” as well as keeping money on the exchange. “I know of companies, and I know of people that will keep a majority of their funds in custody on an exchange when in reality, you and I both know that, that's not your wallet. That's essentially a shared wallet."

Security concerns in a blockchain

Rettas turned the conversation to asking about unaddressed security vulnerabilities in a blockchain.

The main issue is “poor cyber hygiene,” Schwed said. Your wallet could be secure, but if you copy and paste someone’s bitcoin address and there is malware in your computer, you risk sending a transaction to someone you didn’t intend to send it to.

And, he noted, “these transactions are immutable, so it's gone. You can't recall. It's not a wire that I can call the bank, and have it pulled back, it's gone.”
As more people and organizations adopt crypto currencies, there are more avenues for exploitation of vulnerabilities, Schwed said, “because a lot of these new wallets that are popping up are definitely not tested and probably not secure.”

In response to a question from Rettas about the challenges he faced protecting the API keys for exchange connectivity, Schwed said whether you’re building an EMS or OMS system that's going to be connected to different exchanges, you are integrating with different services. This means having to utilize API keys that sign the transaction to tell the exchange to permit this trade or do a withdrawal.

“You have to ensure that this one API key is as secure as you can possibly make it, because if you lose that API key or someone is able to get that API key, they have full access to whatever funds you have.” It is critical to ensure that that key is encrypted at rest as well as encrypted in transit, he said.
Hardware security modules (HSM) and the ERC-20 standard

Rettas asked Schwed to explain the differences between how bitcoin effectuates multi signatures versus how ERC-20 does it with smart contracts?

“At a very simplistic level, the bitcoin protocol will allow for a multi signature,’’ Schwed said. That means if you have an asset on the blockchain you want to send someone you need to sign in with a private key. But you can build into the blockchain protocol that you want to utilize multi signatures, in which case you would need two or three keys.

See Related: "Cryptocurrency ‘Fueling’ Ransomware Incidents"

ERC-20, he said, is essentially a standard used for smart contracts on the Ethereum blockchain or all the tokens that sit on the Ethereum blockchain are ERC-20 compliant. “The way it's effectuated is, you're essentially building this smart contract and the smart contract will say, ‘Don't send funds and unless two or three … signatures or keys sign this transaction.’"

Although to the end user, it appears to be the same thing, it's two different technologies, Schwed added. You’re relying on the ERC-20 programming language to say there’s a requirement that someone has to sign a smart contract, he said.

“You could get into faulty programming, if you will, on the smart contract side [because] not all the vendors will do it the same way. Or somebody could do it themselves, or somebody could write a vulnerability in the smart contract.”

Pageler agreed, saying that with ERC-20, you're relying on smart contracts that are “pretty much developed by each person individually. Whereas, with bitcoin multi signatures … it's written in there.”

Rettas asked Schwed for his thoughts on Secret Sharing versus multiparty computation (MPC). Schwed said he prefers MPC. He also explained that Secret Sharing is a concept that takes one key and breaks it up into different pieces. This gives someone the ability to store the keys and in different locations, he said.

“That way there's somewhat of an assurance that while this key is stored at rest, it's not stored in one place.” From a physical security perspective, someone would need to break into three different cloud vendors in order to get the key, he added.

The downside, however, is those keys need to be reassembled at some point in order to sign the transaction, Schwed added. But this reduces the ability to exploit a vulnerability.

Cloud or on-premise blockchain?

When it comes to the type of blockchain model to deploy, Schwed said he prefers a hybrid approach.

In certain instances, if an organization is using a cloud infrastructure and wants to secure its API keys, he said he might keep that on prem.

“That way, it's under my physical security … from an encryption standpoint, but the rest of the infrastructure that's signing the transactions and it's interfacing with the exchanges, I may keep in the cloud.”

Rettas point out that there has been a lot written about people losing money in public blockchains and asked Schwed if he would “trust $100 million with this technology?”

Noting that that was a “loaded question,” Schwed replied that he would, as long as it was “done properly,” meaning there is transparency in the blockchain, as well as in the protocols and the type of encryption.

Schwed also pointed out that “there's probably not one major financial institution that hasn't been in the news for some data breach,” and said that even then, people feel their money is still protected regulatory perspective.

“I think, at the end of the day it's the same thing here … as long as you have all the custodians, and the funds are insured, and it's regulated and there is government oversight, I think you'll see onboarding of the institutions.”

But Rettas said if that’s the case, what is preventing institutional investors from adding cryptocurrencies to their portfolios today?

Schwed replied that most institutions don’t want to be the first, “so they're waiting to see who else jumps into it.”

All the major banks are also developing their own custodial solution, he said.
Pageler added that a big piece of it is that banks are constantly looking at their risk modeling and try to see how much they want to take on. There is also the issue of volatility, he said, but “as regulations come in, as more people come into the space [and there are] more acceptable use cases,” adoption of cryptocurrencies will become more widespread.

The ‘Task Force 7 Radio’ recap is a weekly feature on the Cyber Security Hub. To listen to this and past episodes, click here.