[Azure AD]登録済みデバイスからのみアクセスを許可する

こんにちは、富士榮です。

最近Pokemon Goの話題ばかりだったので、Azure Active Directory（Azure AD）の話題を。

以前、IdM実験室別館（Channel 9）やセミナで紹介したことがありますが、組織内のネットワーク以外からのアクセスを拒否したり多要素認証を要求したりする「条件付きアクセス（Conditional Access）」の新機能の「デバイスベースの条件付きアクセス」のパブリック・プレビューが公開されました。

　公式Blogでのアナウンス
　#AzureAD Conditional Access Policies for iOS, Android and Windows are in Preview!
　https://blogs.technet.microsoft.com/enterprisemobility/2016/08/10/azuread-conditional-access-policies-for-ios-android-and-windows-are-in-preview/


具体的に何ができるのか、というと

• ドメインに参加しているデバイスからのみアクセスを許可する
• MDM（Intune）で管理されているデバイスからのみアクセスを許可する

ということです。
※ドメイン参加は以下の条件
　・オンプレミスのADに参加しており、デバイス同期がAzure ADに対して実行されている
　・Azure AD自体に参加している
　・Workplace Joinしている
※対応しているデバイスは、Windows PC、Windows Mobile、iOS、Android

　やはりネットワーク・ベースのアクセス制御だと業態によっては適用が難しかったり、信頼済みネットワークのメンテナンスが面倒だったりするので、デバイス自体を見てアクセスを制御する機能の必要性が挙がっており、ようやくの対応となりました。まだまだパブリック・プレビューですがニーズは多いはずなので早く正式リリースしてもらいたいですね。


と、いうことで早速試してみます。

◆設定はアプリケーション単位

ネットワークベースの条件付きアクセス制御と同様にアプリケーション単位で設定を行います。
（Azure AD Premiumのライセンスが必要です）

[設定]メニューを開くと「デバイスベースのアクセス制御」が表示されているので「アクセス規則を有効にする」をONにします。

すると、適用対象とデバイスルールの2つのメニューが表示されます。
適用対象は、対象とするユーザを選択します。例えばルール適用対象から除外したいユーザがいる場合は、ユーザやグループの単位で除外することが出来ます。
また、デバイスルールは、対象とするデバイスの種類、およびWindowsデバイスの場合のルール準拠の条件（ドメイン参加やIntune登録など）を設定することが出来ます。

以下が設定画面です。

今回は、全てのユーザが、すべてのデバイスにおいてルールに準拠している必要があるように設定してみました。

では、早速アクセスしてみます。

◆Windows PCからのアクセス。IEとEdge以外は対応していない！

まずはPCでアクセスしてみます。

まずはルールに準拠していないPCからのアクセスです。

ログインをすると、アクセスが拒否されました。

しかし、FirefoxやChromeでアクセスした時とInternet ExploreやEdgeでアクセスした時で出てくるメッセージが異なります。
どうやらInternet ExploreとEdgeしか対応していないようです。

Firefoxでのアクセス。The current browser is not supportedと言われてしまう。

Edgeでのアクセス。The application contains sensitive information and can only be accessed from the devices that are compliant with eIdentity access policyと言われ、デバイスベースでのアクセス制御が有効に働いていることがわかる。

次に、ポリシーに準拠しているPCからアクセスしてみます。今回はAzure ADに直接参加しているWindows 10のPCからアクセスしてみます。

Firefoxからのアクセスだとやはりブラウザが対応していない、と言われます。

Edgeでアクセスすると問題なくアクセスできるので正常にデバイスベースのアクセス制御が働いていることがわかります。

◆モバイル（iOS）でアクセスする。同じくブラウザを選ぶ！

同じくiOSでアクセスします。このデバイスはIntuneに登録済みなので、ポリシーに準拠している状態です。

まずはiOS版のChromeです。
やはりブラウザを選ぶようで、アクセスできません。

Safariでアクセスするとクライアント証明書認証が走ります。

証明書をタップするとうまくアクセスできました。

◆まとめ

