Stay up to date on all things crypto and blockchain

Token Daily is a place to discover trending news and products in crypto and blockchain.

Introducing SoHo Token Labs: Advancing Smart Contract Security

SoHo Token Labs will be answering questions on Tuesday 6/12 at 1pm pst.

Launches posted 5 months ago

with or if you'd like to join the discussion.
Jonathan Haas
Hey all! Delighted to be here. I've spoken on Token Daily before, but I really love the platform. Happy to answer any hard-hitting questions you may have about what we're working on, and how we intend to better benefit the smart contract security world.
1
soona
What do people get wrong about smart contracts/the audit world?
1
Jonathan Haas
@soonaorlater Great question! I think a lot of auditing teams have done people a disservice in tooling — many focus on their next generation analyzers while forgetting one of the most important ones — the brain! We’re looking to get around that by making it far easier for our vulnerability research engineers to write rules to detect vulnerabilities — just like how an antivirus works :-)

We don’t think humans will ever be fully removed from the process — but making their jobs as easy as possible is our goal!
2
Elissa Shevinsky
@soonaorlater @Jon_A_Haas I’m glad Jonathan mentioned this, because it’s so important. Even the best automated tools should be supplemented with human expertise. Expert auditors will catch issues that automated tools miss.
0
Dennis Stücken
What kind of report can one expect to receive from your auditing process?
1
Jonathan Haas
@dstuecken Hi Dennis -- our auditing process focuses on incorporating a number of elements, and it largely depends on what is being audited. Contracts that need certain levels of interoperability, for instance, may require a deeper threat modeling overview.
1
Jonathan Haas
@dstuecken @Jon_A_Haas I've thought a bit about how to respond to this more cohesively, largely given the blog post I made today (https://blog.sohotokenlabs.com/2018/06/12/standards-smart-contract-security/)

To answer, we're trying to figure out the correct answer to that for the entire industry, but we know right now what is included in ours.

