暗号化と圧縮、どちらを先にするべきか?

こんなことを想像してみてください。

あなたは大企業で働いています。仕事はかなり退屈です。端的に言えば、あなたの顔も見たくないという経理担当の3人しか使わないようなアプリケーションのために定型的なコードを書いて、才能を無駄にしているという状況です。

あなたが本当に情熱を注げるのはセキュリティです。毎日、r/netsecを読み、仕事の後にはバグ報奨金プログラムに参加しています。ここ3カ月間は手の込んだ株式取引ゲームをプレイし、報奨金を得ています。ヒープベースのバッファオーバーフローを発見し、優良株を選ぶ手助けとなるAVRシェルコードをいくつか書いたからです。

あなたが取り組んできたビデオゲームが、実は巧妙な偽装のリクルートツールであったと判明し、全てが変わります。世界最高のセキュリティコンサルタント会社、Mont Piperが人材を募集していて、あなたは面接に行くことになったのです!

飛行機やUberを使って目的地にたどり着いたあなたは、いずれ自分の上司になるであろう人物と向かい合って座っています。ノルウェーのメタルバンドTシャツを着て、屋内でもサングラスをかけたままのGaryという名前のちょっと汗ばんだハッカーです。

あなたは面接開始から大変気合いが入っています。プライバシーと匿名性の違いについて熱弁しています。同一生成元ポリシーについても事細かく説明し、これを攻撃者がうまく回避する際の3つの方法についても話します。さらに、__fastcall__stdcall、それぞれの複雑さについてはホワイトボードも使って説明します。ようやく最後から2番目のセクション、プロトコルのセキュリティに関する話題になったところです。

Garyはあなたの目を見てこう言います。「あなたはネットワークプロトコルの設計をしているとしたら、データを圧縮してから暗号化しますか? それとも、暗号化してから圧縮しますか?」そう言いながら、両手をぎゅっと組み合わせて握り、笑みを浮かべます。

これは、セキュリティに関する面接では古典的な質問です!


一息ついて、考えます。

高いレベルでは、圧縮は、データのパターンを使ってサイズを小さくします。暗号化は、キーがなければデータ内のパターンが全く分からなくなるよう、データをシャッフルします。

暗号化は、ランダムに見えるようなアウトプット、つまり高いエントロピーをもつビットを寄せ集めたものを生成します。一方、圧縮は、ランダムに見えるデータに対しては、その効果を発揮しません。実際のところ、エントロピーは”圧縮可能な”データかどうかを決める尺度と考えることができます。

そのため、最初に暗号化を行うと、圧縮は役に立たないものになります。つまり、最初に圧縮をしなければいけない、というのが正解なのです! ちょうど、質問&回答サイトのStackOverflowでも、同様に考えられています


あなたはこのことをGaryに話そうとしますが、言いかけて口をつぐんでしまいます。暗号化されたトラフィックの傍受を狙う攻撃者は、十分な情報は得られなかったとしても、メッセージ長は知ることができます。もし、そのメッセージのさらなる情報を得ようとして、どうにかその情報を利用することができた場合、暗号化は失敗となる恐れがあるのです。

あなたはこのことをGaryに説明し始めますが、今度はGaryがあなたの話を遮ります。「ああ、CRIME攻撃のようなものですか?」

「そうです!」とあなたは答えます。すぐに詳細について思い出し始めます。あなたはキャッチーな名前のSSL攻撃なら全て頭の中で一緒くたに入っていますが、CRIMEがどういうものなのかは、はっきりと認識しているのです。攻撃者はサーバから返される情報の一部をコントロールし、その情報を使って、サーバからの応答メッセージの中にある秘密トークンを推測するのです。応答は、圧縮されたメッセージ長にどのように影響を及ぼすかを見ることにより、秘密に対する推測が正当かどうかを確認できるような方法で圧縮されます。もし、その秘密トークンがAAAAで、推測したものもAAAAだった場合、圧縮後に暗号化された(以下、「圧縮→暗号化」と表記します)応答は、推測したものがBBBBだった場合よりも短くなります。

Garyは感心しているようです。「しかし、攻撃者がどうやってもプレーンテキストのどの部分も全くコントロールできないという場合は? それでも、この種の攻撃は可能ですか?」と尋ねてきます。

CRIMEは、圧縮→暗号化手法が必ずしも正しい決断ではないことの非常に鮮やかな証明でしたが、私は、それより1年前にAndrew M. White、Austin R. Matthews、Kevin Z. Snow、Fabian Monroseが発表した、圧縮→暗号化手法への攻撃が気に入っています。その論文Phonotactic Reconstruction of Encrypted VoIP Conversations(暗号化されたVoIP会話の音素配列論による再構築)に、暗号化されたVoIP通話から会話を再構築するための技法が紹介されています。