デバイスの状態をちゃんとみてアクセス制御が働いていることがわかります。これでネットワーク制御に加えて、さらに柔軟に制御をすることもできるようになりそうです。

しかし、デバイス状態をAzure ADが判断するためには仕方ないことかもしれませんが、ブラウザを選んでしまうのが難点といえば難点です。
せめてChromeやForefoxなど他のブラウザ用にプラグインなどを用意して対応していってもらいたいものです。。。

安全!? #PokemonGo のログインと OpenID Connect と PokeIV

こんにちは、富士榮です。

今回はもPokemon Goとアイデンティティのネタです。

前回、前々回とPokemon Goのログインの流れを見てきました。

　攻略！ #PokemonGo のログインと OpenID Connect
　http://idmlab.eidentity.jp/2016/07/pokemongo-openid-connect.html

　続！#PokemonGo のログインと OpenID Connect
　http://idmlab.eidentity.jp/2016/07/pokemongo-openid-connect_25.html


これまでのポストでは、主にGoogleでログインすることで、Googleサービスへの不要なアクセスができる状態になっていないか？という観点で調査をしてきましたので、Scopeパラメータを見る限りはメールアドレスくらいにしかアクセスしていないことが分かったので、ひとまず安心、という結論を出していました。

◆Pokemon Goのふりをするアプリの登場

しかし、逆にPokemon Go側から見ると、Pokemon GoのサービスへのアクセスはGoogleから取得したid_tokenを持っていることだけを条件にしているので、何とかしてPokemon Goアプリの”ふり”をしてid_tokenを取得してしまえば、あとは何とでもなる、という状態でもありました。

最初のポストを書く時に、OpenID ConnectでGoogleからid_tokenを取得する流れを見ていると、public clientにもかかわらずimplicitではなくcode flowを使っており、codeやclient_secretが丸見えな点にものすごく違和感を感じて、サードパーティ・クライアントでも作るつもりなのかな？？？など、色々と議論をしていたんですが、やはり出てきてしまいました。

　PokeIV : 個体値チェックサイト
　　https://pokeiv.net/

Gigazineでも紹介されていますが、Pokemon Goで使っているアカウントでGoogleにログオンし、codeを取得しPokeIVに貼り付けることでPokemon Goへアクセスして個体情報を取得するという仕組みなのですが、内部的には、Pokemon Goのclient_idとclient_secretを使ってPokemon Goのサービスへアクセスできるid_tokenを取得しているようです。

以下の同意画面を見るとクライアントがPokemon Goになっており、クエリパラメータの中のclient_idを見るとiOS版のPokemon Goで使っているclient_idと同じものが使われています。

Googleに登録されているredirect_uriがurn:ietf:wg:oauth:2.0:oobなので、redirect_uriにクエリでcodeを渡す代わりに、取得したcodeを手動（コピペ）で渡し、tokenエンドポイントを叩く、という実装はしていますが、色々とタチが悪いですね。

最近OpenID Foundation Japanの事務局長になったnov氏がoauth.jpで書いているようにcode置き換えもあるでしょうし、そもそもclient_secretが漏れている段階で今回のPokeIVのように単純にPokemon Goのふりをしてデータを取得するようなクライアントの開発が出来てしまいます。

今は集めたポケモンの情報をとってくるだけ、ということになっているので良いんでしょうが、例えば、今後Pokemon Goからユーザの位置情報の履歴を取得できたりすると、一気にホラーな話になってしまいますよね。。。

◆Pokemon Goはどうすれば良かったのか？

そもそも論、HTTPSを使っているにも関わらずFiddlerでトレースできてしまう段階でCertificate Pinningなどの対策が出来ていない、という話もありますが、ネイティブアプリ（パブリック・クライアント）として実装している段階で逆コンパイルや解析をされる前提でOpenID ConnectやOAuthの設計をすべきです。具体的にはimplicit flowを使ったり、Google Sign-In SDK for iOSを使って、client_secretを使わない方法で実装するのが一番簡単な対策だと思います。

簡単にまとめるとこんな感じかと。（他にもあるとは思いますが）

