Keyless wallet
署名対応の秘密鍵を一切生成せずにトランザクションを送信するWallet。
クライアントのニーモニック管理が必要ない
ソフトウェア的、暗号学的なアプローチ
秘密鍵を人類が使うのは早すぎる
クライアント型
パンピーにニーモニックさせる?できる?
サーバー型・カストディ
取引所を中心に痛ましい事件の数々
カストディ側のコスト・責任が重大
ZenGo
https://gyazo.com/346dab2c998e995f25bf738df44950e9
閾値署名を利用したkeyless wallet
クライアントとサーバーでマルチシグにしていてどっちかの鍵が流出してもヘーキ
Tx送信には両方の署名が必要
https://zengo.com/how-zengo-guarantees-access-to-customers-funds/
https://zengo.com/a-deep-dive-into-zengo-guaranteed-access-solution/
https://zengo.com/biometrics-in-zengo-wallet/
他のウォレットとの違いは?
デフォルトでマルチシグ
ニーモニック管理などは存在しない
マルチシグカストディ(2-of-3で取引所に2つ、BitGoに1つとか)と何が違う?
イーサなどのビットコイン以外にも対応
Bitcoin, Ethereum, BNB, Libra(testnet)
カストディ権限だけでユーザーの資産は動かせない
ユーザー側のウォレットもハックされねば
マルチシグってなんだっけ?
いろいろある
ビットコインscript
Bitcoinだけに対応、プライバシー欠陥(通常TxではなくマルチシグTxであると第三者から分かる)
Locking Script
2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG
Unlocking Script
OP_0 <Signature B> <Signature C>
イーサリアムマルチシグコントラクト
オンチェーンコントラクトでの管理
マルチシグの参加者をTx送信でコントラクトに登録して、それ経由で他の関数を呼び出すことで実質マルチシグ
シュノア署名
鍵ペア(a, A), (b, B)に対し署名が$ \sigma_a、$ \sigma_bとすると、$ A + B = C、$ \sigma_a + \sigma_b = \sigma_cが成り立つようなイメージ。Cも通常の署名としてワーク。
まだBTCに取り込まれておらず。対応してるのはBCH, zilliqaとか?
Threashold Signatureってなんだっけ
2/3 以上の署名があればOK的な
今回の文脈だと閾値であるよりも複数署名が必要なことが重要
BLS署名が有名
non-interactive!
Pairing, HashToCurve, Side-channel protection, HDKDなどなど安全性的にまだハードルが
そもそもそのBlockchain自体がBLS署名に対応しなければ使えない
Threshold ECDSA
MPCベースのECDSA
複数人の署名が必要なECDSA
複数間で秘密鍵を持って、互いに秘密鍵を明らかにすることなく、協力してinteractiveに署名生成
なので、ふつーにBTCでもイーサでも使える
概念自体は昔からあったが最近新しいpaperがでてきて効率性ageage。
https://gyazo.com/1c0d8376bbb21c48e3f495602e610342
BitGoもクライアント<->BitGo serverのマルチシグ対応してるが、スクリプトベース。
なので、ETHなどコントラクトマルチシグなので鍵管理は発生してる。
Zengo
Secret Share管理はThreashold署名でクライアントとサーバーに。
Tx送信時はinteractiveにやりとりしてblockchainにブロードキャスト。
一方のSecret shareが流出しても署名を作れないのでTxは処理されない。
それぞれのshareをなくした時の対処
クライアント側
暗号化したsecret shareをデバイスとiCloudなどにバックアップ
復号鍵はZengoServerに保存
FaceTecのZoOmっていう顔認証
ServerはSecret share自体を知ることはない
デバイスなくしたり、壊したりしたら...
icloudから暗号化secret shareをダウンロード -> ZoOm認証で復号鍵取得
https://gyazo.com/2a72edf71d5e191a16469c01cbf31b12
サーバーサイド
もう一方のsecret shareを持つマン
secret shareを暗号化するための(バックアップ用)暗号鍵をサーバーに、それを復号するための復号鍵をEscrowに。
EscrowTech
Escrowの復号鍵に対する署名検証
Trustee:Zengoサーバーモニタリングしてるマン
appointed a law office (JRG) as trustee. The trustee’s role is to check and report on ZenGo “proof of life,” composed of both legal and technical criteria.
サーバーサイドのSecretShareは暗号化されクライアント側でも保持。
https://gyazo.com/24e66f7e4a4e9223e1cf2c385d2248f4
もしサーバーにアクセスできなくなったら?
A Deep Dive into ZenGo Guaranteed Access Solution
Github
https://gyazo.com/25004b9f71be699c9b621a4768d3e6dd
Decryption Keyのデータをぶっ壊した絵
https://gyazo.com/1755e4ad1fa14f38a2ad969813ac9d36
まとめ
ふつーのウォレットと何が違う?
ニーモニック管理しない
マルチシグカストディ(2-of-3で取引所に2つ、BitGoに1つとか)と何が違う?
ビットコインだけでなく、イーサなどのマルチプラットフォームに対して同じロジックで適用可能
それぞれのユーザーのウォレットにあるsecret shareも必要なので、bitfinex事件みたいに取引所だけから秘密鍵が流出することはない
カストディ権限だけでユーザーの資産は動かせない
サーバーは何を持ってる?
一方のsecret share
サーバーsecret shareの暗号鍵(復号鍵は持たない)
暗号化したバックアップ用のクライアントsecret shareの復号鍵(ZoOm認証のみでアクセス可能)
クライアントは何を持ってる?
一方のsecret share
暗号化されたサーバーサイドのsecret share
もしサーバーのsecret shareが流出したら?
サーバーが検知した段階でアプリからの送金できないように
Rotationする(署名対応の公開鍵は変えずにそれぞれのsecret shareは変更)=> 流出secret shareは無効に
結局、secret shareは守らねばならぬやつなのでカストディ業?
まだ新しい技術で安全性的に大丈夫?
中身の個々の技術自体はよく知られているもの
実質zengo実装だけなのでもっと他の実装も必要
階層的鍵導出はできる?
Yes。ただ、BIP32/39準拠ではない。