- 1 XTGwXQt9aq hX4ZXOJMYFA 700x423 - Behind the scene of the Ferrum Network token bridge

Behind the scene of the Ferrum Network token bridge

We recently launched our bridge between the FRM ERC20 and BEP2 Tokens. In this article we discuss our architecture and security considerations when designing this tool.

One important note here is that our token bridge is not the only one on the internet. Other projects have also created a token bridge between chains. One of the reasons we choose to write our own bridge is security. Note that this does not, by any means mean that we think other projects out there are not secure our are less secure. In fact I have looked at some of them like this one with Fantom and I think it’s pretty good and advice you to use it if you deem suitable.

The point to learn here is that security doesn’t come only from the choice of technology. To ensure the security of your systems, it is also very important to be very consistent, and keep the processes for your developers as simple as possible. That means we think very hard and carefully before introducing and new security model to our echo system.

We have a bunch of crypto services that run in the cloud and do all our signing and crypto needs. A developer that needs to encrypt something or sign a transaction will just ask for an instance of the service and use it. They won’t need to care about any configurations, how to generate or store keys, or how to protect them. The deployed services will automatically use the right config based on where they are running. This allows us to significantly simplify our security model and make it harder to shoot ourselves in the foot. Something that actually happens everyday in the industry.

Principles: Reusable Services, be paranoid about security

Reusable Services

In Ferrum, we have a complicated suit of products. From the unifyre and Kudi wallet to simpler tools such as token swap, we try to write and utilize reusable services. For example, a service that monitors ethereum Network and notifies a client that a transaction deposited some tokens into their account, is re used across all different products. Another example of a service that can be re used across products is a prayer service.

Security by design

Security cannot be an after thought. It is tempting build products first, and figure out how to secure them later, but it’s not the right approach. Specially in Crypto industry we are constantly under attack. That is why we should all be paranoid about security. That is why we are releasing Unifyre and Sub-Zero wallets.

Below are four requirements for any design from the security point of view:

  • User facing applications must never hold or have access to sensitive information. They are the first targets of attack.
  • Keys must be encrypted at rest and motion but it is not enough. But encryption is not enough.
  • No single encryption key can be used more than on a limited amount of data and keys must be rotated periodically. Master keys must be held. on secure hardware modules
  • Define isolated security zones. Communication between these zones must be done through pub-sub mechanism. Direct access between zones must be limited.

Future

Token bridge uses several parts of our infrastructure to put together a secure and scalable solution. We are working hard to. open source these bits and make them suitable for public consumption. Write documentation and re factor services to be general purpose enough that can be used by others. If your are a developer that get excited about what you just read, approach me directly. We are always looking for great developers to join us or our community.


Behind the scene of the Ferrum Network token bridge was originally published in FerrumNetwork on Medium, where people are continuing the conversation by highlighting and responding to this story.