暗号化や署名は特定のフラッシュ空間の範囲に適用できますか?
暗号化されたフラッシュ領域内におけるプログラム自身の読み書き動作は、以前とどのように異なりますか(読み戻されるデータは暗号文ですか?書き込まれるデータは平文ですか?)?
OTAアップグレードの際、チップの暗号化/復号に適合するアーキテクチャを競合なくするにはどうすればよいのでしょうか?
こんにちは、
まず明確にしておきたいのは、暗号化が有効になると、チップ上で実行されているプログラムがフラッシュメモリに書き込む際、書き込まれるデータは平文ですが、最終的にフラッシュメモリに保存されるのは暗号文です。そして、チップ上で実行されているプログラムがフラッシュメモリ内の暗号文を読み取ると、平文として出力されます。
正しい
上記の観点に基づくと:
そして、Secure Provisioningソフトウェアが読み取るSBファイルは暗号文であり、シリアルISP経由でチップの純正ISP ROMブートローダーに送られるものも暗号文でなければなりません(そうでなければ論理的な欠陥が生じます)。工場出荷時のISP ROMブートローダーは、シリアル通信で受信した暗号文を平文に復号化し、その平文データをフラッシュメモリに書き込みますが、最終的にフラッシュメモリに保存されたデータは再び暗号化され、暗号文になります。
つまり、ISPプログラミング中、工場出荷時のISP ROMブートローダーはまず復号化を行い、次に暗号化を行うため、復号化と暗号化の往復処理が行われる。
もう少し詳しく説明させてください。
はい、SBファイルは暗号化されているため、フラッシュメモリに書き込む前にROMで復号化する必要があります。しかし、SBファイルはOEMと製造工場間のファームウェアを保護するために、完全に独立して暗号化されています。
フラッシュメモリのプログラミング(内蔵型か外付け型かを問わず)はまた別の話で、全く使用されないか、あるいは異なるアルゴリズム、初期ベクトルなどを用いて使用されます。
よろしくお願いいたします。
リボル
まず明確にしておきたいのは、暗号化が有効になると、チップ上で実行されているプログラムがフラッシュメモリに書き込む際、書き込まれるデータは平文ですが、最終的にフラッシュメモリに保存されるのは暗号文です。そして、チップ上で実行されているプログラムがフラッシュメモリ内の暗号文を読み取ると、平文として出力されます。
上記の観点に基づくと:
そして、Secure Provisioningソフトウェアが読み取るSBファイルは暗号文であり、シリアルISP経由でチップの純正ISP ROMブートローダーに送られるものも暗号文でなければなりません(そうでなければ論理的な欠陥が生じます)。工場出荷時のISP ROMブートローダーは、シリアル通信で受信した暗号文を平文に復号化し、その平文データをフラッシュメモリに書き込みますが、最終的にフラッシュメモリに保存されたデータは再び暗号化され、暗号文になります。
つまり、ISPプログラミング中、工場出荷時のISP ROMブートローダーはまず復号化を行い、次に暗号化を行うため、復号化と暗号化の往復処理が行われる。
こんにちは、
MCXNデバイスの場合:
暗号化や署名は特定のフラッシュ空間の範囲に適用できますか?
SECツール:
- アプリケーション全体に署名
- 暗号化領域は製品のライフ期間中に一度設定され、FUTUREのアップデート(アプリの拡張)のために予約を取る必要があります。
暗号化されたフラッシュ領域内におけるプログラム自身の読み書き動作は、以前とどのように異なりますか(読み戻されるデータは暗号文ですか?書き込まれるデータは平文ですか?)?
暗号化/復号化はリアルタイムで行われます。アプリがフラッシュメモリから読み込む場合、そのことを気にする必要はありません。透過的に処理されます。アプリケーション自体から暗号化されたフラッシュ領域に書き込むことについては、調査が必要です。注意点があるかはわかりません。
OTAアップグレードの際、チップの暗号化/復号に適合するアーキテクチャを競合なくするにはどうすればよいのでしょうか?
前述のとおり、暗号化には適切なサイズのメモリ領域を指定する必要があります。もしアプリケーションが暗号化領域を超えた場合、OTAは動作しますが、暗号化圏外のアプリ部分だけが動作し、IPアドレスは暗号化で保護されません。
よろしくお願いいたします。
リボル