idcon 16レポート

5月24日に行われた #idcon #16に行ってきました。ヒカリエ21Fの:DeNAセミナールームです。

今回はconsumer secretの秘匿、IIW報告などディープな話が聞けそうです。

(19:10)

OIDFJからごあいさつ

「公式Twitterアプリに望まれる認証鍵の難読化とリバースエンジニアリング対策(仮)」

  • フリーソフト作家: ベクターなどで公開
    • Application Blocker
      • User32.dllをロードするときに、ポリシーを参照して、特定プログラムをブロック
    • Windows 2000拡張カーネル
      • レガシーカーネルを使いたい。.Netアプリや最新ブラウザ、メディアプレイヤーなどが動作可能
  • もふったー
    • Win95で動くuser stream対応のtwitter client
    • MS Unicode, OpenSSL, GDIPLUSを使い、日本語にも対応、アニメアイコンも対応
    • Win95デザインのレガシーな見た目がクール
  • 本題: GIGAZINE記事のネタ: consumer secret keyの難読化について
    • twitterクライアントのConsumer key, Consumer secret key
    • Q: consumer secret keyは難読化しないといけないのか
    • A: 公式の開発ページに「never be human-readable」とある
    • ところがtwitter公式アプリでは生で読める状態だった(メモ帳で開くだけで見える)
  • もふったーの難読化1
    • ハッシュ化していたが、実行時にメモリダンプすると見えてしまう
  • もふったーの難読化2
    • 必要なときにsecretを部分ごとに取り出せるようにしてみた
    • HMAC計算の途中で見えてしまう。メッセージが空白なのでpadとxorしただけのものが見えてしまう
    • 対策
      • メッセージが空白ということは定数なので、ハッシュ済のものを持っておく
      • padのxorを行う関数もひとつにした(ブレークポイントを置けないように)
  • もふったーの難読化3
    • メッセージが長い場合のSHA-1計算2回目が難しい
    • プログラム中の他の部分とxor。どこだかはわからない
  • おまけ: リバースエンジニアリング対策
  • Q&A
    • nov: Windowsの場合の話だったが、iPhoneとかだとどうかくしたらいいのか
    • BlackWingCat: 開発環境でないとそもそも見られない。少し難読化した方がいいだろう。Javaだと逆コンパイルで見えてしまう場合もある。公式アプリは特権を持っているので、漏れてしまうと困る
    • nov: 公式アプリだからって特権(rate limitを上げるなど)を与えなければいいのに
    • lef: じゃあどこまでやったら納得いくのか。最後の最後は読まれてしまうのは避けられない。みんなここまでやれるんですかというバランスの問題。実際どうだった、やりすぎだったのか
    • BlackWingCat: うちのは公式アプリではないし有名でもなかったので、ここまでやる必要はなかっただろう。しかしkeyを抜かれて悪意あるアプリに組み込まれると信用を失ってしまう。最低限の難読化は必要だろう
    • ?: secretをサーバーに置いて、トークンだけをクライアントにもらってくるようにしたらどうだろう
    • → nov: OAuth1.0aだとリクエストごとに署名が必要なため、クライアントがsecretを知っていないと
    • → BlackWingCat: サーバーでproxyしてやればOK → それならブラウザアプリでいいじゃん
    • → nov: OAuth2.0ならば、トークンだけ渡してやればいい
  • nat: dynamic client registrationでインスタンスごとにsecret作るしかない。これ以上はOSの支援でクライアントのハッシュを得るなどが必要
  • mad_p: 抜かれて困るのは、自分のクライアントの名をかたって悪意のあるクライアントを作られるリスクだけか? エンドユーザーもサーバーも困らない。アプリ作者だけが困る
    • nov: 公式アプリのsecretを使ってtwitterphishingサイトを作ることができる。多くの人が使っている公式アプリをbanしにくいだろう
    • nov: nativeアプリのcredentialを抜いてnativeアプリで使われる分にはApp Storeのような仕組みでなんとかなる。iframeでいたずらされると困る
  • lef: twitterにOAuth2対応してくれ、でFA。開発者としてはつらい
  • ?: API1.1から、いくつかのAPIではOAuth2.0ベースで実装されている部分もあるようだ
    • nov: twitter anywareは裏でOAuth2のような何かを使っていたようだ。実装は持っているのに公開していない印象
  • 感想: 懇親会などでも、結論は OAuth2.0にしてdynamic registrationを使う、ということのようです。refresh_tokenも永続化するのであるし、dynamic registrationは難しくないとのこと

(20:00)

休憩

(20:10)