脅威	対策
通信トレースによるcodeやclient_secretの漏えい	Certificate Pinning
バイナリ解析によるclient_secretの漏えい	難読化（限界あり）
Proxyサーバの通信ログよりcodeの漏えい	PKCEの利用（Googleは既にPKCE対応してます）
client_secretの漏えいによるクライアントなりすまし	client_secretを使わないフローの採用（implicit/Google Sign-In SDKの利用）

◆現バージョンのPokemon Goはどうなっているのか？

最近バージョンが上がったクライアントはどうなっているのか？を見てみました。

Proxyを挟んだ状態でアクセスするURLなどを見て推測すると、Google Sign-In SDKを使っているみたいです。また間にfiddlerを挟んだ構成だとログオンに成功しないので、MITMもチェックもしているみたいです。（うまくトレースできなかったので深追いはしていませんが）

◆PokeIVなどのアプリを使ってしまった場合の対策

しかし、一度PokeIVなどのアプリを使ってしまった場合、id_tokenやrefresh_tokenがアプリ側に保管されている可能性もあり、勝手にPokemon Goへ不正にアクセスされてしまう可能性もゼロではありません。

このような場合は、Googleアカウントのページからアプリケーションからのアクセスを一旦取り消して、正規のPokemon Goで再度サインインをしましょう。

アクセスを許可しているアプリケーション一覧が以下のURLで確認できるので、Pokemon Goを探して、一旦削除してしまいましょう。

https://security.google.com/settings/security/permissions

Pokemon Goを起動すると再度Googleアカウントへのアクセス許可のページが表示されますので、ここで改めて許可をすることでid_tokenが取得できるので引き続きPokemon Goを楽しむことが出来ます。

続！#PokemonGo のログインと OpenID Connect

こんにちは、富士榮です。

昨日に引き続き Pokemon Go / ポケモン Go です。

だいぶレベルあがりました。

昨日のポストに対する皆様の反応を拝見していると、iOS版はわかったから、Android版はどうなの？という意見が多かったので、今回はAndroid版です。

また、結局 Pokemon Go はどういう権限を要求しているのか？について若干混乱が見られたので、そのあたりもついでに整理していこうと思います。

では、早速見ていきます。

まずは、Android版の動きです。

◆環境設定

昨日のiOSと同様に、Wifi設定よりProxyサーバとしてPC上で動かしているFiddlerを使うように設定します。

準備はほぼ同じなので、さっそくGoogleでログインしてみます。

◆ログイン時のトラフィックの違い

実際にログオンしてみるとiOSとは大きな違いがあることがわかります。

iOS版では、WebViewが立ち上がりGoogleアカウントでログインする必要がありますが、Android版ではOSにログオンしているGoogleアカウントがシームレスに使われるため、改めてGoogleへログインする必要がありません。

トラフィックをキャプチャすると、android.clients.google.com/authに対して直接client_idなどをPOSTしてid_tokenを受け取っています。

POST https://android.clients.google.com/auth HTTP/1.1

POSTデータ

androidId=3798d3c8e02a1cce

&lang=en_US

&google_play_services_version=9256438

&sdk_version=23

&device_country=jp

&client_sig=321187995bc7cdc2b5fc91b11a96e2baa8602c62

&callerSig=321187995bc7cdc2b5fc91b11a96e2baa8602c62

&Email=reign.of.pharaoh%40gmail.com

&service=audience%3Aserver%3Aclient_id%3A82..snip..b.apps.googleusercontent.com

&app=com.nianticlabs.pokemongo

&check_email=1

&token_request_options=

&callerPkg=com.nianticlabs.pokemongo

&Token=oauth2rt_1%2FBF_GAY86cPwrwUgpf2HZd3pV71FRTE0q-YgCePsVp2E

ちなみに、iOS版とはclient_idが違うんですね。

このリクエストに対して、HTTP 200で以下のデータが返ってきます。Authにid_tokenが入ってきています。

Auth=eyJhbGciOiJSUzI1N...snip...d9LC7FGaQ

issueAdvice=auto

Expiry=1469374236

storeConsentRemotely=1

isTokenSnowballed=0

jwt.ioでdecodeするとちゃんとid_tokenになっています。

