idcon 16レポート
5月24日に行われた #idcon #16に行ってきました。ヒカリエ21Fの:DeNAセミナールームです。
今回はconsumer secretの秘匿、IIW報告などディープな話が聞けそうです。
(19:10)
OIDFJからごあいさつ
- インド、ブッダガヤにいる山中さんから動画が届いています
- 江川さんからイベント告知
「公式Twitterアプリに望まれる認証鍵の難読化とリバースエンジニアリング対策(仮)」
- @BlackWingCat (黒翼猫)
- スライド
- [補助資料] 超軽量Twitterクライアント「もふったー」コンシューマシークレットキー難読化最後の挑戦 - GIGAZINE
- フリーソフト作家: ベクターなどで公開
- Application Blocker
- User32.dllをロードするときに、ポリシーを参照して、特定プログラムをブロック
- Windows 2000拡張カーネル
- レガシーカーネルを使いたい。.Netアプリや最新ブラウザ、メディアプレイヤーなどが動作可能
- Application Blocker
- もふったー
- 本題: GIGAZINE記事のネタ: consumer secret keyの難読化について
- もふったーの難読化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: 抜かれて困るのは、自分のクライアントの名をかたって悪意のあるクライアントを作られるリスクだけか? エンドユーザーもサーバーも困らない。アプリ作者だけが困る
- 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」
- セッション「Reputation Consulting .05Cents」
- Dinnerで
- 「Anonymousの逆って何だと思う?」 → 議論がもり上がり、セッションやろうかな
- セッションやれるよ → やってみよう
- セッションの立て方
- 誰でもOK!
- 1セッション50分
- 自分でテーマを決め、色紙に書き、早い者勝ちでセッションボードに貼っていく
- 大きい紙にトピックを書く、ふせんが部屋になっている
- 本当に早い者順
- 会場にてログ係(note taker)を指定する
- セッション「What is Real Name」
- やってみて
- 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で公開される
- http://iiw.idcommons.net/IIW_16_Notes
- 赤いリンクはノーツがないよ
- セッション「Mobile SSO」
- セッション「Mobile SSO」
- 「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
- Smarter Hardware
- 「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は発行しない
- Justin Richer, MITRE
- 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と呼ばれていたものですね。このメソッドではリクエストが業務に必要な情報しか取得しないことを第三者機関によって検証できるそうです。法律の要件に合致することが認められれば、ユーザーの同意画面をスキップ可能とのことです。ちょっと詳しく勉強してみようと思います
以上です。誤りや発言意図と違うなどあればご指摘ください。
