Web 3.0 Blockchain Security Insights:
Side-Channel Attacks and Transaction Pattern Analysis
Web 3.0 Blockchain Security Insights
Exploring Side - Channel Attacks and Transaction Pattern Analysis
Welcome to our comprehensive guide on Web 3.0 blockchain security. In this section, we delve deep into the critical aspects of blockchain technology, focusing on the emerging threats and vulnerabilities.
Our primary focus today is on side-channel attacks - a sophisticated method used by attackers to extract sensitive information - and transaction pattern analysis, where we analyze the flow and structure of blockchain transactions to detect potential risks and anomalies.
Join us as we explore these key topics, offering insights and strategies to enhance the security and resilience of your blockchain systems.
1, Let’s deepen our understanding of the properties of keys and the differences in how they are used.
This paper provides a detailed explanation of the structural aspects of vulnerabilities to side-channel attacks in blockchain technology.
First, it focuses on the necessity of including information required for script decryption within the blockchain. This necessity is crucial as it is indispensable for verification by other nodes, and thus cannot be omitted.
In other words, by design, the blockchain must include transaction information, including scripts, that is accessible to all nodes in the network and is publicly available to third parties. Because this information is openly available to anyone, there is a possibility that specific attackers may exploit this public information to execute side-channel attacks. This paper discusses how these characteristics can lead to potential attack risks through theoretical analysis.
By the way, let's examine the typical use of public keys. In public key cryptography used for authentication on Linux and UNIX systems, public keys are stored internally on the server. In this context, the public key is used solely to verify that the party possesses the private key corresponding to the public key during authentication. Therefore, there is no need to expose the public key information to the outside.
In other words, third parties do not need to know the public key of a specific server. The authentication process only requires providing the server with a signature generated by the private key and verifying whether the signature is valid or not. Thus, there is no necessity to publicly disclose the public key itself for this purpose.
In this way, the blockchain has the necessity of recording and publicly leaving the public key on the chain, and it must always be made available to third parties.
2, Let's take a look at the actual transactions.
Now, we are actually conducting an investigation on the Bitcoin mainnet. This is because we need to carefully examine the counterparty's actions, which cannot be adequately done on the testnet. Therefore, we are conducting the investigation on the mainnet. As shown in the block explorer at the URL below, there are currently several transactions where the balance has dropped to zero. These balances did not reach zero due to normal transactions.
In fact, the coins were moved without the need for a private key. Some of these transactions experienced a delay of several minutes before the coins were moved.
Let's start by reviewing the transactions verified in 2023.
https://live.blockcypher.com/btc/address/1C6x9PqHbYg5AdhqTSKSZBv9jPZqoL5fB8/
https://live.blockcypher.com/btc/address/1EoQBcoki6NjowfrGUzSkQCVft25t66XrH/
First, let's look at these two. We tested them by turning a "certain feature" of the blockchain ON (above) or OFF (below). When the feature was ON, the coins were immediately stolen. You can see that transaction, right? In contrast, when the feature was OFF, more than a year has passed, and the coins remain safe (below).
https://live.blockcypher.com/btc/address/1HtZeYQtzbNdVdHRGZK7NgL3XzWqwdsxpt/
https://live.blockcypher.com/btc/address/1De6AKwwDZmrPx3HKDjh8F6XYSRBGQQWRx/
Now, let’s move on to the next point. Both of the two transactions mentioned above were stolen. The first was stolen in about 10 minutes, and the second was stolen instantly.
The key point here is that earlier, I mentioned that the transactions would not have been stolen if a certain feature of the blockchain had been turned off. However, these two transactions should have been harder to steal than the one that was not stolen. Therefore, the first transaction took about 10 minutes to be stolen, rather than being stolen instantly. Yet, it was still stolen.
For this test, we used a balance of 0.0001 BTC. Even such a small amount was stolen. By the way, the transaction itself doesn’t change much in terms of computational effort (transaction size) even if the amount of BTC increases, because it is determined by the number of scriptPubKey that you yourself can unlock.
In other words, whether it’s 1 BTC, 100 BTC, 4500 BTC, or even 210000 BTC, the same kind of theft would occur in a single instance with this type of transaction.
3, Examine blockchain transactions that meet certain conditions.
While developing the transaction, we realized that it is possible to create a situation where the properties of the transaction can be in the same state, as shown in the image above. After all, blockchain transactions are hashes of inputs and outputs, so we thoroughly examined which parts of the parameters specifically affect these aspects in detail.
Now, take a close look at the diagram on the right above. If you think about it carefully, you should be able to imagine what it means for something to be in the same state. There are elements that are nicely aligned along the timeline, aren't there?
In this case, since the same state results in the same hash value, which in turn results in the same txid, the double-spending prevention mechanism should reject it. We thought the same. However, some parameters can be changed. Since these parameters affect the hash that governs the txid, the txid changes, effectively disabling the double-spending prevention mechanism.
And then there is the possibility of this coincidence occurring. If it is astronomically small, it would not be a problem, but in environments with a large number of transactions, it cannot be dismissed as a negligible probability (we estimate that the odds could be similar to being involved in a plane crash). Therefore, we suspect that this phenomenon might be one of the causes behind incidents where coins suddenly move and disappear, even though strict management (such as cold wallets) was implemented at exchanges and other institutions with high transaction volumes.
4, Let's take a look at the specific hacking address.
The following addresses are believed to be collecting Bitcoin through this type of issue. In other words, hackers who are aware of this issue have issued transactions on the Bitcoin mainnet that can be moved without a private key, and the collected Bitcoin is recorded in these addresses. The reason for this assumption is that the 0.0001 BTC we placed for verification purposes is included in these addresses.
https://live.blockcypher.com/btc/address/bc1q9kwy7g79vcf09nfl3dzs2wqv9fecme6rn7s7jm/
However, the 0.0001 BTC we placed for verification purposes are not all the same. We have adjusted them to understand the hacker's situation and computing power. Honestly, we did not expect the 0.0001 BTC in this case to be stolen. The fact that even this small amount was stolen indicates that this hacker has thoroughly grasped the issue and likely possesses a computer with significant computing power. As evidence, approximately 0.34 BTC has been collected. They have then moved all of it to another location.
In the end, hacking incidents related to this issue are reported by media outlets like Cointelegraph when the amounts involved are significant, such as in cases where exchanges are affected. However, smaller amounts like these are being stolen without any media coverage. Considering that this hacker alone has conducted 48 transactions and likely possesses many other addresses, it is believed that the full extent of the damage remains unknown.
5, A specific 'pattern' exists.
Now, let's examine the details of the recent transactions. Based on our previous analysis, we have reviewed multiple transactions, including their computational complexity, to assess the situation. The results are shown in the following URL. Upon inspection, only one transaction has moved, while the others have remained in their original positions.
https://live.blockcypher.com/btc/address/1CKxHkcpb1jivsgtL8BdwbEVWc95RVLfN2/
From this, we can infer, as predicted, that a specific "pattern" exists. As a hypothesis, we assume there might be a pattern where "transactions occur without a private key." As shown in the following URL, this hypothesis applies to only one out of the three cases.
Therefore, it can be concluded that transactions move according to a specific pattern only when such a pattern exists.
On the other hand, a very similar pattern is observed in the central scriptPubKey. This scriptPubKey remains in its original position despite being similar to the transaction that moved. Based on this difference, it is possible to formulate another hypothesis.
6, Technical Consideration of Small Probabilities that May Occur and Those that May Not.
When considering security, it is important to evaluate both cases where an event with a small probability "occurs" and where it "does not occur." Generally, if the number of possible combinations exceeds 2^128, the probability of any one of them actually occurring is extremely low, and it is considered "unlikely" to happen. However, if the number is reduced to something like 2^64, while the probability remains very low, it is interpreted as having a "possibility" of occurring. In such cases, security measures need to be designed accordingly.
7, We will formulate a hypothesis based on the similarities.
Let's examine this alternative hypothesis. Additionally, the scriptPubKey at the bottom remains unused, which means it is still in an unspent state at this stage. Therefore, we will explore the similarities between the central scriptPubKey and the bottom scriptPubKey to construct a new hypothesis about why the central scriptPubKey remains.
Here, we define the top scriptPubKey as α, the central scriptPubKey as β, and the bottom scriptPubKey as Γ. Both β and Γ are unused scriptPubKeys, and although they resemble α, which was moved by a hacker without a private key, they remain unspent. We will examine the similarities between β and Γ, as well as between α and β, and α and Γ. Since they all derive from the same structure, their similarities are significant. However, only α was moved without a private key, which is the most critical point.
From this, we can formulate the following hypothesis to explain why β and Γ remain despite having similar structures:
"When a specific form is achieved, it becomes possible to manipulate it with a certain computational complexity, making it a target for hackers."
Based on this hypothesis, further analysis can be conducted.
8, Monitoring of Frequently Changing Transactions
This process involves observing the dynamic state of transactions that are updated and generated in real-time within the blockchain network. Each transaction is organized into new data blocks at regular intervals and propagated across the network, resulting in frequent changes in transaction details and status. Consequently, continuous monitoring of transaction state transitions is required, particularly in high-throughput environments, where swift processing and analysis are essential.
Consideration of Locations Where Frequently Changing Transactions Occur
It is necessary to examine where frequently changing transactions are likely to occur. These transactions tend to occur less frequently in individual wallets or small-scale services. On the other hand, in environments where transactions are conducted at a high frequency, such as cryptocurrency exchanges or staking pools, transactions are frequently generated and updated, leading to rapid changes in transaction details and status.
Analysis of Locations Where Coin Theft Is Likely to Occur
Next, we will examine the locations where coin theft is likely to occur. The most reliable approach is to refer to actual incidents that have taken place in the past. Typically, the places most prone to coin theft are cryptocurrency exchanges, staking pools, and large-scale cryptocurrency wallet services. These locations manage significant amounts of assets, making them attractive targets for attacks, which has led to the widely accepted view that coin theft frequently occurs in such environments.
However, whether this view is entirely accurate requires further observation based on the hypothesis presented in section 7. By reevaluating the background and conditions under which coin theft occurs through the lens of this hypothesis, it may be possible to reconstruct our previous understanding.
Reconsideration of Factors Leading to Attack Targets
Here, we shift our perspective and re-evaluate the conventional view that "the management of large amounts of assets makes an entity a target for attacks, leading to frequent coin theft." Instead, we propose that "the sheer volume of transactions being processed is the factor that makes an entity susceptible to attacks, drawing the attention of hackers."
In other words, cryptocurrency exchanges, staking pools, and large-scale cryptocurrency wallet services become attack targets not due to the size of the assets they manage, but because the high frequency of transactions invites attacks. Based on this view, the frequency of transactions, rather than the volume of assets, should be considered a key risk factor.
Insights into the Results of Large-Scale Transaction Occurrences
Based on the considerations from sections 1 to 7, we will conduct a detailed analysis of what happens when a large number of transactions occur. As a result, two new findings have emerged.
First, although the theoretical probability of certain events is extremely low, with the population mean being close to zero, there is a possibility that, in a vast number of trials (i.e., the number of transactions), the occurrence of an otherwise negligible "zero" may be observed. In other words, phenomena that are typically considered unlikely in regular transactions become a tangible risk when dealing with a high volume of transactions.