こんにちは、
MCUXpresso SDKs DCP AES の例をハードウェア キーを使用するように変更しました。
- SNVS High経由でOTPMKを使用するように暗号化が設定されている
- すべてゼロのソフトウェアキーで実行される復号化
テストは依然として合格であり、これは暗号化が OTPMK/SNVS High キーではなくゼロ キーで効果的に行われていることを示しています。
観察:
- DCP API はエラーを報告しません。
- 操作は正常に完了しました。
- 「ハードウェア キー」暗号化によって生成された暗号文は、ゼロ ソフトウェア キーを使用して復号化できます。
- 新しい EVK ボードでも、ヒューズが切れた EVK でも、動作を再現できます。(BT_FUSE_SEL、BEE_KEY*_SEL=0b10、EXIP 有効化など)
これは、ハードウェア キーが無視されているか、正しく選択されていないことを示しています。
質問:
- DCP が実際に OTPMK/SNVS High を使用するために必要な前提条件 (ヒューズ、SNVS セットアップ、キー選択ビット) はありますか?
- SDK の例には既知の制限やフォールバック動作はありますか?
- 有効な DCP キー ソースを実行時に検証するにはどうすればよいでしょうか?
修正した例を添付します。これは RAM 内で実行するようにリンクされています (名前が示すようにフラッシュ内ではありません)。
TestAesEcb() のみを保持し、OTP キーを使用するために DCP_TEST_USE_OTP_KEY を定義しました。
私は自分の仮説を証明するために鍵と暗号文を変更しました。
static const uint8_t keyAes128[16] __attribute__((aligned)) = { 0 };
static const uint8_t plainAes128[] = {0x6b, 0xc1, 0xbe, 0xe2, 0x2e, 0x40, 0x9f, 0x96,
0xe9, 0x3d, 0x7e, 0x11, 0x73, 0x93, 0x17, 0x2a};
static const uint8_t cipherAes128[] = {0xcf, 0x2e, 0xa3, 0x8a, 0x12, 0x3b, 0xe2, 0x07,
0x65, 0xeb, 0x8c, 0x5c, 0x56, 0xca, 0xf2, 0x24};暗号文は、すべてゼロのキーを使用して平文から取得されます。
OTPMKで暗号化し、SWキーで復号化します
m_handle.channel = kDCP_Channel0;
m_handle.swapConfig = kDCP_NoSwap;
m_handle.keySlot = kDCP_OtpKey;
status = DCP_AES_SetKey(DCP, &m_handle, keyAes128, 16);
TEST_ASSERT(kStatus_Success == status);
DCP_AES_EncryptEcb(DCP, &m_handle, plainAes128, cipher, 16);
TEST_ASSERT(memcmp(cipher, cipherAes128, 16) == 0);
m_handle.keySlot = kDCP_KeySlot0;
status = DCP_AES_SetKey(DCP, &m_handle, keyAes128, 16);
TEST_ASSERT(kStatus_Success == status);
DCP_AES_DecryptEcb(DCP, &m_handle, cipher, output, 16);
TEST_ASSERT(memcmp(output, plainAes128, 16) == 0);
PRINTF("AES ECB Test pass\r\n");これを実行すると、シリアル ポートに次の内容が表示されます。
ご説明いただければ幸いです。
よろしくお願いいたします。
最大
こんにちは@Bio_TICFSL
ご説明ありがとうございます。
私の状況は次のとおりです。
「実際の」ボードでは USB または LPUART1 を使用できないため、NXP プロビジョニング ツール (SEC またはシリアル ダウンローダー) を使用できません。
このため、私は次の目的を持つRAM 常駐ファームウェアを開発しています。
必要なヒューズ（BT_FUSE_SEL、BEE_KEY*_SELなど）をプログラムします。
最終的なファームウェア イメージを理想的には SNVS High キー (OTPMK) を使用して暗号化します。
しかし、ヒューズの設定に関係なく、また HAB およびキー選択ヒューズがすでに切れている搭載ボード上であっても、SNVS キーが使用されることは決してないということを私は一貫して観察しています。
使用可能なインターフェースはSWD/JTAGのみなので、DCP が実際に OTPMK にアクセスできる状態にデバイスを設定するための推奨手順は何ですか?
あなたの説明は重要な懸念も提起しています:
デバイスがオープン モードのままの場合、署名または暗号化されたブートを必要としないアプリケーションであっても、独自の SNVS キーを使用してデータ (暗号化された大容量ストレージ ファイルなど) を暗号化/復号化できないことを意味しますか?
これは厳しい制限となります。
最後に、ドキュメントに記載されているステート マシンによれば、キーは赤色の「失敗」状態のいずれかを通過する場合にのみゼロ化されます。
mastupristi_0-1765466458455.pngオープンデバイスでは、遷移はCHECK → NON-SECUREのように見え、失敗状態になることはないため、SNVS マスター キーが使用できない理由は不明です。
これらの点、特に SWD/JTAG のみが利用可能な場合に OTPMK アクセスを有効にする方法に関する部分を明確にしていただけますか?
よろしくお願いします。
こんにちは、
あなたが観察している動作、つまり暗号化が OTPMK/SNVS High キーではなくゼロ キーで行われているように見える動作は、特定のセキュリティ構成では予想されます。
デバイスがオープンモード構成（SEC_CONFIG[1]ヒューズ= 0）の場合、SNVSはブート中に非セキュア状態に移行します。この状態では、OTPMK は DCP モジュールで使用できません。これは、OTP キー設定を使用すると暗号化されたデータが同一に見える理由です。実際のハードウェア キーは使用されていません。
OTPMK を DCP で使用できるようにするには、デバイスが安全で信頼できる状態である必要があります。これには次のものが必要です:
1.HABを閉じるには、SEC_CONFIG[1]ヒューズを溶断（1に設定）する必要がある。
2. SNVSは信頼された状態にある必要があります
テストケースでは、おそらくオープン モードになっています。このモードでは、DCP は実際の OTPMK ではなくゼロ キーを使用して実質的に暗号化します。これは、観察結果と一致します。
暗号化に OTPMK を適切に使用するには:
- SEC_CONFIG[1]ヒューズをプログラムしてデバイスをセキュアモードに移行する必要があります。
- SNVSが信頼できる状態を維持することを確認する
このセキュリティ アーキテクチャは意図的なものであり、適切なセキュリティ状態要件が満たされた場合にのみ、ハードウェア キーが暗号化モジュールにアクセスできるようになります。
よろしくお願いします。