その考えは基本的には、「VoIP圧縮は汎用的な音声圧縮アルゴリズムにはならない。その理由は、人間の発話に関するいくつかの仮定に依存すれば、さらに効率的に圧縮することが可能だからだ」というものです。以下に論文を引用します。

現代の音声コーデックの多くは、符号励振線形予測(CELP:code-excited linear prediction)としてよく知られる音声コーデックの変種に基づいており、さらにCELPは音声予測のソースフィルタモデルに基づく。ソースフィルタモデルは音声を2つの信号に分離する。それは、声帯によって生成される励振すなわちソース信号と、声道によって行われる音の成形をモデリングする形状すなわちフィルタ信号である。これにより、音素を区別することができる。例えば、母音は周期的な励振信号をもつが、摩擦音([sh]音や[f]音など)は、ホワイトノイズに類似した励振信号をもつ。
基本的なCELPでは、励振信号は固定のコードブックからとられる項目としてモデル化される(それゆえ符号励振と呼ばれる)。SpeexのVBR(変動ビット伝送速度)モデルのような、CELPのいくつかの変種では、コードワードは、入力フレームの複雑さによって異なるコードブックから選択することができ、コードブックはそれぞれ異なるサイズの項目を含む。フィルタ信号は線形予測を使用して、すなわち、項目が過去の励振信号の線形結合である、いわゆる適応型コードブックとしてモデル化される。各コードブックからの「最適な」項目の選択は、合成による分析(AbS)として知られる処理の出力を最適化するために、潜在的なコードワードの空間を検索することによって行われる。よって、符号化されたフレームは、固定のコードブックの項目と、励振信号の利得(係数)とフィルタ信号の線形予測係数から構成される。
最後に、多くのVoIPプロバイダ(Skypeを含む)はVBRコーデックを使用して、通話の品質を維持しながら帯域幅の利用を最小化する。VBRでは、コードブック項目のサイズ、したがって符号化されたフレームのサイズは入力フレームの複雑さによって変動する可能性がある。セキュアRTP(SRTP)の仕様では元のペイロードのサイズは修正されないので、符号化されたフレームのサイズは暗号化層を通過する間も保持される。したがって、暗号化されたパケットのサイズは入力信号の属性を反映する。この相関関係こそが、音素を暗号化パケット長のシーケンスとしてモデリングするために私たちの手法の活用するものである。

この部分は、論文をうまくまとめています。CELPとVBRの組み合わせは、メッセージ長が複雑性に依存することを意味します。線形予測の方法に起因して、音素と音素の間の途切れのような、音の中の急激な変化を符号化するためには、もっと多くの情報が必要になるのです! 多くの情報によって、著者らは暗号化された音声信号を音素に分解すること、つまりどの音声フレームが発話のどの単位に属するかを判断することが可能なモデルを構築できるようになっています。

次に、最初に使ったパケット情報だけを依然として使用して、分割化された暗号化音声の単位のどれが実際の音素のどれを表すか判断する分類手段を構築します。次に、ある言語モデルを使用して、前ステップの出力を補正し、音素ストリームを単語に分け、さらに句に分けます。

面白いことに、この長々とした手続きは有効なのです。彼らはMETEORと呼ばれる測定基準を使用して、6前後のスコアを達成しました。これは、5を超えると「人間による解釈」と見なされる尺度です。この技法を使って暗号化されたVoIP通話を盗聴する人間がサイバー犯罪の主役となると考えられます。驚異的です!


結末

夜を徹した厳しい審査を突破して、あなたは採用に漕ぎ着けました。その半年後、Mont Piperは巨大複合企業に買収されました。Garyは、ノルウェーのメタルTシャツをボタンダウンシャツに着替えることを拒み、あっさり解雇されました。あなたは今、大銀行に派遣されて、あなたを心底嫌っているチームに「アドバイス」を行っています。でも最近は、機械学習に興味があり、実にクールなオンラインゲームを見つけて3D物理シミュレーションで歩行する6脚のロボットの作成を試みています・・・

P.S.

新しい投稿の通知をお届けします。ニュースレター購読か、Twitterでフォローしてください。

課金情報

毎日のように脆弱性が明らかになっていますが、そのほとんどに関しては、この記事のようなブログ投稿はありません。

私たちのAppcanary製品はアプリとサーバを監視して、あなたが使っているパッケージに新しい脆弱性が発見されるたびに通知します。

今すぐ登録しましょう!