idcon15レポート

2月1日に行われた #idcon #15に行ってきました。
ミッドタウンタワーの大きなY!セミナールームがいっぱいになるほどの参加者でした。
idconとしては過去最大?

「Andouroid Android OSのカスタマイズによるアプリ間統合認証の実現」

  • ヤフー株式会社 安藤 義裕 氏
  • Andouroid: Android OSとJavaのFrameworkおよび下のCのレイヤに手を入れて作ったカスタムAndroid
    • 注: 個人としてやっているものでありY!がAndroidに〜という話ではありません
  • デモ
    • emulatorの中にAndouroid。起動に1分くらいかかる
    • ポイント: Y!のアプリを2種類使う。一方でログインすると、もう一方ではログインする必要がない
    • 最初にY!メールアプリを起動 → ログインしていないのでログイン画面が出る
    • 次にY!ブラウザを起動。ブラウザからメールを開く → やっぱりログインしていない
      • ここでログインしてY!メールを見てみる
      • ここでY!ブラウザを起動
    • さっきログインしていなかったY!メールを起動すると…… → ログイン済
    • おまけ: ほぼすべてのアプリをY!版で置きかえてみた。検索もY!
  • デモのポイント
    • アプリ自体には手を加えていない
  • しくみ
    • WebKitの改造
    • ログイン完了時にトークンをトークンストレージに格納
    • ログイン時にストレージにトークンがあればログイン処理を自動で行う
  • ストレージの説明の前に…
    • AndroidのユーザーIDはどうなっているか
    • プロセス一覧を見ると、アプリごとにuniqueなUIDが振られているのがわかる
    • アプリのDBファイル: アプリUID/GIDに対して0660になっている
  • あんどうろいどではyahoo(UID/GID)を追加した
    • uid, gidはUNIXのようなファイルで管理されているわけではなくCソースにハードコードされている。それを改造した
    • アプリインストール時にY!アプリならUID/GIDをyahooに設定
    • 改造したOSのビルドは3時間〜3時間半
  • 認証情報の共有
    • データ共有の方法はいろいろある(Shared Preference, SQLiteなど)
      • Shared ID: アプリ署名の証明書が同一であれば複数のアプリにも同じUIDを振ることができる
    • なぜカスタマイズしたのか
      • アプリ単体でデータを持つ or 広くどのアプリからでもアクセスできるデータにするか
      • 今回の要望: Y!アプリに限って認証情報を共有したい
      • → グループの追加のようなやり方がよかった
  • デバイス時代のID
    • OSを握って全部作る者がいろいろできて強い
    • PC時代はWebのIDと同じだった。デバイスのIDとWebのIDは違いがなくなってくる → デバイスを持っている会社がますます強く
  • OpenID Phoneなんて良さげ
  • Q&A
    • Q: アプリのUID/GIDをyahooに書きかえるときY!のアプリであるかどうかはどうやって判別しているのか
    • A: 今回はパッケージの名前で判定している → NGな方法。本来は独自マーケットを作成し、signatureをつけるなどの方法が必要
    • Q: nov: ストレージに保存しているのはOAuthのaccess_token? id_token?
    • A: 実はクッキーですw

アプリ間のトークン共有は発行者の認証や不正な共有を考えるとOSのサポートが必要なのだろうと思いました。そのへん、OSを押さえていると強いですね。

(19:32)