以降のAPIコール時はiOSと同じくid_tokenがPOSTされているので、Android版でもid_tokenに乗っている情報以外（iOSと違って、メールアドレス以外に姓と名がid_tokenに含まれます）はサービスにはわたっていないことがわかります。

まぁ、一安心ということで。

◆結局どういうパーミッションが求められているのか？

前回も今回もOpenID Connectという文脈でPokemon GoアプリケーションがGoogleへどのような情報や操作を要求しているのか？を見て、とりあえず新規にGoogleアカウントを作らなくてもよさそう、という結論に達しました。

しかし、前回のポストに対するコメントとして、連絡先へのアクセスが要求されたりするので、やっぱりアカウントは新規に作る方がいいのでは？みたいなコメントもありました。

確かにAndroid版を見ると、アプリが端末に対して連絡先へのアクセスを要求しています。

※理由はよくわかりませんが。。。

＜iOS版＞

＜Android版＞

ここは非常に混乱を招きやすい部分ですが、結論から言いますとアプリケーションが端末に対して要求している権限と、Googleアカウントでログインする際にGoogleに対して要求する権限は全く別のものであり、Googleアカウントの新規作成うんぬん、という話は後者にしか関係しません。（いわゆる、OAuthのscopeパラメータの話ですので）

ここで言う連絡先へのアクセスは前者の端末インストール時の話なので、連絡先へのアクセスが嫌なのであれば、Googleアカウントを新規に取り直すのではなく、専用端末を新規に購入すべきである、ということになります。

まぁ、この辺りは確かにユーザにとってわかりにくいですね。

攻略！ #PokemonGo のログインと OpenID Connect

こんにちは、富士榮です。

世の中 Pokemon Go / ポケモン Go 一色ですが、いかがお過ごしでしょうか？

あいにく私の住んでいる地域は過疎化が進んでおり、ポケモンがほとんどおりません・・・・

おかげで全然レベルが上がらないので、ジムなどには無縁な平和な生活を営んでいるわけなんですが、果たして Pokemon Go のログオンは平和なのか？という ID 厨なら必ず抱く疑問を解消すべく、家族で地元の夏祭りに参加している横で解析をしてみました。

公開当初はフルアクセスを要求するアプリだったので、プチ炎上したりしましたが現状は解消されたということなので、パケットキャプチャしてみます。

　参考）ポケモン Go がフルアクセスを要求していた件。

　http://mobilelaby.com/blog-entry-pokemon-go-google-account-full-access-bug-issue.html

では早速、Pokemon Go へのログインの仕組みを見ていきましょう。

Pokemon Go ではいわゆるローカルアカウント（Pokemon Trainer Club）と Google アカウントを使ってログオンする2つの仕組みが用意されています。

色々な Web サイトを見ると、専用の Google アカウントを作るべきである、というような記事を見かけたりしますが、根拠として先のとおり、すべて権限を要求するから、という理由が挙げられています。

　参考）ポケモン Go をプレイするなら専用の Google アカウントを作るべき

　http://www.appbank.net/2016/07/20/iphone-application/1229961.php

まぁ、公式発表によると権限周りは修正されたということなのですが、実際にどのような権限が要求されているのか、ログオン～ユーザ登録のシーケンスにおいて何が起きているのかを見ておきたい、ということで解析してみましょう。

◆準備

基本的に通信をキャプチャすることになるので、プロキシを用意して HTTP/HTTPS の通信を覗いてみたいと思います。今回はiOS版を使ったので、PC にインストールした Fiddler をプロキシとして使うように iOS の Wifi 設定を行います。

今回は、PC で Fiddler を立ち上げ、リモートクライアント向けのプロキシとして動作するように設定を行いました。

Tools より Fiddler Options を開き、Connections タブへ以下の通り設定を行います。

- Fiddler Listen Port : 8888（デフォルト）

- Allow remote computers to connect : ON

これで PC にインストールした Fiddler がプロキシとして動作するようになります。

ちなみに、 Windows Firewall が邪魔をするので、外部からの 8888 への通信を許可するように設定をしておく必要があります。

