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

1. Cloud Identity Summit 2016
参加報告
2016/06/24
MVP for Enterprise Mobility
Naohiro Fujie / @phr_eidentity / http://idmlab.eidentity.jp

2. 開催概要
• 主催：Ping Identity
• 日程：2016/06/06
～2016/06/09
• 場所：New Orleans
• テーマ：R/Evolution of Security
• ハッシュタグ：#CISNOLA
2

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. 分散セッション管理
• 分散セッション管理（DSM）が必要な理由
• Continuous Authentication の必要性と課題
• Single Log Out（SLO）の課題
4

5. Continuous Authentication の必要性と課題
• Password ベースの認証の限界
• 漏えいしている前提に立つ必要がある
• シングルサインオンの普及
• 最初の認証は本当に信頼できるのか？
5
ドメインを跨いだセッション削除が可能であること
モバイル・デバイスやバイオメトリクスを利用した
Continuous Authentication
大前提

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. 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. Identityレイヤの下層に元帳レイヤを構築
• セッション管理を含め、Identityレイヤの下層に整合性
のとれた元帳（Ledger）レイヤを構築する必要がある
アイデンティティとセッションの紐づけが可能になる
分散環境において確実に整合性がとれる
8
ディレクト
リ
認証 SSO
フェデレー
ション
セッション
管理
共有
シグナル
整合性のとれた分散データストア
Identity
レイヤ
元帳
レイヤ

9. 実装イメージ
9

10. 分散環境における元帳の整合性の課題
• どうやって整合性のとれた元帳レイヤを構築するか？
• アプローチ
• 中央集権サーバ
• リーダーベース＆非Proof of Work Blockchain
• Proof of work Blockchain（Ethereumなど）
• Bitcoin Blockchain
• Swirlds Hashgraph
10

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. Hashgraphのコア・コンセプト①
• Transactions
• メンバは誰でも、いつでもトランザクションを作ることが出来る
• 全メンバはトランザクションを受け取り、コンセンサスを形成する
• Fairness
• 少数の攻撃者グループが不正にトランザクションの順序に影響を与え
ることは難しい
• Gossip
• 各メンバが知っているすべての情報は、ランダムに選択される他のメ
ンバに対して拡散される
• Hashgraph
• 誰が、誰に、どんな順にGossipしたのかを記録したデータ構造
12

13. Hashgraphのコア・コンセプト②
• Gossip about gossip
• Gossipされた履歴自体がGossipされる
• Virtual voting
• 各メンバがhashgraphのコピーを持つため、実際に投票をしなくても何
を投票するはずかがわかる
• Famous witnesses
• トランザクションの前後関係を証明するために最低限必要なイベント
をwitnessと呼び、あるトランザクションの直後に一番多くのメンバが
受け取ったトランザクションをfamous witnessと呼ぶ
13

14. BlockchainとHashgraph
14

15. Blockchainにおける元帳データ確定方法
出典）5分でわかるブロックチェーンの基本的な仕組み
http://www.slideshare.net/cookle/5-58379474
15
• チェーンの長さによる決定
• 計算速度の速い採掘者による決定（PoW）

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. Swirlds Hashgraphの特徴①
• Fair（公平である）
• 誰もトランザクションの順番を操作できない
• Blockchainだと採掘者が順番の選択を行うことが可能
• 誰もトランザクションを止めたり遅延させることが出来ない
• Blockchainだと大多数の採掘者が拒否した場合、トランザクションが遅延する
• （結局のところ）Blockchainでは採掘者を説得できないと無視される
• Fast（早い）
• 帯域のゆるす限りトランザクションが可能
• Bitcoinはブロックサイズの制限により秒間7取引までに制限される
• Provable（立証できる）
• イベントが発生すると2分以内にコミュニティ全員が知る
• また、他のメンバが知っていることを知る
17

18. Swirlds Hashgraphの特徴②
• Byzantine（ビザンチン・フォールトトレラント）
• 一つもしくは少数のメンバが承認を妨げることが出来ない
• 一度承認されたものを取り消すことが出来ない
• Blockchainでは恣意的にネットワークから切り離してChainを伸ばすことによ
りコンフリクトを発生させることが可能
• ACID Compliant（ACID特性の遵守）
• 承認されたら各メンバへ確定データのローカルコピーが作成される
• 100% Efficient（効率的である）
• Blockchainでは古くなったり捨てられたブロックを採掘するのは無駄だが、
hashgraphではブロックが古くなることは無い
• Inexpensive（安価である）
• Proof of Work（計算を早く解いたメンバが新しいブロックを配布＝高速なコ
ンピュータのためのコストがかかる）を避けることが可能
18

19. Swirlds Hashgraphの特徴③
• Timestamped
• 各トランザクションは確定したタイムスタンプを持つ（各メンバが最初にト
ランザクションを受け取った時間の中央値）
• Blockchainにおいても各ブロックはタイムスタンプを持つが、採掘をした際の、
採掘者のコンピュータの時間を持っているだけである
• DoS resistant
• HashgraphはProof of workを必要としないため、リーダーノードに対するア
タックによるシステム全体の停止を避けることが出来る
• Non-permissioned（optional）
• Proof of stake（保有割合が多いメンバが新しいブロックを配布）を必要とし
ないため、参加するメンバの信頼性の担保は必須ではなく、誰でもメンバと
して参加することが出来る
19

20. ニュースリリース：Ping Identityが投資
https://www.pingidentity.com/en/about/press-releases/2016/ping-
identity-invests-in-next-generation-blockchain-alternative.html 20

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. ちなみに
•来年はシカゴ
•6月17日～19日（だったと思う）
22