OAuth-J, ネットワーク強靭化に対応したOAuth Optical Transport Profile を発表。仮想通貨技術を応用。

【AF電 東京】OAuthファウンデーション・ジャパン(OAuth-J)は2018年4月1日、インターネット分離にも対応したOAuthの新たなプロファイル、OAuth Optical Transport Profile (OAuth OTP)の策定を開始すると発表しました。

OAuth [RFC6749] はGAFAM (Google, Apple, Facebook, Amazon, Microsoft)は言うに及ばず、携帯電話会社、銀行、航空会社、マスコミ、政府機関等に広く使われているAPI保護技術でAPIエコノミーの中核をなす技術ですが、通信プロトコル(トランスポート)としてはHTTPSに依存するため、昨今のネットワーク強靭化の流れによってインターネット分離が行われた環境では、クライアントが内部ネットワークに存在し、認可サーバがインターネット側に存在1するなどのように、複数の接続されないネットワークにサーバが分散してしまうと、処理が実行できないという難点がありました。そのため、ネットワーク強靭化をほどこすと、APIエコノミーから取り残されてしまうリスクがありました。

OAuth OTPではこの課題を解決するために、HTTPSに代わり内部ネットワークと外部ネットワークの間で使う光学トランスポートを導入します。具体的には、ブロックチェーンを使った仮想通貨取引の安全性を上げるためにしばしば使われるペーパー・ウォレットで使われている二次元コード技術を使い認可要求と応答を紙に印刷し、それを逆側ネットワークに接続した光学リーダで読み込むことによって処理を行います。要求の二次元コード化にあたっては、4桁のNonceと呼ばれるユニークIDを別途生成しその中に含め2、応答にも同じIDを含める3ことによって、コード挿入攻撃4にも対応します。また、紙を光学リーダで読み込む形をとるため、USBメモリを使う方法と異なり、サプライチェーン汚染5を通じたBadUSB6攻撃にも対応しています。

OAuth Optical Transport Profile は、ブロックチェーンを用いた仮想通貨取引にも使われるペーパー・ウォレット技術を利用しているため、BadUSB攻撃などにも対応。

なお、本規格案は、この発表に先立ち、2017年度中にIETFにI-Dとして提出する予定でしたが、エディタのナット・崎村氏によると「エイプリルフールだからといって、2017年度が終了したなどとの悪質な嘘を着くことは許されない。」とのことで、本日段階でまだ提出は行われておりません。

OAuth-Jのエグゼクティブ・ディレクターであるノヴ・真武氏は、本件についての期待を以下のように述べております。

「本規格案は、多くの日本の組織をAPIエコノミーからの脱落から救う決定打であるが、この恩恵は日本だけでなく、それを見習うアジアその他の多くの組織にも広げられるだろう。そのため、OAuth-Jとしては宇宙標準化機構(Universe Standardization Organization)へも規格案を提出し、USO番号も取得したいと考えている。番号としては800番台の取得が望ましいと考えているが、昨今の番号振り出しの状況をみると、希望が通るかどうかは予断を許さない。」

4月2日追記

4/2 にネタバラシするのがマナーらしいので書きますが、これ、ちゃんと動くと思いますよ。使いみちがあるかは要検討ですが。ちなみに、図中のQRコードは本当にOAuthのRequest/Responseになっています。ただし、Codeフローになっています。実際に分離ネットワークで扱う場合にはCodeフローだともう1往復しなければならないので現実的ではありません。Implicitにすべきでしょう。

その場合、Access Tokenが平文でQRコードに印刷されてしまいます。このような作業をする場所には当然監視カメラを設置するでしょうから、その画像などから漏れて当該Access Tokenが使われる恐れが出ます。なので、Access Tokenは、暗号化するか、Sender Constrainedにする必要があります。前者はRFC6749でカバーできなくなりますし、その他のことで漏れたときの影響もあるので、後者が良いでしょう。その場合、Client は事前にASに自らのPublic Keyを登録しておいて、ATにkeyhashを入れ、MTLSと組み合わせて使うような形が考えられます。そうすれば、リソースが内部ネットワークにあるのであれば、外部ネットワークへの接続は必要なくなります。リソースが外部ネットワークにある場合は、データ取得までを外部ネットワークで行って、データを内部ネットワークに持ち込んでから作業をするのが現実的でしょう。

また、QRコードを印刷するときに、その有効期限は人間が読めるように印刷するべきだなと思います。そして、それが過ぎたら廃棄か、アーカイブ行きですね。

脚注

  1. 扱うリソースが個人識別可能情報[JIS X 9250]である場合、個人は基本インターネット側にいるため、認可サーバはインターネット側にある必要があります。
  2. state変数を使うので、既存のOAuthと互換性があります。
  3. RFC6749によって自動的に満たされます。
  4. 認可要求と応答のバインディングが弱いことを利用して、認可コードを別に取得した認可コードで差し替える攻撃。別名、カット・アンド・ペースト攻撃。
  5. ある製品が工場を出荷されてから使用者に届くまでのサプライチェーンの中で、その製品を置き換える、ソフトウェアを仕込む、悪環境において限界性能を落とすなどする攻撃。倉庫、トラックの荷台などが狙われやすい。Amazonを通じて購入した仮想通貨用のハードウェア・ウォレットがこの攻撃にあっており、仮想通貨がすべて抜き取られるなどの事例も起きている。軍事用品では特に大きな問題になっており、米国防省では国防授権法にて、流通を通さず、生産者から直接購入することでそのリスクを減らすよう義務付けています。
  6. Black Hat USA 2014で発表された攻撃。USBファームウェアを使って接続されたデバイスを騙し、データ抜き取りなど様々なことを可能にする。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください