Navigation :
第13回議事録
概要
- 2018/05/11 8:00-9:30
- 参加者：楠，岩下，杉下，小宮山，肥後，樋田，須賀，島岡，佐藤，萩尾、松尾，上原，志茂
agenda
- Agenda Bashing, Note Taker
- 過去議事録の確認・承認
- Status update
- TF Site Publish plan
- Security WG Item
- AOB / Housekeeping
- Tasks and To-Dos
議事サマリ
agenda1 Agenda Bashing, Note Taker
agenda2 過去議事録の確認・承認
agenda3 ステータスupdate
- TF進捗：なし
- WG進捗：メインagendaにて
- リエゾン、関連団体：
- ISOのTC307のロンドン会議。来週から1週間開催
- SC27とTC307のジョイントコミッティ？を作れないか、と言うのが議題の一つ
- セキュリティにおけるドキュメントの作り方の議論がなされる。共有できることがあればこの場で共有する
- TC307委員会のロンドン会議準備会合を少人数で開催した
- セキュリティのまとめは、求められるスピード感が標準化のペースと合わない
- 国際標準を目指す前にISO以外の出口を考えた方が良いか
- JISも考えられなくはない。一度METIに会いに行こうと考えている
- 他の取引所の方も誘って良いか
- この場はTFのMtg。TF参加はBoTの承認。WGはWG co-chair の承認で参加可能
agenda4. Site Publish Plan
- 議案
- 議論
- 議事録の転記が終わっていない．コンテンツの充実はまだ．それ以外はほぼOKと考えられる
- アクセス数を見たいのであればanalysisを入れる
- 議事録は、議事要旨を出すだけにする
- 粒度感をどうするか．参加者，Agenda，要旨など。議論はbynameでは書かない
agenda5 secWG
- 議案
- 進捗：月曜にWG開催した
- 脅威とリスクの洗い出しを行っている．保護対象として秘密鍵と資産データの大きく2つに分けて検討している．
- トップダウンからと、ボトムアップから考えていく
- トップダウンで＝網羅性を考慮してリスクを整理する。客観的に説明ができるメリットがあるが，課題としては仮想通貨特有の問題はなかなか洗い出せない
- ボトムアップで＝鍵生成の乱数空間を広く、とかは、脅威からだけだと見えてこない。情報のフェーズ・ライフサイクルの観点からアプローチしていかないといけないことはWGとして認識している
- 資産が凍結されて引き出しできない問題は利用者保護として当然入れるべきだがまだ検討できていない．保護対象として入れるべきだが，対象が増えると大変になるジレンマがある
- トップダウンから、とボトムアップからでチームを分けている。
- 網羅性を持って，かつ具体性も備える二つのアプローチで進めていく。
- 議論
- 資産データの保護
- 鍵管理は、PKIの方に目が行きがちだが、資産データの管理は銀行の勘定系の元帳に相当するものであり、その管理が銀行よりも劣っているという考えはまずい。ベンチャーかどうかではなく、お金預かってんだから求められるよね、というのはコンセンサスだと思うので、資産データをどう守るか、についてもきちんと作業を進めていただければと思う
- WG内では、資産データは、何を守れていればよいのか議論できてない。例えば、顧客の個人情報はプライバシ保護対象なのは分かるが，お金についていうと、取引履歴を消失含め脅威として考えないといけないのか、あるいは、預かりの額だけあれば資産保護という点で充分なのか、などは自身たちがわかってないよね、という議論がある。それがないと、オーバーヘッドの大きい管理策を作ってしまうことになるかもしれないし、それは得策ではない。WGに金融系の知見を持っている方がいてくれると良いのだが、どう思うか
- 資産データはテーブル自体を保護するだけでなく，エンドユーザがハックされた場合の被害が甚大である部分が銀行の資産データ保護と大きく違う．引き出し上限もない。それを保護するのは、果たして標準化なのか？
- FISCの中には項目はあるが，古い印象がある．銀行は高リスク取引になるとヒトが出てくる。2人でやる、とか。仮想通貨は、銀行よりリスクが高いが，やるべき要件を押し付けても運用コストが高くなるだけ．クレカは、限度額を設けることでリスクをヘッジしている。プリペイドもそう。
- 仮想通貨は裁判できない。どうやっても返ってこない。理想郷的な、アナーキーなのは無理で、どこかで中央集権にならざるを得ない。
- 裁判によるアービトラージは期待できないし、仮想通貨のガバナンスは、ないことを前提に考えざるを得ない。
- ハッキングが横行するのは実際に手に入ってしまうから。それが犯罪を惹きつけている。機運が高まっているのだから、何かあると良い。取引所がアライアンスをちゃんと組んでいてNGアドレスを共有している、とか。
- ユーザーへの啓蒙
- 消費者は保護されるもの、ということになっているが、利用者がちゃんとやったら取られない。甘々な利用者が引っかかって取られている。そこの意識の低さはどこでやるべきか。教育することが取引所の責任になっているが、セキュリティガイドラインで、ユーザにも責任があることを言った方がよいと思う
- 国だと利用者を守れない、というのがアナーキーな仮想通貨の現実。消費者といった瞬間から守らなきゃ、となる。銀行のオンラインバンキングと同じく事業者がかぶる覚悟でやれ、という話に突き詰めるとなりかねない。そうではなく、テクノロジー的に利用者に責任が生じるのが当たり前、というのをどう伝えるか、どう教育するか
- 説明責任がある程度でもよい．教育をしているなど。資産データはユーザのセキュリティに依ってしまう。取引所には限界がある
- 仮想通貨特有の要件
- 破壊的な攻撃があった場合にどうするのか．銀行は残高を示すものだから命をかけて守っているが，そのガチガチさがないように見える．
- セキュリティ標準だから資産データの保護をしないといけないことは言うべき
- ユーザーがハックされるリスクは、他よりでかい
- 銀行などは、一度に動かせる金額を絞っている．上限を設けていることが歯止めになっている
- 特別な要件を出す必要はない．銀行などと同じ基準に準拠すればよい。仮想通貨交換事業者は、現状FISCの安対基準はチェックしてないのではないか。仮想通貨のためじゃないし、主にレガシー向けではあるが、銀行には本当に変えられないレガシーな部分が残っている。そこを抜き身にしちゃうと怖いという感覚がある。
- マルチファクターでやればよい、という幻想があるが、メールに送る、アプリで受け取るのでレベル感違うし、アプリでもどこに保存するかで段違い
- マネロン、疑わしい取引
- マネロンの手口でやすいコインをわざと高く買うなどのテクニックが見られる．
- 文書構成
- このTFで全部背負うのも重いよね。タスクを分割して，ロードマップを書いて抜けを見ていくのが現実的
- 今のドキュメントが、ISO27001のトップダウンのアプローチ。個別になると、フロントエンド，コールドウォレットなど，各論でボリューミーなことが出てくる。マネジメントの全体論がありながら個別は飛ばして別文書ような形が良いのでは。ある部分はISOで標準化されているとか
- ログイン認証はSP800-63の世界．顧客資産管理系はクラウドのCSAのドキュメントで出来ている．リミッタがない，APIの接合の文書は別である．
agenda6 AOB
agenda7 TaskとToDo