「IIWでセッション立てたよ(技術者じゃないけど) -- IIW#15報告」

  • @IdentityPenguin
  • 本職は社会科学と技術の関わりについてを研究している
  • IIW#15 (2012/10/23-25)のレポート
    • 会場はおなじみ: Computer History Museum
  • IIW: worshopの進め方…アンカンファレンス
    • 顔を合わせた初日にスケジュールを決める
      • この分野の変化が非常に早い → ニーズはあらかじめわからない
      • 学ぶこと、contributeする情熱を持つ参加者を主体としたい
    • 毎朝セッション座長を立候補で決める
  • 軽い朝食、エスプレッソが提供されている → 食べ物があると人が集まる
  • まずはテーブルに分かれて座る
    • 必ず新人を一人は入れること! by IdentityWoman
    • テーブルごとにお題が配られて、言葉の定義を各テーブルで話し合う。例:「framework」
  • 参加者全員が輪になって座る
    • テーブルごとのお題の紹介 → セッションを立てる
  • セッション「Anonymous」
    • 匿名性について、4chan(米国版2ch)を引き合いに議論
    • Pseudonym(仮名)との違い
    • 「匿名性」の定義についてはうまく合意できなかった
    • Pseudonymは含まれるのか、複数の発言が同一人物とわかってはアウトなのか
  • セッション「Reputation Consulting .05Cents」
    • 1vs1のセッションになってしまった
    • 個人や企業についてのreputation controlの必要性
    • すべて実名でオープンは危険すぎる
      • シリコンバレーはみんな実名でしょ → そんなことはない、シリコンバレーは世界がせまいので、むしろオープンにできない
      • 例: Facebookは家族・親友のみ、LinkedInはオープン。私的なことは名前を変えてblogに書いたり。identity controlが必要。名寄せされたら困る
  • Dinnerで
    • 「Anonymousの逆って何だと思う?」 → 議論がもり上がり、セッションやろうかな
    • セッションやれるよ → やってみよう
  • セッションの立て方
    • 誰でもOK!
    • 1セッション50分
    • 自分でテーマを決め、色紙に書き、早い者勝ちでセッションボードに貼っていく
    • 大きい紙にトピックを書く、ふせんが部屋になっている
    • 本当に早い者順
    • 会場にてログ係(note taker)を指定する
  • セッション「What is Real Name」
    • 17名
    • note taker指名しなかったら誰も取っていなかった
    • 口火を切った人は、何度も実名が変わっている人だった
    • そもそも実名って変わるものじゃないの? 実名は変更できるの?
      • 法律の問題
    • Williamの愛称はBill。同一人物の担保が必要な場合も
    • 個人の識別と特定に必要な情報は何か?
      • 同姓同名の人がいれば別の属性が必要。居住地、髪の色など
      • 名前空間の大きさにもよる。国家・コミュニティーによって違う → サイズによるのでは?
    • 実名はなぜ必要か?
      • Reputationに結びつく
      • 信頼を担保する。社会のしくみとして必要
    • それなら、国に登録している名前でなくてもいいのでは?
  • やってみて
    • unconference形式 → 手を挙げてやってみると得るものは多い
    • 議論はできた
    • ログは残しておくこと!
      • フレッシュなものを議論する → フレッシュなものほど残しておくべき
  • 「最後に名寄せしておきます」ということで@IdentityPenguin の中の人は@oritakoさんでした。山中さんのビデオで言われていましたが、あれはプライバシー侵害ですよねー、自分の望まない名寄せは困るよねー、との指摘
  • nat: その1v1だったreputationの本書いた人ってRandy Farmer?
    • IdentityPenguin: わからない。名刺ももらったんだけど…
  • nat: real nameの話で、範囲が小さいと属性が少なくてすむ、大きくなると属性がたくさん必要というのがあった→これってISOの定義そのもの。ある範囲で特定するに足る十分な属性の集合。日本人はidentityと言うと1個のidentifierだと思ってしまうが、属性の集合としてとらえるべき
    • IdentityPenguin: なるほど! 実生活での実名の考え方とISOの定義がつながってすっきりした

(20:38)