「Yahoo! JAPANのOAuth/OpenIDに代わる新しい認証認可機能 〜YConnect〜」

  • ヤフー株式会社 河内 俊介 氏
    • こうち しゅんすけ
    • ID決済本部 2008年入社 2011年〜認証/セキュリティー等ID関連
  • YConnectとは
    • OAuth2.0に準拠、OpenID Connectをサポート
    • Y! J IDでログイン可能
    • 一部属性情報の連携も可能
    • OAuth 1.0と比べてRPの作り方がカンタン
  • YConnect歴史
    • 2011年末、設計開始
    • 2012年9月中旬 → パートナー企業に提供
    • 2012/11/17公開
  • サポート範囲
    • OAuth2.0: Authorization code, Implicit, resource owner password credential
      • resource id credential: 社内のみ
    • OpenID Connect: Basic Client, Implicit Client
  • パートナー、社内アプリで導入
    • Y!ショッピング、Y!バザールなど
  • ユースケース
    • Y! J IDでログイン → 認証機能を使用
    • リソースの提供 → Y!ウォレットの導入 → 決済(ID連携と独立して可能)
    • 属性情報の連携 → ユーザー登録時にプリセット。生年など
      • 提携パートナーにはより詳細な属性
    • Y!提供APIの活用
  • 導入構成図の事例
    • Webサイトの連携: authorization code
      • ①Auth endpoint → code入手
      • ②codeでToken endpoint → id_token, access_token, refresh_tokenを取得
      • ③id_tokenをチェック、リソース活用
    • クライアントアプリ連携(implicit)
      • id_token, access_token → アプリ内ストレージに保存
    • resource id credential
      • ①デバイスのUUID → YID発行API Y! ID, passwordの発行 → 保存
      • ②Y!ID passwordでYConnect → access_token, id_token
  • 裏話
    • OAuth1.0, BBAuthはすべてY!incのローカライズ
    • 全WebAPIのSSL化(署名不要になった代わりに全SSL化)
    • 翻訳プロジェクトへ業務として参加
    • Appleからのreject例
      • 課金アプリでのブラウジング
      • ブラウザから「新規登録」リンクがあるとreject → iTunesから課金しろ
      • Safariを使ってログインしたらreject → OAuth2.0の仕様どうしよう
        • ログインしないと使えないものはrejectされるのかなー
    • 認証PF一覧
      • 用途によって認証PFがバラバラだった。ユーザー識別子もバラバラだった → YConnecetですべて統一
  • 機能拡張
    • PPID
    • OTP(one time password)
    • シングルログアウト
    • IDの質向上: 連携強化(自治体/金融をターゲットに)
  • OpenID Connect → 爆速で追っていきます!
  • Q&A
    • Q: (asyoulike007) implicitはスマートフォンでwebだけ? → アプリも
      • 課金もそのまま使える? → y
      • セキュリティー上の懸念は何か考えたか
      • 提供するSDKの中にも組み込まれている。トークンは暗号化して保存。アプリではアプリでしかアクセスできないストレージに入れるよう要請
        • jailbreakされる場合などは端末所有者の自己責任とするなど
    • Q: 導入事例のなかでここが良かったは?
      • id_tokenは特に便利という話は聞かないが…
      • access_tokenによるなんちゃって認証だったのが、ちゃんと認証できるようになった
      • 属性情報が信頼できるのはメリットとなっている
    • Q: カスタムURLスキームで後勝ち/先勝ちの問題はどう考えているか
      • Y!アプリのスキームでは外のアプリとカブらないようにしている → 外にもらさない
        • バレちゃって真似されないということ? → Androidではユーザーが選択できる。真似される件は今後の課題
      • 外部のアプリではカブってしまう場合がある → 懸念が残る
    • Q: 提携パートナーに属性を多く提供というのはclient_idで区別? → そのとおり
      • 公開クライアントでは使えなくしている? → 特にやっていない。WebサービスはsecretでBASIC認証してもらう
        • クライアントアプリはsecretによる認証なし
      • 提供アプリのclient_idがわかってしまうと困る? → return_uriで制御
      • (nov)以前のidconでも扱いましたがimplicitは難しいですねー
      • (nov)YConnectはOpenID Connectの商用実装の世界第1号ですよね?
        • → こんなツイートも

実際に運用されているというYConnectだけに裏話が面白かったです。

(20:00)

