現時点では何と呼ぶべきかよくわからないため、見出しでハイブリッド名で言及しました Microsoft Officeの365.
(Microsoft のワード プロセッシング、スプレッドシート、プレゼンテーション、およびコラボレーション アプリの総称としての「Office」という名前は、 殺された 次の 365 ～ XNUMX か月で、単に「Microsoft XNUMX」になります)。
人々は個々のアプリ名を使い続けると確信しています (Word, Excel, PowerPoint と友人) とスイートのモニカ Office 何年もの間、ソフトウェアの初心者はおそらくそれを 365、ユビキタスな Microsoft プレフィックスを削除した後。
ご存知かもしれませんが、Office スタンドアロン アプリ (実際にローカルにインストールするため、オンラインで作業する必要がないアプリ) には、保存されたドキュメントを暗号化するための独自のオプションが含まれています。
これは、これらのファイルのいずれかを後で誤って、または意図的に、それらを受け取るはずのない人と共有した場合に備えて、セキュリティの層を追加することになっています。これは、電子メールで添付ファイルを共有するときに誤って驚くほど簡単に行うことができます.
ファイルのロックを解除するために必要なパスワードを受信者に提供しない限り、それは受信者にとって千切りキャベツのようなものです。
もちろん、電子メールの本文にパスワードを含めても何も得られませんが、別の経路でパスワードを共有することに少しでも注意を払っていれば、悪党に対する安全とセキュリティを強化したことになります。 、スヌープ、ネアドゥウェルが機密コンテンツに簡単にアクセスできます。
脚光を浴びるOME
それとも持っていますか？
による 研究者 フィンランドのサイバーセキュリティ企業である WithSecure では、あなたのデータは、あなたが合理的に期待しているほど保護されていない可能性があります.
テスターが使用した機能は、彼らが Office365メッセージの暗号化または OME 略して。
ここでは彼らの実験を再現していませんが、それは単純な理由で、コアの Office、申し訳ありませんが、365 製品は、私たちが仕事で使用している Linux でネイティブに実行されないためです。 Office ツールの Web ベースのバージョンには、フル アプリと同じ機能セットがないため、得られる結果は、Office のほとんどのビジネス ユーザーが Word、Excel、Outlook を構成した方法と一致する可能性は低いです。 Windows ラップトップの友人。
研究者は次のように説明しています。
この機能は、組織が組織内外の人々の間で暗号化された電子メール メッセージを安全な方法で送受信できるようにするために宣伝されています。
しかし、彼らは次のことも指摘しています。
残念ながら、OME メッセージは安全でない電子コードブック (ECB) モードの動作で暗号化されています。
ECBの説明
説明する。
多くの暗号化アルゴリズム、特に エーイーエス またはOMEが使用するAESは、として知られているものです ブロック暗号、個々のビットまたはバイトを順番に処理するのではなく、一度に大きなデータのチャンクをスクランブルします。
一般的に言えば、これは効率とセキュリティの両方に役立つと考えられています。なぜなら、暗号には、アルゴリズムを駆動する暗号クランクハンドルの各ターンで、混合、ミンチ、シュレッド、および液体化するための入力データが多くあり、ターンごとに先に進むためです。暗号化したいデータを通して。
たとえば、コア AES アルゴリズムは、一度に 16 の入力平文バイト (128 ビット) を消費し、暗号化キーの下でそのデータをスクランブルして、16 の暗号化された暗号文出力バイトを生成します。
(混同しないで ブロックサイズ キーサイズ – AES 暗号化キーの長さは、推測されたくない度合いに応じて、128 ビット、192 ビット、または 256 ビットにすることができますが、128 つのキー サイズはすべて、アルゴリズムが「クランキング」されるたびに XNUMX ビット ブロックで機能します。)
これが意味することは、(長さに関係なく) AES キーを選択し、データのチャンクに対して AES 暗号を直接使用すると…
…それから 同じ入力チャンクを取得するたびに、同じ出力チャンクが取得されます.
本当に巨大なコードブックのように
そのため、この直接操作モードが呼び出されます ECB、の略 電子コードブックというのは、暗号化と復号化のルックアップ テーブルとして使用できる巨大なコード ブックを持っているようなものだからです。
(完全な「コードブック」を実際に構築することはできません。128 16バイトのエントリ 可能なキーごとに.)
残念ながら、特にコンピューター形式のデータでは、使用されるファイル形式のおかげで、データの特定のチャンクの繰り返しが避けられないことがよくあります。
たとえば、512 バイト境界 (ディスクに書き込むときの一般的なセクター サイズ) または 4096 バイト境界 (メモリを予約するときの一般的な割り当て単位サイズ) に整列するようにデータ セクションを定期的にパディングするファイルは、多くの場合、次のようなファイルを生成します。ゼロバイトの長いラン。
同様に、すべてのページのヘッダーとフッター、または完全な会社名の繰り返しの言及など、多くのボイラープレートを含むテキスト ドキュメントには、大量の繰り返しが含まれます。
AES-ECB 暗号化プロセスで平文のチャンクが繰り返されるたびに、16 バイトの境界に並ぶたびに、暗号化された出力に現れます。 まったく同じ暗号文として.
したがって、暗号文ファイルを正式に復号化できなくても、入力のパターン (知っているか、推測できるかもしれませんが、または推測する）出力に保持されます。
これは、アドビが現在悪名高い ECB モード暗号化を使用してユーザーのパスワードを「ハッシュ」している理由を説明したほぼ XNUMX 年前に公開した記事に基づく例です。 いい考えではない:
右。 AES-128-ECBで暗号化された画像データ。
入力で白一色のピクセルが出力で繰り返しパターンを確実に生成し、元のデータの構造が明らかなように、青色の部分がある程度規則的に保たれていることに注意してください。
この例では、元のファイルの各ピクセルは正確に 4 バイトを占めるため、入力データ内の左から右への 4 ピクセルの各ランは 16 バイトの長さであり、これは各 16 バイトの AES 暗号化ブロックと正確に一致するため、強調されます。 「ECB効果」。
暗号文パターンのマッチング
さらに悪いことに、同じ鍵で暗号化されていることがわかっている XNUMX つのドキュメントがあり、たまたまそのうちの XNUMX つのプレーンテキストを持っている場合、暗号化されたテキストを調べることができます。 することはできません 解読し、そのセクションを暗号文のパターンと一致させようとします できる 復号化します。
最初のドキュメントがすでに復号化されている場合、そのドキュメントを「復号化」するためのキーは必要ないことに注意してください。 既知平文攻撃.
それ自体が秘密のデータではない、一見無害なテキストの一致がわずかしかない場合でも、敵対者がこの方法で抽出できる知識は、知的財産スパイ、ソーシャル エンジニア、法医学捜査官などにとって金鉱となる可能性があります。
たとえば、ドキュメントの詳細が何を参照しているのかわからなくても、複数のファイルにわたって既知の平文のチャンクを照合することで、明らかにランダムなドキュメントのコレクションであると判断できる場合があります。
- すべて同じ受信者に送信された場合、 それぞれの上部に共通の挨拶がある場合。
- 同じプロジェクトを参照し、 ポップアップし続ける一意の識別テキスト文字列がある場合。
- 同じセキュリティ分類を持ち、 他のものよりも明らかに「秘密」であることを意味するものに集中したい場合。
何をするか？
ECB モードを使用しないでください。
ブロック暗号を使用している場合は、 ブロック暗号操作モード それ：
- IV、または初期化ベクトルとして知られているものを含みます。 メッセージごとにランダムかつ一意に選択されます。
- 暗号化プロセスを意図的に調整する 繰り返し入力が毎回異なる結果になるようにします。
AES を使用している場合、最近選択したいと思うモードは AES-GCM (ガロア カウンター モード) では、IV を使用して毎回異なる暗号化データ ストリームを作成するだけでなく、キーが同じままであっても、 メッセージ認証コード (MAC)、または暗号化チェックサムと同時に、データのスクランブルまたはスクランブル解除を行います。
AES-GCM は、暗号文パターンの繰り返しを回避するだけでなく、復号化したばかりのデータが途中で改ざんされていないかどうかを示す「チェックサム」が常に得られることを意味します。
暗号文が実際に何を意味するのかを知らない詐欺師は、最終的にどのような誤った出力が得られるかを知る (または気にする) ことなく、不正確な復号化を信頼するようにだますことができる可能性があることに注意してください。
同じキーと IV に基づいて復号化プロセス中に計算される MAC は、受信した暗号文が有効であることを確認するのに役立ち、したがって、相手側で最初に入力されたものをほぼ確実に復号化したことを確認できます。
または、専用の ストリーム暗号 これにより、一度に 16 バイト (またはブロック サイズが何であれ) を処理しなくてもデータを暗号化できる、疑似ランダムなバイト単位のキーストリームが生成されます。
AES-GCM は基本的に AES をストリーム暗号に変換し、MAC の形式で認証を追加しますが、そのように動作するように特別に設計された専用のストリーム暗号を探している場合は、Daniel Bernstein の ChaCha20-ポリ1305 (Poly1305 の部分は MAC です)、詳しくは RFC 8439.
以下に、AES-128-GCM と ChaCha20-Poly1305 (ここでは MAC コードを破棄) を使用して取得したものと、 Linux カーネル疑似乱数ジェネレーター。
データが構造化されていないように見えるからといって、それが真にランダムであることを意味するわけではありませんが、ランダムに見えなくても暗号化されていると主張している場合は、何らかの構造が残っており、暗号化が容疑者：
次に何が起こる？
WithSecureによると、Microsoft はこの「脆弱性」を修正する予定はありません。明らかに、Office 2010 との下位互換性のためです…
従来のバージョンの Office (2010) には AES 128 ECB が必要であり、Office ドキュメントは引き続き Office アプリによってこの方法で保護されます。
…そして…
[WithSecure の研究者の] レポートは、セキュリティ サービスの基準を満たしているとは見なされず、侵害とも見なされません。 コードは変更されていないため、このレポートに対して CVE は発行されていません。
つまり、現在 OME に依存している場合は、メッセージを作成したアプリとは無関係にデータを暗号化し、内部暗号化とは無関係に機能する機密メッセージ用のサードパーティの暗号化ツールに置き換えることを検討することをお勧めします。オフィス範囲のコード。
そうすれば、Office 2010 に組み込まれている昔ながらの復号化コードに戻ることなく、最新の暗号と最新の暗号操作モードを選択できます。
記事内の画像の作成方法 sop330.png から始めます。これは、最上部の画像からクリーンアップされた SOPHOS ロゴをトリミングし、2 ピクセルの青い境界線を削除して、PNG 形式で保存することで作成できます。 画像のサイズは 330x72 ピクセルになります。
ImageMagick を使用して RGBA に変換します。 $ convert sop330.png sop.rgba 出力は 330x72 ピクセル x 4 バイト/ピクセル = 95,040 バイトです。
=== Lua と LuaOSSL ライブラリを使用して暗号化します (Python には非常によく似た OpenSSL バインディングがあります): -- データをロード > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- 暗号オブジェクトを作成 > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') --パスワードと IV を初期化します -- AES-128-ECB には 128 ビットのパスワードが必要ですが、IV は必要ありません -- AES-128-GCM には 128 ビットのパスワードと 12 バイトの IV が必要です -- ChaCha20 には 256 ビットのパスワードと12 バイトの IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- 95040 つの暗号でファイル データを暗号化します> aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- ストリーム暗号はバイト単位で出力を生成するため、暗号文は平文と同じ長さにする必要があります> gcmout:len() 95040 > chaout:len() 1305 -- ここでは GCM と Poly128 の MAC コードは使用しませんが、 -- しかし各暗号は 16 ビット (16 バイト) の「チェックサム」を生成します -- 復号化が終了した後に復号化を認証するために使用されます -- 入力暗号文が破損またはハッキングされたかどうかを検出します -- (MAC はキーに依存するため、攻撃者はそれを偽造できません) > base.hex(gcm:getTag(70)) a204605f5cd18bd9c4e36da9cbc74e16 > base.hex(cha:getTag(55)) a97b5d9e3f9cb3a2be4fa040f56b95040ef -- /dev/random から直接 1 の「イメージ」を作成します > rndout = misc.filetostr('/dev/random',#fdat) -- それらをすべて保存します - AES-ECB を明示的に切り捨てることに注意してください -- ブロック暗号出力を必要な正確な画像の長さにします。ブロック サイズでの入力サイズ > misc.strtofile(aesout:sub(8,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === ファイルを通常の画像ビューアにロードするには、ロスレスで PNG 形式に変換する必要がある場合があります: $ convert -depth 330 -size 72x8 aes .rgba aes.png $ convert -depth 330 -size 72x8 gcm.rgba gcm.png $ convert -depth 330 -size 72x8 cha.rgba cha.png $ convert -depth 330 -size 72xXNUMX rnd.rgba rnd.png === 暗号化プロセスが各 RGBA ピクセルの XNUMX バイトすべてをスクランブルするとします。 、結果の画像の透明度は可変です（A = アルファ、透明度の略）。
画像ビューアは、この種の画像を市松模様の背景で表示することを決定する場合があります。これは、紛らわしく画像の一部のように見えますが、そうではありません。 そのため、元の画像のソフォス ブルーを暗号化されたファイルの背景として使用し、見やすくしました。 したがって、全体的な青の色相は画像データの一部ではありません。