「IIW #16に参加してきた。Sponsored by GREE

  • @nov
  • IIW参加は2回目。GWあけ直後
    • 前回は有給取って自費で行った。今回は会社が出張扱いにしてくれた
  • 会場はいつも同じ: Computer History Museum
  • session creation
    • personal cloudがバズってた
  • 大きな部屋は30人くらい。小さな部屋は8人会議室に15人とか。廊下もあり
  • NotesがWebで公開される
  • セッション「Mobile SSO」
    • Sascha Preibisch, Layer7
    • エンタープライズ分野のiPhoneに特化したSSO
    • Connectそのままはないが、OAuthするときにid_tokenを発行 → 同じベンダーでだけshareできるkey chainに入れる
      • アプリA1を認可した後、同じ会社のA2を入れると、認可の必要がない
    • mssoというスコープをつける
    • generate RSA key pair on client side (OPTIONAL)
      • 複数のアプリがそれぞれIdPになる
    • nat: OpenID Foundationでもうじきこの手のことのworking groupができる
  • セッション「Mobile SSO」
    • George Fletcher, AOL
    • モバイルのネイティブアプリと同じデバイス上のwebブラウザ
    • webssoというスコープでaccess_tokenを取る
      • webssoにdown scopeしたtokenをrefreshで取って渡す
    • ID tokenをweb appに渡すような感じ
  • 「Auth@Google - Next 5 Years」
    • Eric Sachs, Google
    • Google docsに資料あり
    • 過去5年何をやったか: リスクベース、2要素、OpenId, OAuth
    • good news: アカウントhijackされてスパム配信されたアカウント数。リスクベースでかなり減った
    • bad news:
      • OpenIDへのmigrationは難しかった。usabilityに難あり → account chooserへの流れ、account linking: 同じメアドのときに同じアカウントにするか分けておくべきか → RPの人達が考え込んでしまう
      • Account recoveryがアキレス腱
    • 今後5年間
      • 5年前にやろうとしていたことと5年間でやったこととは結構違っていた。スマホが流行ったとか
    • Setup, not sign-in
      • ネイティブアプリはインストール時にログインしたらそれっきり。クラウドのwebサイトはいつもログインし直し
      • webでもsetupすればいいんじゃないか。OSレベルのaccount managerが必要
      • account switchの機能もOSレベルで提供
    • Reduce Bearer Tokens
      • OAuth 2.0のaccess tokenはbearer
      • JWT bearer tokens
      • セッションクッキーもbearer
      • → こいつらをもっとsecureにしたい
      • self-signed cookie: ブラウザ内にキーペアを生成、サイトにpublic keyを登録
      • chrome://settings/cookies に行くと「チャンネルID」と出るのがそう
    • Smarter Hardware
      • Chromeでサイトにアクセスするとリスクベースの確認がAndroid側に出る
      • バイスのunlock/activationをすでに持っているdeviceを使って行う。google device同士だとできるんだけど → 標準化したい (FIDO ファイド Alliance)
      • nat: PayPalが中心になっている。これを標準化したい
      • universal second factor
      • yubikey: USB keyboardとしてワンタイムパスワードを入力してくれる、安いデバイス
  • 「OAuth & JOSE @ BlueButton+」
    • Justin Richer, MITRE
      • OAuth, OpenID ConnectのMLによくいる
    • OAuth2のdynamic client registrationのauthor
    • use caseとしてBlueButton+というのを作っている
    • 「trusted registration」
    • BlueButtonとは: ヘルスケア情報を患者が自分でアクセス可能にする
    • nat: 退役軍人さん達が自分の健康情報を取ってお医者さんに持っていく
    • class: クライアントのテンプレート
      • registration_jwtを発行 → nativeアプリにうめ込む
    • instantiation: Dynamic client registration
      • registration_jwtを使ってtrusted registrationできる
    • discovery: OAuth2にはまだない。
      • registry discovery: エンドポイントを見つける
      • providers authサーバーのリスト
      • provider ひとつのプロバイダのエンドポイントリスト
      • apps discovery AuthZがクライアントのリストを確認
    • push authorization
      • あるユーザーに定期的に過去3か月間の通院記録を送るための認可
      • authorizationだけして、access tokenは発行しない
  • Personal Cloudがよくわからなかった
    • nat: lifelog managementに近い概念かも
    • nov: パーツが全部クラウドにあって、どのパーツにどのベンターを使うかを自分で選べる
  • nov: device上にkey-pairを作ってseld-issuedみたいなのが面白かった

(21:20)

懇親会

  • :DeNA様ご提供のフードとビールをいただきました。ごちそうさまでした
  • @flano_yuki さんから「OAuthたん」ステッカーが配布されました!
  • 秘密の質問と答の流出事件、マイナンバー法案、OAuth2 dynamic client registrationなどが話題になっていました
  • 個人的にはnatさんからOpenID ConnectのRequest File Methodを聞き、興味を持ちました。Open ID Artifact Bindingと呼ばれていたものですね。このメソッドではリクエストが業務に必要な情報しか取得しないことを第三者機関によって検証できるそうです。法律の要件に合致することが認められれば、ユーザーの同意画面をスキップ可能とのことです。ちょっと詳しく勉強してみようと思います

以上です。誤りや発言意図と違うなどあればご指摘ください。