また、HTTPS 通信を復号するためには、Fiddler の使う証明書を iOS が信頼するように構成する必要があるので、 Fiddler で証明書をエクスポートし、iOS 側へ送信、インポートしておく必要があります。（細かい手順は割愛します）

次は、iOS 側の設定で、Fiddler をプロキシとして使うようにしまう。

設定から Wifi を開いてプロキシサーバのアドレスとポートに Fiddler を動かしている PC のアドレスと先のポート番号を指定します。

これで準備は完了です。

早速、Pokemon Go をインストールしてサインアップしてみます。

◆Google アカウントでサインアップした場合の要求スコープは？

Pokemon Go を起動し Google アカウントでサインアップを選択します。

ここで、Googleを選択した時の通信キャプチャを見ると、以下のようなリクエストが飛んでいます。

GET https://accounts.google.com/o/oauth2/auth

?client_id=84....snip......apps.googleusercontent.com

&redirect_uri=urn:ietf:wg:oauth:2.0:oob

&response_type=code

&scope=openid email https://www.googleapis.com/auth/userinfo.email HTTP/1.1

注目すべきは scope パラメータです。OpenID Connect のリクエストなので当然 openid は含まれるとして、email および https://www.googleapis.com/auth/userinfo.email が含まれています。

Google の OpenID Connect 関係のドキュメントを見ると、email と は同じスコープで、メールアドレスの表示だけを要求していることがわかります。

画面上に表示されるとおりですね。

ここで、許可をクリックすると token エンドポイントへ認可コードが POST される普通の OpenID Connect の流れが続きます。

POST https://accounts.google.com/o/oauth2/token HTTP/1.1

ボディ

client_id=84...snip...alem.apps.googleusercontent.com

&client_secret=NCjF1...snip....uL7

&code=4/D7vS...snip....i7h1Q_njLCM

&grant_type=authorization_code

&redirect_uri=urn:ietf:wg:oauth:2.0:oob

&scope=openid email https://www.googleapis.com/auth/userinfo.email

結果、access_tokenやid_tokenが返ってきます。

{

  "access_token" : "ya29.Ci8pAxbo....snip...FA",

  "token_type" : "Bearer",

  "expires_in" : 3600,

  "id_token" : "eyJhbGciOiJSUzI1....snip.....XsXHNwQ",

  "refresh_token" : "1/lCAJhP...snip....TM"

}

もちろん id_token の中身を jwt.io などで覗くといい感じで Google アカウントの情報が出てきます。

さて、問題はこの後です。

email をスコープとして access_token を要求しているので、必要以上の情報を Google が提供することはありませんが、どのような要求が Pokemon Go から実施されているのでしょうか？

結論、サインアッププロセスの中で access_token が使われることはなく、 id_token の中のメールアドレスだけを使っているように見えます。

続くリクエストは運営元の Nianteclabs.com への POST なのですが、所謂 RESTful API 的に JSON などがやり取りされるわけではなく、バイナリデータが飛び交うのでこれ以上の解析はしませんが、見えている範囲では、 id_token がそのまま POST されているようです。

POST https://pgorelease.nianticlabs.com/plfe/rpc HTTP/1.1

ボディ

＜いろんなバイナリ情報＞

google

   eyJhbGciO....snip.... <- div="" id_token="" post="">

と、いうことでやっぱり OpenID Connect でのログインおよびメールアドレス情報だけを渡している、ということで、まぁ大丈夫そうです。

◆まとめ

今回はあくまでサインアッププロセスのみを見ているので、続く処理で何が行われているかはわかりませんが、とりあえずという意味では以下のことが言えると思います。

• Pokemon Go のログイン・サインアップには OpenID Connect が採用されている
• email アドレスのみを読み取る Scope で access_token が要求されているが、実際は id_token だけが使われている
• 結果、メールアドレスくらいしか連携されていなさそうなので、別アカウントを作ったりする程にセンシティブにならなくてもよさそう？

注記）

• 解析はあくまで一部分のみを対象としているので、他の処理で色々と情報を収集している可能性があります
• 本解析は Pokemon Go のサービスを攻撃することを意図したものではありません
• 本ポストが Pokemon Go のサービス規約に違反するなどし、サービス提供者の意図にそぐわない場合は本ポストを削除する可能性があります