「C向けサービスで2要素認証を普及させるためにできること」

  • 株式会社ミクシィ 伊東 諒 氏
  • 去年話題になったネタ
    • パスワード管理
    • ログイン画面のURL
    • 2要素認証 ← 今日の話題
    • C向けだとID+passwordからの脱却は難しい。2要素認証でがんばっている
  • 現状と課題
    • 金融系、ゲームなどでは以前から昔及
    • ユーザー数の多いサービス、メールプロバイダ: パスワード使い回しが問題
    • 実装方法: ワンタイムパスワード: メール/SMSで送信など
    • ID/PW認証 + α
    • ハードウエアトークン → コスト高; ソフトウエアトークン → 鍵; 時計がずれたら? など
    • 脆弱性や課題については黙認状態
      • 銀行の乱数表がごっそり抜かれる時代なのだが
  • 2要素認証: ユーザーは各サービスごとに登録
    • よく聞かれるつぶやき: 「○○も2要素認証対応してほしい」
  • 普及への課題
    • ついてこれないユーザーがいる: サービスごとの設定はめんどくさい
    • 導入しにくいプロトコル: POP/IMAP/SMTP, XMPP……
      • 認証とリソースアクセスの結びつきが強いと2要素を導入するスキがない
      • → Googleではアプリ固有パスワードで逃げている
  • 解決案
    • 設定がめんどい → 強い認証しているプロバイダの下にぶら下がる (G, f, Yなど)
    • 認証とリソースアクセスの結びつき → OpenID Connectのaccess_tokenを使おう
      • 認証とリソースアクセスを分離
      • Andouroidの場合だったら、パスワード設定しないでaccess_tokenだけでOTP認証する。その強度にしたがってメールのやりとりをするなどはどうか
  • OpenID Providerは何をやるべき?
    • 「認証強度の見える化」
      • RPから見て、OPがどんな認証してくれるかわかる
      • ユーザーから見て、どんな認証してくれたのかわかる
    • RPが認証強度を要求
      • OpenID Connect仕様の"acr"パラメータをうまく使えばいい
  • RPがやるべきこと
    • 自分達のサービスに必要な認証強度を意識する
    • 適切なタイミング・強度で再認証を要求する
      • 銀行の例: ID/PWで残高見れる; 送金には乱数表が必要
  • 残る課題
    • 2要素認証を採用しないOPはオワコン?
      • 自サービスで課金しないとか
      • 認証よりもAPIを使ってもらいたいサービスではなかなか実装してくれない
    • 1ユーザーは1OPしか使わない風潮?
      • VPN経由で社内に行く場合など別PWが必要 → ID/PW+αでは組み合わせにくい
  • 追加認証に特化した認証プロバイダは面白いのではないか
    • どうやってもうけるかはまだわからないけど
    • RP側が既存OPとの組み合わせを使う → 柔軟な実装が可能
    • trustが重要
      • B向けに実績のあるサービスがC向けに出てきてくれるとうれしい
    • 物理デバイス、生体認証などの可能性
      • ID/PWの代替としては難しいが、オプションとしては使い途があるのでは?
  • まとめ
    • 普及のカギ: 「めんどくさい」
    • OpenID Connectは重要(OPの集約など)
    • 追加認証に特化した認証Pも面白い
  • 作ってみた!
  • 作ってみてわかったこと
    • メアドを識別子として使うとメアドの確認がめんどう
      • YConnect, Google, facebookでは認証済メアドを提供してくれる
      • フィッシング被害などのリスクがあってなかなか国内では提供しにくいよねー
    • Google Authenticatorを使う(Server側の処理)
      • ユーザー単位にSecret生成
      • 設定用のQRコード生成 → 中身を見てみると……
        • otpauth://totp/(メールアドレス)?secret=(base32_encoded_otp_secret)
      • ritouのブログを見よ
      • アプリをインストールし、QRコードを読み取ると、時計にしたがってコードが変わっていく
    • リモートログアウト
      • 不正利用対策、ログアウト忘れ
      • Facebook, Googleではリモートログアウトを実装
    • OpenID Connect Session Management
      • OPのログアウトをRPから検知するための仕様
      • AuthZ Responseにセッション識別子をつける
      • iframe + postMessageを送り続ける。ユーザー情報が変わったことを検出
    • 組み合わせてみる
      • 公共のPCでログイン → ログアウト忘れて帰宅
      • 自宅PCでログイン → リモートログアウト
      • RPはブラウザ起動時、悪い人が使おうとしたときにOPと交信 → ログアウトを検知
  • #idcon miniやるよー
    • 少人数、USTなし
    • アンカンファレンスもどき
    • 技術屋が気になることをじっくりと話せる場

追加認証プロバイダは面白そうですね。クレデンシャルで独自性も出せそうです

(20:25)

宣伝

  • JICS2013
  • OAuth翻訳プロジェクト
  • OpenID Foundation Japan会員企業募集中

(20:30) 休憩

