In an evolving blockchain ecosystem, the number of bad actors and exploiters grow, one could experience some fear or paranoia around interacting with strangers in the terrifying internet.

In this short article, we will explore a few ways to equip yourself with the necessary tools to fend off any potential attacks and keep your keys/system secure. This handbook will encompass a few protective measures, including:

• Key Storage
• Wallet Security
• Ephemeral Execution Environment
• Making Smart Decisions

Our exploration will dive into the Ethereum blockchain system and associated tools and technologies.

Key Storage​

One's key(s) is an essential component to interacting with the blockchain and an incredibly valuable piece of data that should be well guarded. Safeguarding these keys should be prioritized and those keys should always be used with caution.

A simple way to start is choosing how one's private keys are generated. Opt for offline generation to ensure that the process remains concealed from prying eyes and potential data breaches. An offline private key generator, such as this one, guarantees the confidentiality of your private key. Additionally, consider exploring the SLIP39 protocol — a mnemonic (private key) generator leveraging Shamir Secret Sharing to divide the seed phrase into multiple shares.

These private keys, or mnemonic - a list of 12 or 24 words, must be safeguarded and should never be lost or stolen. You may wish to physically write down your private key/mnemonic on a piece of paper, which is called a "paper wallet". It is imperative to never lose this piece of paper and take precautionary measures, such as buying a safe to store it in. The best way to protect your keys is to generate them offline on a dedicated computer/device. This computer/device will never connect to the internet and be "air gapped", which will further shield your keys.

Alternatively, entrusting a reputable wallet application with your key management is another option. Beware that certain wallets are "custodial," implying that they possess ownership of your keys, while merely providing access to it via their platform. Opting for a "non-custodial" wallet provides greater autonomy, granting you full control over your assets by exporting one's private key. As the saying goes, "not your private key, not your coins".

Among various "non-custodial" wallets, ZenGo, Torus, Argent and AlphaWallet stand out. Particulary, the most technologically inclined for protection is ZenGo. This is due to the its MPC (multi-party computation) as well as the "social recovery" feature.

There are also different types of wallets such as hot wallets and cold wallets. Any keys used to continually connect to the internet and make frequent transactions would be a "hot wallet". "Cold wallets" would refer to stored keys that are not connected to the internet and are rarely used, such a Ledger and Trezor. For highest security, both should be used. The cold wallet should hold longer term assets that do not need to be transferred frequently and the hot wallet should have minimum funds (perhaps, up to the amount one would be willing to lose).

To note, there is actually a vulnerability for the Terzor T. Additional information can be found here. Due to this, it is recommended to use another model offered by Trezor, or taking extra precautions in physically securing the device.

Wallet Security​

So now that you have a wallet, does that mean it's secure forever? Most likely not... However, there are a few ways to make sure your wallets are protected. Let us explore some important strategies for proper and ongoing maintenance.

1. Asset Monitoring: Employ monitoring tools like such as tenderly and OZ Defender to track wallet addresses and associated assets. These will will help in checking wallet address(es) and you may optionally configure notifications for any activity on those address(es). Alternatively, a blockchain explorer can be used to view your address.
2. Approval Management: When interacting with tokens, there is a process by which you allow "approval" for another address to transfer the corresponding token. This is a necessary step when minting/burning/transferring tokens. However, there are plenty of times a contract will request "indefinite approval" for any amount of tokens. These are especially dangerous if the contract has malicious intent. Utilize tools such as revoke, unrekt, orzapper to manage "approvals" for all of your addresses.
3. Key Rotations: Regularly rotate your keys to enhance security. While there is no particularly fixed schedule for key rotations, the more frequently you do it, the more likely your keys will be secure - granted they are generated in a secure manner. Key rotation involves generating a new key and then transferring your previous assets to the new key. Though execution costs may be a deterring factor in the frequency of key rotations, it is still an important practice to exercise.
4. Adding Canary Tokens/Accounts: For the ultra-cautious, there is a great tool to provide insight into potential breaches. Canary Tokens generates a dummy file and it can be given an obvious name, like "privatekeys.txt". The file will then keep track of who accessed the file, when it has been accessed, and from where. This is a great way to ascertain if your computer has been compromised and if there is anyone lurking that could potentially cause you harm. To get started, you can follow this quick guide.