Ours details a number of steps (those which I've disclosed in a post a bit further down) but they largely relate to determining a few key aspects: what is the contract trying to do? How is it trying to do it? Is the way by which it is attempting to do it in a secure manner?

These can be broken down into a few further steps.

For instance:
What is the contract trying to do: Is this an ICO? Is it a protocol of sorts? What level of specification is attempting to be met? Does a white-paper or similar exist?
These questions are superb at determining what is in the report. We'll be sharing more details on one of our first clients soon, but in their case, they're doing quite complicated things with smart contracts that would differ quite heavily when compared to a standard ERC-20 ICO.

What does the threat model of the contract look like: Where are trust boundaries? How does information flow? Where is information stored?
These are standard questions inside any audit for traditional application security, but they're important to ask. Even with everything in the open, it's vital to clarify where trust boundaries and similar aspects are. By understanding where data is flowing or being held at any given point (who is impacting this variable? how?), one can get a better understanding of how to protect it.

Which toolsets or platforms were used: e.g. Did the contract use Truffle, Eth.Testing, Smart Contract Factory Contracts?
All vital questions to ask. By gaining a better understanding of what someone is utilizing to create their contract, we can gain a better understanding of which pitfalls they may have encountered. Developing smart contracts is hard, and securing them is often even harder -- when one develops with security in mind from the start, it reduces quite a bit of the structural difficulties one may encounter upon more comprehensive review (outside of traditional unit testing).
0
soona
1
Elissa Shevinsky
@soonaorlater Song is correct - smart contract security is (currently) very challenging for most developers. Jonathan and I would like to simplify this process (we’ll release more details about our product roadmap later in the summer.) His post also highlights the importance of good auditing tools + having experienced application security experts reviewing the code and relevant scans.
1
Jonathan Haas
@soonaorlater @ElissaBeth I noted a number of these aspects on Twitter, and I'm in agreement with much of the sentiment of the post. Smart contract security is difficult -- immensely so. Look at the simplicity in crafting a hello world in something like C or Python. It's relatively rudimentary, easy enough to explain to a non-technical individual, and can be broken down conceptually. While Solidity (and most of the programming languages which allow for interaction with the EVM) is not inherently not these things, it certainly has a much higher learning curve.

I'd like to get to a state where heavy amounts of application security knowledge are not inherently necessary to produce good code -- and that's [email protected] and I are trying to capture. Making it easier for any individual to utilize smart contracts will (we believe) not only drive their adoption, but drive far more in the space with technical advances. If you look at the sheer number of individuals who quickly picked up far more complicated development after being exposed to a relatively short-term computer programming class (as many public schools in the United States now offer as part of their curriculum) -- the amount is staggering. Enabling people to use a technology enables the technology just as much as it enables the people.
1
Sam Campbell
A few questions for you:
1. Can you please describe (at a high-level) the diligence checklist that you look for in a smart contract audit?

2. What are your plans (if any) to publicly review popular smart contracts?

3. Is there a site or platform you recommend for issuing ERC20 tokens that is cost effective yet secure?

Thanks!
1
Sam Campbell
@Jon_A_Haas Thank you, Jonathan! Very helpful! In regards to my third question- I was referring to a site that will create a "factory" contract. For example, I played around with Hexel (https://www.onhexel.com/) to create a token for educational purposes only.

Have you found any reputable "factory" contracts or thought about issuing an industry standard? Understandably, it's difficult to design without the intent behind the token's purpose.
2
Jonathan Haas
@campbellcapital @campbellcapital I actually worked at Snapchat around the same time the Hexel Founders did -- and went through the same YC W18 batch during my tenure at Quantstamp -- quite a small world!

The premise of a factory contract is appealing to many -- they're relatively quick to utilize, and can create various contracts with a simple exchange of funds (whether ETH or a token of their choosing). That noted, the security flaws these contracts can inherently produce is rather scary -- especially those without any way to upgrade. While there are a few methods to "upgrade" a smart contract (utilizing two smart contracts and a series of pointer contracts, if you will), I've yet to see any smart contract factory utilizing these. This presents a pretty scary premise, as any time the smart contract factory is out of date, they're actively going to be producing vulnerable smart contracts -- definitely not cool for customers (or their customers, by proxy).

We're definitely interested in establishing an industry standard, and doing so in a way that is both secure and simplistic. We've hinted at it quite a bit in our materials, but if something is difficult to use -- people will find a way around it. Such is the case with most security counter measures. Think of your password screen -- often times, if your password needs to be lengthy and confusing, you may find a shortcut to get the minimum viable password in. Smart contracts are the same for many -- because security is so lengthy and confusing, many have taken shortcuts to get to a minimum viable state of security.

It's the intent of our company (and our products) to change this. By making things not only secure, but simplistic as well, we remove this logical gap. We drive creation of secure smart contracts from the start -- not after all the code has since been written.
2
Jonathan Haas
@campbellcapital Fantastic questions, Sam.

1. The diligence checklist highly depends upon which side you're coming from -- it's a two way street, and many forget that. In order to get the most value out of a smart contract audit, an organization looking for an audit should come prepared with a few answers to the following questions:
- What are you trying to trying to achieve? While this question may seem a bit dull, a quality audit will not only ensure your contract is secure, but ideally that it does what you intend.
- How did you build this? When it comes to having a satisfactory audit, many steps can be skipped by following industry standards for creation. Using heavily vetted codebases like OpenZeppelin are useful in this case, as is using the Truffle framework. Many audits include extensive testing.
- Did you write this, or did someone else? While not always necessary to know, having access to the relevant individuals is hugely beneficial during scope of audit.
- Is there a whitepaper or specification? Much of the tooling within smart contract security focuses on adherence to formal specification. By having these instances pre-defined, it's much easier to create a specification to compare the smart contract against.

So in summary: what is the intent, usage of tools, who wrote it, is there proper documentation around it.

2. We intend to do this on an ongoing basis, and we've got an internal tool doing this right now. One of the things we've realized is that any time we're seeing heavy transaction volume that seems to be an indicator of compromise, one should instantly research into it. Taking the time to delay hours or minutes could be catastrophic. While the monitoring aspect is still relatively rudimentary, it's how we do ongoing vulnerability research and have an idea of attacks occurring in the wild.

3. Depends heavily on your definition of issuing -- is this going to be a site that is going to create them for you? Or in the sense that it would allow for sale? In terms of creation, that's a tricky area. Creation of smart contracts is something we're heavily focusing on, but there's unfortunately a number of players in the space who do so via very scary ways. Many focus on having a smart contract "factory" contract, which given ETH or a relative token will produce a new smart contract. While this can work, these factories are by nature smart contracts (and by nature immutable) -- so they are susceptible to producing flawed contracts down the line.
1
Elissa Shevinsky
@campbellcapital @campbellcapital We've been thinking about this question (industry standards) quite a bit. We just published a post this morning about the importance of creating industry standards (and our interest in working with other auditors to make this happen.) As Jonathan notes in his reply, automatically generated contracts are only as good as their inputs. We're certainly interested in smart contract generation, and are working on ways to develop those tools with better outputs (producing more secure, simple, contracts.) Here's our post from earlier today: https://blog.sohotokenlabs.com/2018/06/12/standards-smart-contract-security/
1
Bryan Myint
Hi! Bryan at Republic Crypto here. Really like your product and its definitely serving a need. How do you guys stack up against other companies that are providing smart contract audits? What is the differentiator?
0
Jonathan Haas
@bryanmyint Fantastic question!

Audits for us are primarily serving as market research -- giving us insight into how and why people unknowingly may introduce vulnerabilities to their code. Our primary focus is actually building out a way to securely develop smart contracts from scratch -- which we're slowly sharing more details about as we go along! (And we'd love to talk further about -- but those details we're keeping under wraps!)

In terms of our pure audit differentiation, we're two individuals who are incredibly skilled in application security, in addition to development experience and knowledge of smart contract auditing. While there's a number of teams who have some combination of these teams, relatively few have all of them. For those that do have all of them, we're countering through the development of our own static analyzer -- one which makes it incredibly easy to write rules. Think of how a signature-based antivirus works -- it looks for a piece of something and says "Hey, I think I found thing X!". We're looking fairly similarly, making it easy for developers and security engineers alike to write rulesets which can help sniff out vulnerabilities.

Hope that answered your question!
0
X