Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CIS参加報告 - Blockchain/HashgraphとIdentity

5,680 views

Published on

2016/06/24のOpenID Foundation Japan EIWGでのCloud Identity Summit 2016への参加報告。分散セッション管理とBlockchain、Hashgraphの活用について。

Published in: Technology
  • Be the first to comment

CIS参加報告 - Blockchain/HashgraphとIdentity

  1. 1. Cloud Identity Summit 2016 参加報告 2016/06/24 MVP for Enterprise Mobility Naohiro Fujie / @phr_eidentity / http://idmlab.eidentity.jp
  2. 2. 開催概要 • 主催:Ping Identity • 日程:2016/06/06 ~2016/06/09 • 場所:New Orleans • テーマ:R/Evolution of Security • ハッシュタグ:#CISNOLA 2
  3. 3. 個人的注目テーマとニュース • 分散セッション管理/シングルログアウト • Hashgraph / Blockchain • 自己主権型アイデンティティ(Self-Sovereign Identity) • GDPR(一般データ保護規則)と有効な同意の取得 • Kantara Initiative / Consent & Information Sharing WG • MVCR(Minimum Viable Consent Receipt)v0.8が7月にリリース • その他ニュース • GoogleもSCIMやるらしい 3
  4. 4. 分散セッション管理 • 分散セッション管理(DSM)が必要な理由 • Continuous Authentication の必要性と課題 • Single Log Out(SLO)の課題 4
  5. 5. Continuous Authentication の必要性と課題 • Password ベースの認証の限界 • 漏えいしている前提に立つ必要がある • シングルサインオンの普及 • 最初の認証は本当に信頼できるのか? 5 ドメインを跨いだセッション削除が可能であること モバイル・デバイスやバイオメトリクスを利用した Continuous Authentication 大前提
  6. 6. Single Log Out(SLO)の課題 • クライアントの多様化 • ブラウザ、モバイル • プロトコルの多様化 • OpenID Connect / OAuth2 • SAML 6 確実にセッションを削除するのは難しい IdP Example.net RP2 Example.co.jp RP1 Example.com Session Session Session Cookie Example.com Example.co.jp Example.net ⇒セッションの延長やサスペンドなどのシナリオを考えるとほぼ不可能
  7. 7. Single Log Out(SLO)の実装方式の比較 7 要件 解説 Front Channel実装 Back Channel実装 理想の実装 Shared State ユーザとアプリ ケーションセッ ションの関連付 けができること YES Cookieでセッション情報 を持っているので削除 対象のセッションが判 別できる NO アプリケーション側で ユーザとセッションの 紐づけを保持していな いと削除対象セッショ ンが判別できない YES Verifiable アプリケーショ ンがログアウト リクエストを受 け入れたことが 確認できること NO iFrame/Form POST /Redirectなので確実性に 欠ける YES IdPからアプリケーショ ンへ直接ログアウト要 求を投げるので確実 YES
  8. 8. Identityレイヤの下層に元帳レイヤを構築 • セッション管理を含め、Identityレイヤの下層に整合性 のとれた元帳(Ledger)レイヤを構築する必要がある アイデンティティとセッションの紐づけが可能になる 分散環境において確実に整合性がとれる 8 ディレクト リ 認証 SSO フェデレー ション セッション 管理 共有 シグナル 整合性のとれた分散データストア Identity レイヤ 元帳 レイヤ
  9. 9. 実装イメージ 9
  10. 10. 分散環境における元帳の整合性の課題 • どうやって整合性のとれた元帳レイヤを構築するか? • アプローチ • 中央集権サーバ • リーダーベース&非Proof of Work Blockchain • Proof of work Blockchain(Ethereumなど) • Bitcoin Blockchain • Swirlds Hashgraph 10
  11. 11. 各アプローチの評価 11 評価軸 中央集権サーバ リーダーベース &非PoW Blockchain Proof of work Blockchain Bitcoin Blockchain Swirlds Hashgraph 少ない計算量 YES YES NO NO YES DoSへの耐性 NO NO YES YES YES SPOFなし NO YES YES YES YES 暗号ベースの受信保証 NO NO NO NO YES 暗号ベースの送信保証 YES YES YES YES YES 信頼できる合意タイム スタンプ NO NO NO NO YES スケーラブル YES NO/リーダー YES/Blockchain YES NO YES 監査用の不変レコード NO YES YES YES YES 分散信頼 NO YES YES YES YES 高信頼性 NO YES YES YES YES
  12. 12. Hashgraphのコア・コンセプト① • Transactions • メンバは誰でも、いつでもトランザクションを作ることが出来る • 全メンバはトランザクションを受け取り、コンセンサスを形成する • Fairness • 少数の攻撃者グループが不正にトランザクションの順序に影響を与え ることは難しい • Gossip • 各メンバが知っているすべての情報は、ランダムに選択される他のメ ンバに対して拡散される • Hashgraph • 誰が、誰に、どんな順にGossipしたのかを記録したデータ構造 12
  13. 13. Hashgraphのコア・コンセプト② • Gossip about gossip • Gossipされた履歴自体がGossipされる • Virtual voting • 各メンバがhashgraphのコピーを持つため、実際に投票をしなくても何 を投票するはずかがわかる • Famous witnesses • トランザクションの前後関係を証明するために最低限必要なイベント をwitnessと呼び、あるトランザクションの直後に一番多くのメンバが 受け取ったトランザクションをfamous witnessと呼ぶ 13
  14. 14. BlockchainとHashgraph 14
  15. 15. Blockchainにおける元帳データ確定方法 出典)5分でわかるブロックチェーンの基本的な仕組み http://www.slideshare.net/cookle/5-58379474 15 • チェーンの長さによる決定 • 計算速度の速い採掘者による決定(PoW)
  16. 16. Hashgraphにおける元帳データ確定方法 • GossipプロトコルによるGraph自体の伝達 • Virtual Votingによる合意形成 • Graphの繋がりによる決定 16 Alice Bob Carol Z X Y ZのHash ZのHash 本来はXのHash 悪意を持った Folk Gossip Gossip Gossip Graphの繋がりの不整 合を検知、Yを破棄 Gossip Gossip 整合性の回復 整合性の回復
  17. 17. Swirlds Hashgraphの特徴① • Fair(公平である) • 誰もトランザクションの順番を操作できない • Blockchainだと採掘者が順番の選択を行うことが可能 • 誰もトランザクションを止めたり遅延させることが出来ない • Blockchainだと大多数の採掘者が拒否した場合、トランザクションが遅延する • (結局のところ)Blockchainでは採掘者を説得できないと無視される • Fast(早い) • 帯域のゆるす限りトランザクションが可能 • Bitcoinはブロックサイズの制限により秒間7取引までに制限される • Provable(立証できる) • イベントが発生すると2分以内にコミュニティ全員が知る • また、他のメンバが知っていることを知る 17
  18. 18. Swirlds Hashgraphの特徴② • Byzantine(ビザンチン・フォールトトレラント) • 一つもしくは少数のメンバが承認を妨げることが出来ない • 一度承認されたものを取り消すことが出来ない • Blockchainでは恣意的にネットワークから切り離してChainを伸ばすことによ りコンフリクトを発生させることが可能 • ACID Compliant(ACID特性の遵守) • 承認されたら各メンバへ確定データのローカルコピーが作成される • 100% Efficient(効率的である) • Blockchainでは古くなったり捨てられたブロックを採掘するのは無駄だが、 hashgraphではブロックが古くなることは無い • Inexpensive(安価である) • Proof of Work(計算を早く解いたメンバが新しいブロックを配布=高速なコ ンピュータのためのコストがかかる)を避けることが可能 18
  19. 19. Swirlds Hashgraphの特徴③ • Timestamped • 各トランザクションは確定したタイムスタンプを持つ(各メンバが最初にト ランザクションを受け取った時間の中央値) • Blockchainにおいても各ブロックはタイムスタンプを持つが、採掘をした際の、 採掘者のコンピュータの時間を持っているだけである • DoS resistant • HashgraphはProof of workを必要としないため、リーダーノードに対するア タックによるシステム全体の停止を避けることが出来る • Non-permissioned(optional) • Proof of stake(保有割合が多いメンバが新しいブロックを配布)を必要とし ないため、参加するメンバの信頼性の担保は必須ではなく、誰でもメンバと して参加することが出来る 19
  20. 20. ニュースリリース:Ping Identityが投資 https://www.pingidentity.com/en/about/press-releases/2016/ping- identity-invests-in-next-generation-blockchain-alternative.html 20
  21. 21. 参考情報 • http://www.swirlds.com/ • http://www.the-blockchain.com/docs/Overview-of-Swirlds- Hashgraph.pdf • http://www.swirlds.com/wp-content/uploads/2016/06/2016-05-31- Swirlds-Consensus-Algorithm-TR-2016-01.pdf • http://bitcoinist.net/swirlds-blockchain-limitations-hashgraph/ • https://www.pingidentity.com/en/about/press-releases/2016/ping- identity-invests-in-next-generation-blockchain-alternative.html 21
  22. 22. ちなみに •来年はシカゴ •6月17日~19日(だったと思う) 22

×