Keyless wallet
署名対応の秘密鍵を一切生成せずにトランザクションを送信するWallet。
クライアントのニーモニック管理が必要ない
ソフトウェア的、暗号学的なアプローチ
秘密鍵を人類が使うのは早すぎる
クライアント型
パンピーにニーモニックさせる？できる？
サーバー型・カストディ
取引所を中心に痛ましい事件の数々
カストディ側のコスト・責任が重大
ZenGo
https://gyazo.com/346dab2c998e995f25bf738df44950e9
閾値署名を利用したkeyless wallet
クライアントとサーバーでマルチシグにしていてどっちかの鍵が流出してもヘーキ
Tx送信には両方の署名が必要
他のウォレットとの違いは？
デフォルトでマルチシグ
ニーモニック管理などは存在しない
マルチシグカストディ（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に保存
ServerはSecret share自体を知ることはない
デバイスなくしたり、壊したりしたら...
icloudから暗号化secret shareをダウンロード -> ZoOm認証で復号鍵取得
https://gyazo.com/2a72edf71d5e191a16469c01cbf31b12
サーバーサイド
もう一方のsecret shareを持つマン
secret shareを暗号化するための（バックアップ用）暗号鍵をサーバーに、それを復号するための復号鍵をEscrowに。
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
もしサーバーにアクセスできなくなったら？
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準拠ではない。