In recent weeks the topic of address security has become a top concern for active vulnerabilities in blockchain protocols.
As the conversation and investigations continue to grow in the industry, we believe it is important to explain Aion’s approach to address design and the security considerations.
This post serves as a high-level summary of Aion’s address design.
Designs from Ethereum, Bitcoin and Lisk
The address model utilized by Bitcoin and Ethereum have high-level similarities. They involve a seed, a private and public key pair, and an address derived from the public key. This address is derived using a/or a combination of hashing functions and truncating to arrive at an address of a specific byte size. In the case of Bitcoin and Ethereum this address is 20 bytes in binary (40 bytes in hex).
Another approach, most notably utilized by the Lisk project involves a similar process of hash functions, however, only the last 8 bytes (16 bytes in Hex) of the final hash are taken as the address.
Bitcoin: 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM (Hex — 40 bytes)
Ethereum: 0x4CEdA7906a5Ed2179785Cd3A40A69ee8bc99C466 (Hex — 40 bytes)
Lisk: 3040783849904107057L (Hex — 16 bytes)
The design approach of Seed -> Private Key -> Public Key -> Address creates the opportunity to discover the preimage of any address by performing an intense amount of computational operations — meaning the discovery of another key pair as an input to that address. The difficulty of this operation depends heavily on the size of the address. In addition, if key pairs are not bounded to addresses the preimage discovered can be used. This was demonstrated in the recent security threat with Lisk. (Seek link below)
In the case of Bitcoin and Ethereum the size of the address (20 bytes) results in the computation (2¹⁶⁰) to discover the preimage of a specific address to be feasibly impossible, therefore no key to address binding exists.
In the case of Lisk, using the final 8 bytes of the hash as the address results in the computation (2⁶⁴) of the preimage to be feasible and key pairings are unbound until a transaction occurs.
Please read through Kudelski Security’s research for additional context and all the investigation details on the Lisk vulnerabilities.
For all three of these protocols, the derivation of an address from a public key creates the risk of preimage attacks. Presenting the potential for another key pair to correspond to the address. In the case of Bitcoin and Ethereum, at an address length of 20 bytes — this is highly difficult. However the risk still exists.
Our Design
The design of the Aion address has a fundamental difference from Bitcoin, Ethereum and Lisk. Instead of deriving an address from the public key, the address is the public key.
Aion: 0x03d18b1b285927c29c5dc4f3129005a096cda6cabeaaa2815b1ab48342e8b174 (Hex — 64 bytes, binary — 32 Bytes)
Overall security benefits
Reducing the complexity of the address structure removes the risk of a preimage attack as there is no derivation between the address and the public key. In addition, there is no risk of key binding vulnerability as no such binding exists.
Seed -> Private Key -> Public Key / Aion Address
As you can see above, this results in a significantly longer address that will sacrifice ease of human-readability and certain storage considerations. We however made the decision that security was of the primary importance. It is anticipated that naming services such as ENS will help address human-readability in the future.
Another common element of the key generation process in many protocols is the use of a seed to create the key pair. The integrity of the seed source is critical for the security of the key pair. This risk was recently demonstrated in the theft of IOTA from certain individuals accounts who used online seed generators. To establish a Aion key pair, users will generate a seed on their local machine using secure random sources. Aion will not create or support any online seed generators.
While Aion addresses are not vulnerable to the preimage attack or key binding vulnerability, the risk of a collision occurring in the key pairing still remains (as it does in Ethereum, Bitcoin, Lisk etc).
Specific Key Pairing Collision in Aion: 2²⁵⁶
Kudelski Security’s Research: https://research.kudelskisecurity.com/2018/01/16/blockchains-how-to-steal-millions-in-264-operations/
Please feel free to engage on our forum with any questions, comments or suggestions — https://forum.aion.network/t/aion-address-design-security/70