Ephemeral Execution Environment​

A great way to ensure that all web3 interactions are safe would be to setup a brand new environment. This will account for any potential malware or undetected bad-actors that could be present in your current system.

One way this could be done is by creating a VM (virtual machine) - ideally a dedicated machine. This will be used solely for any blockchain activity. This will guarantee a clean working environment and can foster some peace of mind. Another benefit to this type of setup is that if anything anomalous occurs, you can always tear down the VM and build a new one again!

A very useful article for getting quickly set up and get started is available here. Bear in mind, this article does not go through security in detail (e.g. networking security) and should be considered when following the article.

Making Smart Decisions​

People are prone to making mistakes, but rarely do they make a royal one. When it comes to protecting your assets, however much, there is nothing more important. Minimizing errors is crucial, as actions within the blockchain are immutable.

A very common problem for blockchain users are phishing scams. Some are relatively easy to catch, and here are a couple tips on how to avoid them. Firstly, never click any links (especially if they're phish-y) in emails or strange websites - supplemental information can be found here. Secondly, do not send tokens to any address(es) that are unkown or unverified. Along these lines, be aware of who you are interacting with online (whether username, email, etc.). If an email or DM was sent by a a funny looking email/username, one could deduce that it is most likely a scam.

Another tip is to go deeper into the code. If able, one should try to examine the protocol's codebase and make sure that it is public and verified. This will help with making informed decisions when interacting with a smart contract. Although this may be a far more difficult security practice, there are other simpler ways such as ensuring a protocol has received an audit.

Conclusion​

While this article offers a succinct overview, I hope it goes through some useful tips to be more security-centric. As a now-informed reader, delve into further research and tread cautiously in the dark forest.

If this article was helpful, please let us know and make a request! There is a number of things that could be added or further expounded on and could possibly be in another article. Thanks for the read and stay (Chain)Safe.

Originally posted on Medium

Cross-chain applications

Interoperability solutions have shown great promise in unlocking the potential of decentralized applications in our emerging multi-chain ecosystem. However, due to the high volumes of digital assets and critical data flowing across them, blockchain bridges are amongst the most targeted protocols in the web3 space. This leaves researchers hunting for more advanced security designs.

Multi-Party Computation (MPC) is one of the most interesting potential solutions. Secure MPC represents a powerful next step in digital asset security because it eliminates the risks of a single point of compromise.

Instead of relying on Multisig and other (older) ways of key management that either expose relayer identities or introduce exploitable single-points-of-failure, relayers would run a secure MPC ceremony each time a user wishes to bridge funds or transfer arbitrary data.

In this way, MPC enables multiple parties to carry out a distributed computation on their secret inputs without revealing anything but the output.

This concept has been studied by academia for decades. Still, it’s only due to recent technological advancements that it has become viable for real-world applications like Sygma, the interoperability layer for building cross-chain applications.

Let’s unpack how MPC works, what makes it unique, and why we choose to adopt it.

Threshold cryptography: deep dive

Threshold Signature Schemes (TSS) is an area of MPC that we will focus on today. It’s particularly useful for crypto as it facilitates the distribution of a private key to multiple parties, introducing redundancy into asset management security.

In other words, it enables a set of parties to perform certain cryptographic operations, like signing transactions, while none of them holds a full private key. Instead, the key is split across the parties and can only be used when a subset of them — the size of which is larger than a certain threshold — combines their key shares.

Thanks to the homomorphic properties of the underlying scheme, a fully formed private key doesn’t ever need to exist. “Homomorphism” is just a fancy mathematical way to say the operations you can perform on the unencrypted (plaintext) values, like addition or multiplication, will behave identically on the encrypted (ciphertext) ones.

You can imagine the benefits of this for privacy.

For example, a user sends encrypted financial data to the server, and it responds with an encrypted credit score that only they would be able to decrypt. If that sounds interesting, see this article for more details and this library if you want to tinker with it.

An example

Imagine you have a secret key sk and a special algorithm that can divide this key into n pieces such that $[sk_i]$ = share_key($pk, n, t$). Imagine now you want to sign a transaction m, so you apply a similar algorithm to get partial signatures $[s_i]$ = sign($m, [sk_i]$). Now, to reconstruct a valid signature, you would simply sum all partial signatures together $s = s_0 + s_1 + … + s_i$ and call it a day.

You might’ve also noticed a third argument t when we shared our key. Although the key is shared between n parties, we only need a threshold number of them to actually sign something. This is akin to a multisig scheme, which interestingly is just an emulation of threshold signatures using a high-level smart contract language like Solidity.

Of course, multisigs come with a cost where one would pay miners to process each call to the multisig contract. Conversely, threshold signatures are processed off-chain, and only a single compact ECDSA signature needs to be transacted on-chain once. Furthermore, such a signature won’t leak anything about its signers, which secures them from targeted attacks and is great for privacy.

When discussing security, MPC algorithms generally provide guarantees based on the threshold number of corrupted parties a system can tolerate. This places TSS in a unique position, as such schemes present the control of their robustness directly in the developer’s hands. Furthermore, this allows it to withstand even the dishonest majority — an extreme state where adversaries can corrupt all but one participant.

You may already know about the blockchain’s Scalability Trilemma and the Interoperability Trilemma of the cross-chain ecosystem. Let’s introduce a third one for the MPC domain — the Threshold Trilemma. Below are the three properties that MPC protocols try to maximize but can only have two of at the same time:

• Risk minimization (robustness): the higher the threshold value set, the harder it is for parties to collude against the system, e.g., forge a signature.
• Fault tolerance (liveness): the lesser the threshold value compared to the total number of parties, the more unforeseen failures such a system can tolerate, e.g., a peer accidentally going offline.
• Performance (latency): the more parties the system employs, the more decentralized, secure, and reliable it would be, but at the expense of increasing performance overhead due to MPC’s high communication complexity.

Generally, protocol engineers prefer to minimize risk first and then balance liveness and performance based on the chosen threshold. However, it’s essential to base the threshold calculation on concrete metrics, such as the number of collateral nodes would have to stake or the amount of computation work needed for participation.

One last trick that can present an even greater degree of confidence in threshold cryptosystems is their unique “Key Reshare” mechanism — which allows parties from the old set to rotate key shares with new participants without changing the underlying public key. This is useful to onboard new members into the signing committee, but more importantly, it prevents hackers from corrupting parties one after another, potentially in the course of many sessions (known as proactive adversaries).

Applications of TSS in blockchains

There are many ways TSS is used today. Keyless wallets like ZenGo or Torus are making a more convenient and secure alternative — no more paper-written mnemonics or cloud-backed keys are needed. Instead, the wallet provider’s server/nodes would actively cooperate with the user to sign transactions.

The folks at Chainlink are using thresh-sigs to efficiently and verifiably aggregate data for their oracle network. Even some rollups like Skale Network are flirting with this technology, although instead of ECDSA, they use BLS signatures that require less MPC-intensive setup due to their elliptic curve pairing properties.

Probably the biggest beneficiaries of the TSS are a new generation of custodian services led by Fireblocks and Entropy. These companies aim to disrupt the way big institutions and foundations operate their escrows and treasuries.

Finally, threshold cryptography has great promise for various cross-chain applications. While designing Sygma, a new vision of cross-chain interoperability, we became convinced that having MPC for relayer communication will not only strengthen the overall security but also significantly reduce fees making the user experience much smoother.