Blockchain Security Report:
Residual memory data

The situations where cryptographic information remains in memory, etc., are as follows:

1, The heap itself after it has been freed.
2, The previous heap that remains after reallocation and moving to a longer heap.
3, Swap space.

If parts of the private key or the entire private key are mixed into such locations, there is a risk of private key leakage. Therefore, depending on the situation, we use memory cleaning or secure allocators. Memory cleaning involves inserting code that ensures the contents are erased even in an optimized state. In contrast, secure allocators not only ensure the contents are erased but also include mechanisms to prevent overflow into swap space.

Therefore, in SORA-QAI, we address memory security with the following rules.

• I. When containing the private key.
  In this case, a secure allocator is used.
• II. When not containing the private key but containing information that can infer the private key.
  In this case, memory cleaning is used.
• III. When containing the private key and waiting to be extracted.
  In this case, memory locking is used.

About Staking Consensus

Staking consensus requires the verification of an additional signature embedded in the transaction. When verifying this signature, the private key that made this signature needs to be unlocked. The timing of staking cannot be predicted. Since staking happens when the timing is right and is approved and then included in a block for the first time, it is necessary to keep the private key corresponding to the scriptPubKey being staked unlocked to be prepared for staking. Therefore, when you earn rewards from staking, you unlock your wallet for staking, right? Even though it is unlocked for staking, the private key remains in memory in an unlocked state. Thus, coins that support staking should lock the private key to prevent it from being read except when necessary. For this reason, in SORA-QAI, we have implemented a memory lock mechanism on the quantum and AI-resistant side first, which prevents memory from being read except when necessary. In the future, we will also insert memory lock processing for private keys that are on standby for staking. On the other hand, coins that are only used for mining without staking do not need memory lock because there is no need to verify signatures in the special “coinbase transaction” that occurs during mining. These can be operated with the private key remaining encrypted. Of course, even for coins with staking, if you only operate mining with the private key locked, staking will not occur. However, since coinbase transactions are still available, it is possible to operate in the same state as coins used only for mining without needing memory lock.