組み込みデバイスでのAES暗号化：これは安全ですか？

Question

次の特性を持つ組み込みデバイス用の暗号化プログラムを作成する予定です。

CPUはIntel 80186互換@ 20 MHz以下
128 KBのRAMのうち、暗号化の目的で自由に使用できる約20 KB
アプリケーションのバイナリサイズは128 KBに制限されていますが、暗号化の部分を16 KB未満に保ちたい
フラッシュメモリ内の永続的ストレージ

これらは要件です：

32 KB未満の小さなテキストファイルとビットマップを暗号化する
いつでもファイル全体をRAMに復号化できます。つまり、ランダムアクセスは必要ありません。
暗号化されたファイルはハードウェアによって「ロックイン」されないため、いつでもPCに転送できるため、デバイスを盗んでデータを復号化しようとする人物から保護したい
私はソフトウェアの悪用、キーロガーなどについて心配していません（デバイスを誰にも貸さず、夜に枕の下に置いておかないと仮定し、NSAが私をクロロホルムにして標的型エクスプロイトをインストールする家）

私は暗号の専門家とはほど遠いですが、AESのウィキペディアを読んだり、暗号化モードと鍵導出アルゴリズムをブロックしたり、 "[AESをコードに入力する場合、あなたは間違っている」。これらすべてから、ハードウェアの制限とこのテーマに関する表面的な知識を考えれば、私が成功できるかどうか疑問に思いましたが、私は試してみます。

次の手順は、私がやろうとしていることを明確に示しています。

このレスポンスに記載されている基本的な手順に従う予定です。つまり、CBCモードでのAESによる暗号化、PBKDF2による鍵の導出、ランダムソルト、ランダムIVです。
AES-128ではなくAES-256を使用するので、SHA-512でPBKDF2を使用して、2倍の長さのキーを派生できるようにします。
組み込みデバイスには信頼できる乱数ソースがないため、私の計画では、ユーザーがPCでランダムキー（k1）を生成し、（おそらく手動で入力して）転送します。これは1回しか発生しないため、問題にはなりません。つまり、同じキー（k1）を使用して任意の数のファイルを暗号化します。
演劇/エッセイ「あなたがコードに文字AESをタイプしているなら、あなたはそれを間違っている」は、暗号化プロセスを制御する、すなわち任意の平文を提供し、それを暗号化させることができる攻撃者の危険を指摘し、これは、「エラーOracle」など、あらゆる種類のサイドチャネル攻撃を可能にするためです。攻撃者は暗号化されたファイルしか見ることができないため、これが問題ではないと私は思いますか？
私の理解では、同一の平文に対して同一の結果を回避するために、個々の暗号化ごとにランダムIVとソルトを生成する必要があります。しかし、IVとsaltは暗号的に強力な乱数でなければなりませんか？私ができる最善の方法は、hash（concat（time、battery voltage））;をシードしたMersenne Twister（またはできればより効率的なもの）です。しかし、これはまったく必要ですか？いずれにしても、IVとソルトの両方をプレーンテキストで保存するので、予測可能性を心配することなく、毎回異なることを確認するだけで済みます。
この実装またはここにリンクされている実装のいずれかを使用する予定です。もちろん、NISTテストベクトルで検証した後です。実装を選択するときに他に確認する必要があるものはありますか？

私はどの部分が間違っているか、安全でないか、または改善されるべきかを教えてくれるコメントに感謝します。また、Intel 80186の信頼できるAES-256実装がある場合は、それについて知りたいです。そして最後に、それが絶望的だと思うなら、遠慮なく教えてください。

Steve Sether · Answer

これのユースケースを指定しないため、制限を理解することは難しく、これが「安全」であるかどうかはわかりません。

HMACの使用については触れていませんが、特定のアプリケーションでの必要性を認識していると思います。

AES-128ではなくAES-256を使用したいが、その理由を指定しないでください。 AES-256は14ラウンド必要ですが、AES-128は10ラウンドしかないため、AES-128はかなり高速であり、非常に限られた環境（たとえば16ビットワード）で重要になる場合があります。 AES-128はすでに非常に安全であり、特に128ビットのエントロピーがほとんどないユーザー入力のパスワードを使用している場合は、より大きなキースペースによって提供される追加のセキュリティはほとんどありません。

IVは予測不能である必要はありません（IVはとにかく攻撃者に知られている必要があります）。 IVの唯一の重要な点は、IVが再利用されないことです。個人的には、新しいファイルが暗号化されるたびにハッシュされるランダムシードを使用し、結果をランダムハッシュに保存しました。次のIVは常に予測可能ですが、十分な初期エントロピーが与えられると、すべてのデバイスでグローバルにさえ、再利用されることはありません。

Ben Voigt · Answer

このスキームのセキュリティは、攻撃者が何を読み取れるかによって異なります。組み込みデバイスが復号化を実行していることを忘れないでください。そのため、それを行うために必要なすべての部分（暗号化されたデータ、キー、およびアルゴリズム）が明確にあります。

攻撃者がシステム（JTAGなど）に何らかのデバッグ接続を持っている場合-ゲームオーバー（即時かつ簡単）。攻撃者は復号化されたコンテンツをRAMから読み取るだけです。
もし彼があなたのデータファイルだけを読むことができて、あなたのAESキーがそれらの1つであるなら-ゲームオーバー。
彼がデータファイルのみを読み取ることができ、AESキーが別のメモリのコードに埋め込まれている場合-Ok（たぶん））。
データファイルとコードメモリの両方を読み取ることができ、AESキーがコードに格納されている場合-ゲームオーバー。攻撃者はキーをリバースエンジニアリングする必要すらありません。コードを実行して、解読されたコンテンツをメモリにダンプさせるだけです。 x86コードを実行できる仮想環境を見つけるのは簡単です。
データファイルとコードメモリの両方を読み取ることができるが、コードが改ざん防止用のキー保護用に明示的に設計されたオンダイの安全なメモリからAESキーを取得する場合-大丈夫です。攻撃者がマイクロコントローラに変更されたコードを実行させ、復号化されたデータをマイクロコントローラのメモリからコピーできる場合を除きます。
彼がデータファイルを読み取ることができ、AESキーが安全なメモリに格納されているが、そのメモリがオンダイでない場合-良くない。安全なストレージとプロセッサコアの間で送信されるキーを攻撃者が盗む可能性があります。ソフトウェアのみの攻撃よりも困難ですが、依然として安全ではありません。

基本的に、コードとオフチップデータの保護には、デバッグインターフェイスを焼き切るためのヒューズで設計されたチップ、同じヒューズによってすべての外部アクセスが拒否されてチップに格納されたコード、暗号化されたデータ、およびオンボードの改ざん防止キーストレージが必要です。 80186時代のチップがこれらの機能（特に後者）を備えている可能性は非常に低いですが、メモリサイズとクロック速度に基づくと、これは最新の80186クローンである可能性があります。