[Azure AD]AAD Connect Health for AD DSでオンプレミスのADを監視する

こんにちは、富士榮です。

Azure Active Directory（Azure AD）やPing ONEをはじめとしたクラウド上のID基盤（IDaaS）が流行ってきていますが、どのソリューションも現状はオンプレミスにActive Directoryが存在していることを前提として構成が組み立てられています。

これは、2014年のVittorio Bertocci氏へのインタビューでもオンプレミスのActive Directoryの普及率は95%を超えている、という発言があるとおり、エンタープライズ分野へIDaaSを適用する際は既存のActive Directoryを避けて通れず、どのようにシームレスにオンプレミスからクラウドへ橋渡しをするか？がフォーカスされているため決して不自然なことではありません。

しかし、こうなってくるとクラウド側の基盤がグローバルでレプリケーションされていて高い可用性を持っていたとしても、システム全体を見た時にはオンプレミスのActive Directoryがボトルネックや障害発生ポイントとなってしまいます。

と、いうことでマイクロソフトはハイブリッドID基盤をなるべく一か所で監視・管理できるようにしたり、セキュアに運用できるように色々と関連ソリューションを出しています。

脅威／リスク	対象	ソリューション
稼働状況監視	AD FS	Azure AD Connect Health for AD FS
	AD DS	Azure AD Connect Health for AD FS
不正アクセス検知	AD DS	Advanced Threat Analytics
特権ID管理	AD DS	Microsoft Identity Manager 2016

今回は、新たにPublic Previewが公開されたAzure AD Connect HealthによるActive Directory（AD DS）の稼働状況のモニタリングについて見てみたいと思います。

　公式Blogでの発表
　Introducing #AzureAD Connect Health for Windows Server AD
　https://blogs.technet.microsoft.com/enterprisemobility/2016/07/19/introducing-azuread-connect-health-for-windows-server-ad/


仕組みとしては、監視用のエージェントをAzure PortalのAzure AD Connect HealthからダウンロードしてオンプレミスのAD DSサーバへインストール・構成するだけなので非常に簡単です。

◆エージェントを入手する

新ポータル（https://portal.azure.com）のダッシュボードにAzure AD Connect Healthがない人は追加しておきましょう。

Azure AD Connect Healthを開くとAgent for AD DSのダウンロードができるようになっていますので、Get toolsをクリックしてAgentモジュールをダウンロードします。

◆エージェントをインストールする

次は、監視対象のドメインコントローラへログインしてモジュールをインストールします。
ダウンロードしたモジュールをドメインコントローラへコピーしてインストーラを実行します。

この際、以下の前提事項があるので準備をしておいてください。。

• ドメインコントローラ上でビルトインアカウントによるInternet Exploreが実行できること
• microsoftonline.com、microsoftonline-p.com、micorosoft.com、windows.netのCookieを受け入れる設定になっていること（windows.netはいらないかも）
• Azure ADテナント上でグローバル管理者権限を持つ組織アカウント（マイクロソフトアカウントではなく）が存在していること
• ドメインコントーローラからAzureへの上り通信がブロックされていないこと

特に、Windows Server 2016では、IEの設定が厳しいのでCookieの受け入れの設定を確実にしておかないとエージェントのセットアップに失敗します。


ダウンロードしたファイルを実行すると、インストールが始まります。

インストール自体は非常にシンプルなのですぐに終わります。

◆エージェントを構成する

インストールが完了したらAzure ADのテナントへ接続し、エージェントを登録します。

うまくIEの構成がされていれば、Azure ADへのログインダイアログが起動してきますので、「組織アカウント」でログインします。（マイクロソフトアカウントだとエラーが出ます）

以下、エラーになった場合のメッセージです。
＜Cookieの受け入れ設定が出来ていない場合＞

＜マイクロソフトアカウントでログインした場合＞

うまく構成ができると、以下のメッセージが出ます。

◆ポータルより状態を監視する
インストールが完了するとドメインコントローラに関する情報がエージェントによりAzure AD Connect Healthへアップロードされます。

