SCSA Member Spotlight: NRI Secure

SCSA Member Spotlight: NRI Secure

NRI Secure is a Japan-based Cybersecurity company which also provides blockchain security services. It is part of Nomura Research Institute (NRI), a leading global provider of system solutions and consulting services.

We sat down with Teruhiro Tagomori, NRI Secure’s senior security engineer to learn more about the company’s foray into blockchain technology and get their take on the blockchain security space.


Please tell us about yourself and NRI Secure

My name is Teruhiro Tagomori, I am a senior security engineer at NRI Secure, a cybersecurity company based in Japan and the U.S. Our services range from cybersecurity consulting and managed security services to software development.

I developed the blockchain security services including the smart contract audits offered by NRI Secure. And my contributions to the blockchain security space also includes two books I’ve written (in Japanese) on smart contract security and key management for Ethereum and Bitcoin.


Can you share a bit about your background? What drew you to blockchain and how did you get involved?


Originally, I was just a software engineer, developing software applications. Later, I moved into a security engineer role as a penetration tester. In 2016, the DAO attack showed that there were big security issues in the blockchain space. A huge amount of funds was lost. Since smart contracts can’t be modified after deployment and are publicly open to the internet, I saw that security vulnerabilities in these contracts could have a huge impact. That’s why I developed services focusing on smart contract security.

Many companies in Japan were trying to use blockchain technology in their businesses but they didn’t know that the smart contracts themselves also have certain security risks. That’s why I published books to promote smart contract security in Japan.

In 2017, more vulnerabilities in already deployed smart contracts were exposed to the public. I wanted to help the public understand the importance of smart contract auditing, so that’s about the time we started formally promoting and offering smart contract security services.

How did you start your blockchain work at your company initially?


In the beginning, it was just out of curiosity. I was investigating smart contract security by myself. In 2017, our client tried to start a blockchain business. They requested us to run only the conventional security penetration tests on their applications. I knew that there were likely risks with their smart contract, so I strongly recommended that they let us perform penetration testing on their smart contracts as well. That was the first time we provided smart contract services. 

Although it was still at an early stage, it was clear to me smart contract auditing was a business opportunity. After that, we officially launched the smart contract auditing as a service in Japan. The industry didn’t really exist in Japan at the time. We were a first mover in the space.


How has your company evolved in your work as the blockchain space has matured?
And as a follow up, what services are you providing now compared to when you started?


After launching smart contract audits, we developed two services; system architecture evaluation to prevent unauthorized transactions of transferring crypto currency and executing smart contract. 

In addition to attacks on smart contracts, there were many attacks that illegally sent cryptocurrencies by stealing blockchain private keys. For this reason, we have applied the know-how we have cultivated over many years in penetration testing and consulting services to the blockchain security space beginning with providing a form of architecture evaluation. In addition to the cryptocurrency businesses, key management of private keys and countermeasures against fraudulent transactions are essential for any business that uses smart contracts. However, when thinking in the context of preventing fraudulent transactions, it is a short-sighted idea to consider only key management. Since fraudulent transactions can be done without stealing private keys, they must be evaluated at the architecture level. 

It is also important to monitor the smart contract for attacks and vulnerabilities after deploying the smart contract. That is why we started providing monitoring services.

I believe these three services: smart contract audits, system architecture evaluation, and monitoring, are critical for businesses using blockchain. 


In your opinion, what are some of the biggest challenges right now in blockchain security?


Auditing services are very important, but the current way of doing auditing is not optimal. Currently we’re evaluating smart contracts by proof-reading the code manually, sometimes using tools like Mythril. I think this is not sufficient. We must focus more on implementing mathematical code checking methodologies by applying formal methods. We must treat smart contracts like we do critical hardware, such as in the aerospace industry. Even though there are many tools already, like MythX; which I also contributed to as a developer. Currently, there are not enough formal verification services. I think It is good that several speakers at Devcon5 emphasized the importance of applying formal method to smart contracts.

As an active user of blockchain and smart contracts, we still encounter many pain-points with the technology today. What are the roles of standards today, and which standards do you think would be especially useful for companies building more and more sophisticated systems?


Broadly speaking, smart contracts themselves, applications that use smart contracts, and the preparation against attacks after they are released will be important.

Beyond the importance of smart contract security, common vulnerabilities of smart contracts have been organized along with best practices online, you should refer to them. However, since there is no such thing as an acceptance criterion for making a deployment decision, I think decision criteria policies and the checklist that includes items such as completion of auditing will be required in the future.

As mentioned earlier, security for applications that use smart contracts is important. But how can we create a standard? Looking at our architecture evaluation service for example, when creating an items checklist from a key management perspective, we also refer to the key management part within the security standard, Point-to-Point Encryption (P2PE) defined by the PCI SSC from the credit card industry security standard. In developing security standards other than smart contracts, I think it is better not to create them from scratch, but to create them referencing existing excellent security standards and security expert opinions.

Finally, we will need a standard for preparing for attacks after deployment.

It is necessary to build measures based on the assumption that vulnerabilities in smart contracts will be found. For instance, it is necessary to consider countermeasures such as circuit breaker functions and design smart contracts where the business logic part can be replaced with another smart contract. These will prevent attacks even if vulnerabilities are found. However, since these measures cannot be implemented after deployment, they should be considered in the design phase. We will also need a standard on how to detect vulnerabilities and attacks, and the operational flow when detected.


What is one oversight companies often have about key management?
What would be your recommendation for these situations?


Storing the private key securely is critical. But that isn’t enough, fraudulent transactions can still happen even if the private key cannot be accessed. For instance, if I can break into server A which calls the API of server B which signs transactions with a private key from server B, I can request to sign fraudulent transactions with the private key via the API.

One more point relates to internal crime. Any key management design should include considerations of bad actors inside the host organization. We recommend designing a multi-signature (multisig) structure and making sure the organization not only has multiple keys but making sure the smart contract cannot be accessed by a single person. 

There are many perspectives to prevent fraudulent transactions. I talk more about it in depth in my thesis

Our architecture evaluation service is delivered based on those many important perspectives.


Speaking of multisig designs, do you believe multisigs are better at the smart contract or base blockchain level? i.e., Ethereum vs Bitcoin multisig models.


You may suffer from the fact that Ethereum does not support multisig at the platform level like Bitcoin. Many use smart contracts to implement multisig wallets like the parity multisig. However, deploying multisig on the smart contract level is very dangerous, I would not recommend it because it means the risk is a single point of failure with a smart contract. Multisigs are just a model of distributing the risk by distributing private keys. You can realize the same things in other ways. For instance, if the private keys are also encrypted, we can distribute keys and passwords, distributing the overall risk. I would recommend you consider other ways before you decide to use a smart contract multisig wallet.

Any closing thoughts for the future of the blockchain security space?


I believe we not only need smart contract standards but also a standard for systems utilizing smart contracts, including high-level standards that covers system architecture, operational standards, and preparation for vulnerabilities etc. We may refer to the many existing security models and apply or adjust them accordingly to the blockchain security space. I believe it will be necessary for traditional security experts and blockchain experts to form an alliance of sorts discussing blockchain security (including smart contracts) creating the standard to improve blockchain security overall.