Taiwanese wallet KryptoGO comments on Edge wallet private key leakage incident, guiding users on assessing security.

This article is written by KryptoGO

Edge, a cryptocurrency wallet provider based in California, USA, discovered a vulnerability in its application that resulted in the loss of 2000 private keys. Although the lost amount is less than five figures in USD, the vulnerability could easily expose users to risks. Edge has released a new version and urges users to update as soon as possible.

Why was the private key of this wallet leaked?

According to the official explanation, using the Buy or Sell options within the app will store the unencrypted private key in the device's log. If the log is then uploaded using Edge's log upload feature, it will be uploaded to the Edge server. If the log is uploaded right after a Buy or Sell action, it will include the private key.

Since the wallet app can access the user's private key, there is a risk of leakage if the unencrypted private key is stored anywhere. In this case, the app accidentally stored the unencrypted private key in the device's log and uploaded it to the cloud through an automatic backup mechanism, leading to a security breach.

Is this a common mistake? Why did this app make this mistake?

Mainly due to inadequate peer code review during the development phase, resulting in poor code quality. In theory, for a hot wallet, the plaintext private key should not exist outside of the memory.

How can users determine which decentralized wallet is more secure?

The safest way for a wallet app is not to store plaintext private keys/mnemonic phrases on any storage device but to store them encrypted. Furthermore, it should ensure that the code does not record any logs or files when operating the private key. From a user's perspective, the evaluation can be based on whether a hacker who steals the phone can extract the private key from it. If not, then it is considered secure enough. Users can pay attention to the wallet provider's description of the "App's internal security mechanism" for evaluation:

For more details, see: Security Checkpoints for Using Wallets - Taking KryptoGO Wallet as an Example - KryptoGO Blog

Did KryptoGO Wallet have this issue in its design?

KryptoGO uses iOS Keychain and Android Keystore to encrypt and store AES-encrypted data.

The AES encryption algorithm is an advanced encryption standard in cryptography that uses symmetric block cipher with a minimum key length support of 128, 192, 256, and a block length of 128 bits. This encryption algorithm is the block encryption standard adopted by the U.S. federal government to replace the original DES, and it has been widely analyzed and used worldwide.

Operation principle of AES:

For our method of encrypting mnemonic phrases, this formula shows how we encrypt the mnemonic phrases (not fully disclosed to avoid unnecessary attack surfaces), and all transmission stages are ciphertext rather than plaintext.

How to evaluate the "App's internal security mechanism"? Recommended technologies!

Since non-custodial wallets need to store mnemonic phrases, seeds, and private keys locally, understanding the working principle of local storage and common attack methods against it is crucial.

Here are checkpoints from various perspectives:

General Checks

• How does the application generate seed phrases and private keys?
• How and where does the application store mnemonic phrases and private keys?
• Is the wallet connected to trusted blockchain nodes?
• Does the application allow users to configure custom blockchain nodes, and if so, what can malicious blockchain nodes do to the application?
• Does the application use shared servers, and what information is sent from the client to the server?
• If the server stores sensitive data, how is it stored?
• Does the application enforce strong password policies?
• Does the application require 2FA or a PIN code when users attempt to access sensitive information or transfer tokens?
• Does the application use vulnerable third-party code libraries?
• Are there any confidential leaks in the source code repository (e.g., API keys, AWS credentials)?
• Are there any obvious poor coding practices in the code repository (e.g., cryptographic abuse)?
• Does the application server enforce TLS connections?