ホーム > sakimura

sakimura

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

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

  • 2018/4/1 9:00
  • sakimura
  • .Nat Zone in OAuth, oauth, ネットワーク強靭化, ブロックチェーン, ペーパー・ウォレット, 仮想通貨

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

To Top