パネルディスカッション「スマデバ時代ぼくらは幾つパスワードを使うのか 」Ustなしの予定

  • "SSL/PKIはなぜ危機に陥ったのか"
  • "二要素認証やバイオメトリクスは流行るのか"
  • "僕らは10年後いくつのパスワードを使い分けてるのか"
  • "スマデバで普通に使えるアクセス管理へ向けた課題を展望する"
  • モデレータ: ヤフー株式会社 セントラルサービスカンパニー 技術調査室 室長 楠 正憲 氏
  • 米国・OpenID Foundation 理事長 崎村 夏彦 氏
  • 独立行政法人 情報処理推進機構 神田 雅透 氏
  • セコム株式会社 IS研究所 松本 泰 氏
  • OpenID Foundation Japan 事務局長代行 高橋 伸和 氏
  • 諸注意
    • このパネルはustしてません
    • ふつうのしゃべってることはつぶやいてもOK
    • 「オフレコ」部分はブログに書いたりつぶやいたりしないでね
  • 楠さん: パスワードっていつからあったのか
    • 1961年IBMのメインフレームでTSSが動いた時点でパスワードがあったはず
    • パスワードはもっと早くなくなると思ってたのに
    • 公開鍵暗号の出現により、なくなると信じていた
      • サーバー証明書としては普及したけど
      • 楕円暗号にもならずRSAの鍵長を長くしながら使い続けている
  • オープンデータのアイディア募集 IDEABOX
  • OpenIDの出現により、MS Passportが全部持っていく、ということにはならなかった
    • とはいえ、いまでもいつまでもたくさんのパスワードを覚えていないといけない
    • 10個以上パスワードを覚えられる人はいないだろうが、それでネット生活は心もとない
  • 去年のIIWではFederated IDに対して批判的な議論もあった
    • 心配: 「UX too hard」ID/PWだけでもこれだけ複雑なのにOTPとかみんな使えるのか
  • PKI基盤が2011年くらいからキワドイ状況。守り続けていけるのか
  • 神田さん: SSL/PKIはなぜ危機におちいったのか
  • 「PKI Day 2012」から資料を取ってください
  • ネットの信頼性ってどう担保されてるの
    • 技術/制度・運用/実装/ユーザリテラシ ← この4つのどこでも狙われるよ
  • ルートCAはPKIのTrust Anchor
    • 悪い人が何をしたいか: ルートCAに保証された中間CAになりたい
  • 公開鍵証明書が悪用されるのってどんな時?
    • 運用の問題
      • 登録局での検証ミス: 信頼の低い者を登録しちゃう(Comodo)
      • 認証局への不正アクセス (Diginator, TURKTRUST)
    • 技術の問題
      • 暗号強度が弱い
      • 証明書が偽物 (Flame, RapidSSL)
  • Diginotarのケース
    • CA機能を乗っ取られた
    • 6つのCAに不正侵入された → 500枚以上不正に証明書を発行されていた
    • ルートCAのずさんな運営管理/見過ごした監査体制
      • イラン在住の人がGmailにアクセスしたときに不正が発覚
      • 5週間以上対策を打たなかった
    • 不正*.google.com証明書のOCSPリクエストが急増していた → 監視でわかったはず
  • なぜ1か月も放置されたのか
    • 一般の人が使うときに証明書が正しいかどうか意識していない
    • OSの証明書チェックが正しい前提で自動で走っているから
    • Windowsだって設定すればOCSPのリアルタイム検証も可能なのに
  • (オフレコにつき割愛)
  • 楠: 20年も経ったら暗号なんて解けるよってわかっていたんじゃないの?
  • 高橋さん: 黎明期、cyber trust japan立ち上げ → verisignフェロー
    • PKIは技術+運用が一体になって初めて成立する
    • 認証局をビジネスとして立ち上げたときはここまでは想像していなかった
      • 昔のNetscape, MS IEはルート認証局は3つくらいしか入ってなかった。ハードな運用仕様を組んでやっていた
  • (オフレコにつき割愛)
  • 松本さん: idconは初めて。神田さんも。away感ある
    • 去年PKI攻撃とその対抗というパネルディスカッションをした
    • 「暗号アルゴリズムの2010年問題」など
    • 電子政府: 適正な認証レベルをねらわないといけないが、どんどん高くなってしまう
  • ここ2〜3年、認証局の証明書が狙われている。昔からあったんだろうけど、顕著化している
    • trust anchorとして広く根づいているので、そこを取ればいろいろできるから
    • いま一番あぶないのはコード署名
  • ビジネスの話がわからないとわからない。証明局はもうかる商売じゃない。その中でweb for trust CAという「一見カッコイイ枠組」ができた。機能してるかというと……?
    • 競合やstakeholderが多数いる中でやっていくので難しい
  • (オフレコにつき割愛)
  • 楠: デバイスのレイヤーが安全じゃないとダメ。もうひとつはwebが頼られてきた中で起こった事件ではないか。この先federationとかなるとwebがますます重要になるのだが
  • 崎村さん: OAuth2ってsecurity propertyが全面的にSSLに頼っている。ここをちゃんとやってくれないと世界が崩壊する
    • アプリレベルで暗号・署名という防波堤もあるが、やってくれる人はほとんどいない
    • インフラとしてのPKIにはもっとがんばってもらいたい
  • 人の話はすごく難しい。海外の電子政府でデンマークが注目されている
    • デンマーク: ソフトウエア証明書を使っていたがやめた ← ユーザーPCがマルウエアだらけで、そこで署名されたものが信用できない
  • 技術・運用・実装・人をバランスよくやるのは難しい
  • 楠さん: web trustが主犯じゃね?の話
    • MSは独禁法の話があって不当に影響を与えている部分をサードパーティーに出していく必要があった
    • 基準にしたがって広くしていくという圧力がかかっていた
  • イランの不正証明書がわかったのはGoogleが証明書を集めていたから。集中モデルだったから判明したことはアンビバレントである
    • ユーザーを信じて何でもできる時代 → スマートデバイスでは証明書・コードサイニングによりユーザーがしたいことを保証する時代
    • 集中と分散、経済的な要因が大きいと感じる
  • 神田さん: 矛盾ある状況でより安全な世界を作るには?
    • 日本で今何が起こっているか: 特定認証局が14ある
    • 認証局はもうからない → 移行の話がある → 機器をかえろ → ついて来れないCAがある
      • 「あそこがついてこれないから時期をずらす」
    • 安い証明書が出ても、メンテナンスがちゃんとできない。退場のしくみを考えないとtrustが続かない
  • 高橋さん: リテラシーが事業者やユーザーにあって、みんなでPKIを使いましょうという夢があった → ムリゲー → だったらID/PW使い続けましょう
    • 個人的にはID/PWはなくならないと思っている
    • 限界は: ぼくは1password使っているが100個以上入っている。もうムリ。
      • これを減らすためにはfederationしていかなきゃいけない
  • 楠さん: 最後にみなさんからひと言ずついただきたい。100〜200個のパスワードをどう集約するかというとIdP, OPをどう集約するかという話になる。またcredentialとしてパスワードの代替となるものは何か
  • 松本さん: 独占と分散という話ではエコシステムでtrustが形成されるのは重要。それが安全かというところに問題があった
    • いま同じことがNFC携帯にあると思う。felica, NFCは非接触のことだと思う人がいるが、もう一つの側面として鍵管理がある
    • 認証局がいくつも立つ。その中でtrustを組む。フレームワークになる
  • セキュアなストレージが必要。iPhoneやiPadには元々チップが入っている。それを活用して切りくずすことができそう
  • 崎村さん: webではsecure storageをブラウザからJSで使えるようにしようという動きがある
    • パスワードは多分なくならない。証明書にしたところで使うにはパスワードが必要
    • ハンコって使いにくい。でも使うでしょう。法律で規定されたのが702年。大宝律令。MD5同様なくなってもいいと思いつつ、いまだに使っている
  • 神田さん: パスワードマネージャを頼ってはいるが、アプリの作りによって何が起こっているかは実はわからない
  • 2048bitの証明書がいくつか破れている。素因数分解ができちゃった。乱数生成器の性能が悪かった。そういうことが起こっている
  • アプリがやってくれないかなという話と、それがちゃんと動いていることの認証制度がほしいなあ
  • 楠さん: 退出のルールというのは、退出させられて泣く人が出てくるということでもある
  • 高橋さん: 総合すると、デバイスIDは大事。platformer、IDを払い出している人達を見ていくと面白い。次にそこにrelyしている人達。
    • ここ2〜3年が楽しみ。特にOpenID Phoneが!

(21:30)

導入部楠先生の歴史のお話、毎度とても面白いです。そしてオフレコの部分の話題は本当に興味深く聞きました。

パスワードはなくならないですね…。一昔前はパスワードをコピペさせないのがセキュリティーだというときもあったと思いますが、今はパスワードをコピペできないと逆にセキュアなパスワードを使いにくいです(auto typeがありますが)。パスワードを入力させると、必ず「パスワードを忘れたときはこちら」も作らないといけないのが大変です…。

この後の懇親会にも参加させていただきました。抽選会では秋田の猫が1発目に来るとふんだのですが2発目でしたねー。惜しかった。

(記述が誤っている/発言意図と違うなどありましたらご指摘いただければ幸いです)