各種状態を確認することが出来ます。
＜FSMO、サイト、GCなど＞

＜機能レベルなどのプロパティ＞

＜認証要求数、レプリケーションステータスなど＞

ちなみに監視対象のドメインコントローラを停止すると以下のようにアラートが表示されます。
（検知するまでにしばらく時間がかかります）

これでHybrid ID基盤のオンプレミス側の構成要素であるAD DSの状態監視もクラウドから実行できますので、別途監視ツールや運用ツールを用意する必要性がぐっと下がりますので、安心して基盤の運用ができますね。

[FIDO]Injectorでパスワードの使いまわしや簡単なパスワードの利用を防止する

こんにちは、富士榮です。

先日のOpenIDファウンデーション・ジャパン、Enterprise Identity Working Group（EIWG）の成果報告会で、Cloud Identity Summit 2016（CIS）への参加についてBlockchainとHashgraphとアイデンティティに関する報告をさせてもらいました。

　資料等は前回のポストで。
　Blockchain、Hashgraphとアイデンティティ
　http://idmlab.eidentity.jp/2016/06/blockchainhashgraph.html


実はCISではセッションの他にExpoという形で各社がソリューションを持ち寄る展示会があり、その中でFIDO関係のブースで出展をしていたBluink社のInjectorというデバイスがとても面白かったので、取り寄せてみました。

Injectorには、Injector USB DeviceとInjector Miniという2種類がありますが、あんまり機能差がなさそうなので、持ち運びを考えてInjector Miniを購入しました。

公式サイトのストアで$29.99＋日本への送料（$15.00）の合計$44.99で購入できます。


2週間くらいで届いたので、早速試してみます。

◆何をするものなのか？

まず、そもそもこれは何をするものなのか？というと、「スマートフォンアプリに各種ログオン情報を記憶させておき、Injector（ドングル）を挿したPCでの各種ログインをスマホ経由で行う」ためのものです。

１．IDとパスワードの入力を代行する入力デバイス

（公式サイトの解説より）

簡単に言うと、PCに挿したBluetoothアダプタが入力デバイスとして認識され、スマホからログインに必要なキーストローク情報を送り込む、というかなり原始的な？仕組みです。
尚、この仕組みをとるのでPC側には基本的には何の追加ソフトウェアもいりません。
（QRコードを使って対象アプリケーションの選択を簡素化したい場合はブラウザのアドオンを入れる必要がありますが、自分でスマホ上で対象のアプリケーションを選択するなら本当に何もいりません）

試しにLinkedInへのログインを動画にしてみました。



２．FIDO U2Fに対応した2要素目のデバイス

また、違った一面としてFIDO U2Fに対応しているので、GoogleなどU2Fに対応したサービスへのログイン時の2要素目としても利用が可能です。

こちらも同じくGoogleへのログイン時の2要素目として使ってみました。

◆まずは準備

では、早速使ってみます。
準備として、スマホ用のアプリケーションをダウンロード～インストールします。

アプリを立ち上げると、マスタパスワード（このアプリ自体の起動パスワード。Touch IDも使えます）の登録およびInjectorデバイスとのペアリングを行うことになります。
（この段階でPCへInjectorデバイスを挿入します）

尚、このペアリングですが、工場出荷時はオープン状態（どのスマホとでもペアリング可能な状態）のはずなんですが、私の手元に届いたものはどうしてもうまくペアリングできず、サポートとやり取りをしてリセットをしてもらいました。（15分くらいでリセット用のコードを発行してもらいました。現地は土曜日の昼頃だったはずなんですが、驚異的なスピードです！）


うまくいくと、こんな感じでデバイスが登録された状態になります。

◆ログイン対象を登録

これでアプリとデバイスの準備が出来たので、次はアプリケーションの登録です。

アプリでAdd Credentialというメニューがあり、ある程度のアプリケーションはプリセットされているので、そこから選択すると簡単に登録ができます。

