We use a simple 6 digit PIN to protect our assets in Mixin Messenger, those wo don’t know the technology behind this design believe it is not secure. This article is to demystify how does D3M-PIN work in Mixin Messenger to prove this simple PIN is both secure and convenient, as a decentralized wallet.
What is D3M-PIN
D3M-PIN is the abbreviation of Distributed Multiparty Mobile Mixin PIN, unlike traditional 6 digit PIN in central applications, D3M-PIN is a distributed PIN technology secured by three parties with different roles.
The three parties are User(U), Trusted Account Manager(M) and Trusted Distributed Ledger(L). Three parties cooperate together to avoid single point failure in all roles, to be both decentralized secure and convenient.
User is typically a true human who uses Mixin Messenger, or some bot code, and they are not connected with any specific devices. The duty of User is remembering their 6 digit PIN securely, easy enough for them. This PIN is part of the whole private key, and it is the most import part.
Trusted Account Manager provides SMS verification code and connect User with another part of the private key. The centralized Mixin Messenger servers cluster is a typical Trusted Account Manager.
Trusted Distributed Ledger is a public permissionless distributed ledger runs in Trusted Execution Environment, e.g. the PoS-BFT-DAG ledger of Mixin Network. The ledger makes the final multisig private key of User.
Every Mixin Messenger User owns a multisig private key of Mixin Kernel, we will use the assumptions and definitions below to simplify the procedure:
- L has a total of n nodes, and we assume the multisig private key of U requires all signatures of these n nodes, and these nodes remains permanent.
- Li is the Kernel public key of node i, and li is the corresponding private key.
- PIN is the secure 6 digit password, and it remains permanent.
- Hs is a deterministic hash function, without collisions.
- I is a standard UUID randomly produced by M to connect with a unique User.
- m is a private key owned by M, and it remains permanent.
- Fs(a,X) is the EdDSA signature function, it produces the signature on message X by a.
- aG is the corresponding public key, if a is an EdDSA private key.
With the above assumptions, a standard D3M-PIN transaction sequence goes as follows:
- The first time U uses Mixin Messenger on a new device, they get their connected account number I through the SMS verification code of M.
- For each node in L, M produces a seed
si = Hs(I || m || Li), result in n total seeds.
- For each new seed si, M sends a Mixin Kernel transaction Ti to its public key siG.
- M sends back these n seeds and corresponding transactions Ti to User’s device and persisted in the device storage. U may choose to backup all si.
- If U uses Mixin Messenger for the first time, they needs to spend the transaction Ti with si to ensure the seed is used only once.
- For each node in L, U produces a private key
ui = Hs(PIN || si || Li), result in n total private keys.
- For each private key ui, U produces signature
Si = Fs(ui,Hs(Li || "COMMIT")), then sends Si and public key uiG to node Li.
- Li verifies signature Si, responds error or send back a new public key piG, with
pi = Hs(uiG || li).
- After U receives total n new public keys, they gets their integral multisig public key in Mixin Kernel,
P = p1G + p2G + ... + pnG.
- Whenever U sends a transaction T, they produces signature
Si = Fs(ui,Hs(Li || Hs(T)))for each node, and sends Si and uiG to Li.
- Li verifies signature Si, responds error or send back a new signature
Si = Fs(Hs(uiG || li),Hs(T)).
- After U receives total n new signatures, they gets their complete multisig signature for T as
S = S1 + S2 + ... + Sn.
In the workflow above, there is one most important part is that each node _Li_ does strict rate limit to every signature verification request.
Security Proof of D3M-PIN
We will analyze the possible risks of D3M-PIN workflow, and prove that this technology is robustly secure and decentralized. Because User and Ledger are already both secure and distributed, we will only analyze the Account Manager.
If there is only one M, if it stops working, are User’s assets still accessible?
Yes, of course. At first, before M stops business, it will notify all Users to download user data, and Users have enough time to backup all their seeds si; Second also the most important, after User connects with M and gets si, they can continue access their assets without any interactions with M; Finally, User can backup all their si at any time, thus User can send transactions or change devices at any time despite M running or stopped.
If User lost access to their phone number, are User’s assets still accessible?
Yes, of course. At first, M allows User to set up an emergency contact, whenever a User lost access to their phone number they can get their all si through their emergency contact; Second, most people can go to ISP to get back their phone number access; Finally, like the analysis in question above, User already have si in their device and can backup them at any time, thus User can send transactions or change devices at any time despite phone number access.
If someone else got the access to User’s phone number, are User’s assets still secure?
Whenever an attacher gets the access to a User’s phone number, they actually gets the User’s si. So why not we just assume the attacker is M, it’s obviously that M has all Users’ private key seeds.
Because M don’t know the PIN of User, and PIN has a total of 1,000,000 possibilities. Assume L has typical 30 nodes, and the node signature verification rate limit is 5 times per day. Then it takes about 1000000/30/5/365 = 18 years to brute force all these possibilities.
And in a typical D3M-PIN implementation, there are random iterators stored on User’s device, it will decrease the possibility to brute force the PIN to zero, unless the attacker also get the access to User’s device.
In summary, D3M-PIN is robustly secure and is the most convenient distributed technology to protect crypto assets.