ここでアプリを選んでログインに使うIDとパスワードを登録していく、という形をとります。
尚、注意点ですが先に書いたとおり、キーストロークを送り込むという仕組みになっている以上、キーボード配列が違うと特に記号がうまく入りません。
これを使うときはPCを英語キーボードモードにしておきましょう。

後は先の動画で紹介したように各アプリを開いてスマホ側でログインをするだけです。

◆FIDO U2Fとしての登録

次は、基本的な使い方に加えてFIDO U2FデバイスとしてInjectorを登録してみましょう。
尚、これも注意点なんですが、U2Fに使う場合、キーストローク入力型の基本的な使い方との両立が現時点でうまくいっていません。（私の環境の問題かもしれませんが）
基本的な使い方の方に戻したければU2Fとしての登録を一旦削除してあげる必要があります。


動きは先に動画で紹介したので、GoogleへのInjectorデバイスの登録の方法を簡単に紹介します。基本はFIDOなのでYubikeyなどと同じくデバイスを事前に登録しておくだけです。

Googleの2段階認証セットアップを開き、セキュリティキーの登録を行います。
基本は画面の指示に従ってキーの挿入をし、アプリケーション側に表示されるRegistration確認を行うだけです。

（Googleのセキュリティキーの登録画面から指示に従いデバイスを登録する）

（うまく認識するとアプリに登録確認が出てくるので回答する）

これで完了です。
後は2段階認証の際にデバイスを挿してアプリで回答するだけです。

◆使ってみた感想

意外と良いかもしれません。
LastPass見たいなサービスに依存するものもなく、あくまでペアリングされたデバイスに依存するので、オフラインでも使えますし（それこそWindowsやMacへのログインにも使えます）、キーストローク入力するだけの簡単な仕組みなので対象のアプリケーションを選びません。
これで各アプリ向けのパスワードは本当にランダムなものを使ってしまっても問題ないかもしれませんし、ブラウザにパスワードを覚えさせる必要もありません。
（忘れた場合、Injectorの設定データのバックアップからパスワードを復元するためのツールが提供されています）

ただ、課題がないわけでもありません。
具体的にはあくまでUSB入力デバイスなので、モバイルのネイティブアプリやブラウザでの利用は出来ません。ネイティブアプリの場合はアプリケーションパスワードなどをうまく利用すればよいでしょうが、ブラウザの場合は困ってしまうので今後に期待です。
（現状でもiOSのSafariの場合はIntentでアプリを呼び出してキー入力させる様にできるみたいです）

Blockchain、Hashgraphとアイデンティティ

こんにちは、富士榮です。

先日（6/24）のOpenID Foundation Japan / Enterprise Identity Working Groupの成果発表会の場で先にニューオリンズで開催されたCloud Identity Summit 2016（CIS）の参加報告をしました。

報告したのはCISで個人的に一番の注目ポイントだった分散セッション管理とBlockchain、Hashgraphの話です。

内容としては、ハイブリッドなSSOの普及に伴い、継続的認証（Continuous Authentication）やその前提となる分散セッション管理の重要性が高まってきていて、アイデンティティレイヤの下に整合性のとれた元帳レイヤ（要は分散DBのレイヤ）が必要で、その手段の一つとしてBlockchainの欠点をうまく補った技術として「Hashgraph」が密かに注目されている、という話です。

HashgraphについてはSwirlds社が論文を発表しているんですが、いかんせん難しい概念なのでBlockchainとの違いを見ながらコンセプトと特徴を解説しました。

Blockchainは不整合が出た枝は切り捨てるので、左の図のような幹から枝が出ては伐採されるイメージ、Hashgraphはあくまでgraphなので関係性を紡ぎながら時系列に伸びていくので右の図のような絡み合ったイメージ、というのが大きな違いです。


細かい内容は以下に資料を公開したので、そちらと資料中にあげている参考URLをご覧ください。
今回は30分のセッションだったので、あまり深堀りは出来ませんでしたが、Swirlds社からHashgraphのSDKがもうじき公開される予定という話もあるので、次回は実際の動きを見てより細かいレベルで解説ができるといいなぁ、と思っています。

CIS参加報告 - Blockchain/HashgraphとIdentity from Naohiro Fujie