アカウント名:
パスワード:
なんか、ずれてますよ。視野が狭いというか、一般化し過ぎというか。要約すると、最終製品（ＩｏＴ）の品質上、プログラムの書き換えが不可能であることが要求されているが、それが破られたことが問題。一般的（このＣＰＵモジュールに限らず）には、電子錠とかを想定すれば、深刻さにめまいするでしょう。
・サプライチェーンでの攻撃は既に現実の脅威であること。・代理販売、転売、中古品流通を介した攻撃が可能であること。
シナリオとしては（あくまでも例です） 攻撃者は不正改造品を流通に紛れ込ませることを攻撃の目標レベルとする。それによって、対象製品の品質を現
・サプライチェーンでの攻撃は既に現実の脅威であること。 ・代理販売、転売、中古品流通を介した攻撃が可能であること。
その通りだと思います。 ただ、攻撃を行うのは実装されたCPUに対してのみと思わないほうがいいかも。以下僕の考えをだらだら書く 例えば、CPUやモジュール自体を取り外して攻撃ROMが乗っているものに乗せ換えれば、セキュアブートやらTPMやらをすべて回避することができる。 必要なのは、取り外すためのはんだ、こて、吸い取り線、ピンセント、カッター、治具(ワイヤーなど)があればいい。1000米ドルのハードウェアは不要だ。 コーティングとかされていなければそんなに難しくないよ。 きれいに仕上げたいならフラックス除去剤やワニスがあるといいかも。ESP32は大きいから熱を伝えるのに苦労しそうだけれどもね。 だから僕はハードウェアにアクセスされたらコードの内容が書き換えられることを現状完全に回避できないと考えている。問題という書き方がよくなかったかも。 ただこの方法はいくつか問題があって、その一つが攻撃ROMの内容はオリジナルとは異なるということだ。つまり攻撃者が1から開発する必要がある。 今回の方法はどうやら、1000米ドルのハードウェアを準備できればオリジナルのROMの内容を覗き見ることができるかもしれないという。 うまくいけば1から開発する必要がなくオリジナルのコードに攻撃コード追加できるかもしれない。これが重大な問題なのかなと考えた。あとは元コメのとおり。
少し、話はそれますが、破壊的攻撃以外にも、単に経済的利益を狙うとしたら、コピーＩｏＴ製品という方が現実的かもしれませんね。（高級ブランドの偽造品、コピー商品に、ＩｏＴ製品も商材に入る時代がやってくる。）
フラッシュの暗号化が有効である前提では、復号鍵と暗号化されたフラッシュ（ファームウェア）は、攻撃者の手に渡るので、コピーＩｏＴ製品であれば現実的ですが、この場合、攻撃・改造コードの追加は技術的に不可能と評価できます。（フラッシュの暗号化方式が非対称鍵（公開鍵暗号）方式（ＣＰＵモジュール側が復号鍵、製品開発者が暗号鍵を保持する応用法を用いるとする。）
>だから僕はハードウェアにアクセスされたらコードの内容が書き換えられることを現状完全に回避できない完全な回避は、世の常として無理です。（これは、攻撃者と防御者の鍔迫り合い。上に政策、下に対策。なのですから。）現実的な対策、攻撃の回避、攻撃への防壁を、おサイフと相談して、策を練るしかないです。最近の特殊詐欺も、電話がダメなら郵便を使うの様に、スキを突かれるのですから。
そらさずに話ができないなら自分の日記でやって下さい
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
ハードウェアアクセスで書き換えできて何が問題なのかとおもったけど (スコア:1)
・プログラム全体を書き換える必要がなく、攻撃コードを一部に埋め込むことができるから本来の動作を損なわず攻撃できるかもしれないこと。
・バックドアなどに使えるBluetoothやwifiが内蔵されているから攻撃コードをデバイス（ハードウェア）別に用意する必要がないこと。
・ESP32が広く使われていて攻撃できるデバイスの範囲が広いこと。
でいいのかな？
Re: (スコア:0)
なんか、ずれてますよ。視野が狭いというか、一般化し過ぎというか。
要約すると、最終製品（ＩｏＴ）の品質上、プログラムの書き換えが不可能であることが要求されているが、それが破られたことが問題。一般的（このＣＰＵモジュールに限らず）には、電子錠とかを想定すれば、深刻さにめまいするでしょう。
・サプライチェーンでの攻撃は既に現実の脅威であること。
・代理販売、転売、中古品流通を介した攻撃が可能であること。
シナリオとしては（あくまでも例です）
攻撃者は不正改造品を流通に紛れ込ませることを攻撃の目標レベルとする。それによって、対象製品の品質を現
Re:ハードウェアアクセスで書き換えできて何が問題なのかとおもったけど (スコア:1)
・サプライチェーンでの攻撃は既に現実の脅威であること。 ・代理販売、転売、中古品流通を介した攻撃が可能であること。
その通りだと思います。
ただ、攻撃を行うのは実装されたCPUに対してのみと思わないほうがいいかも。以下僕の考えをだらだら書く
例えば、CPUやモジュール自体を取り外して攻撃ROMが乗っているものに乗せ換えれば、セキュアブートやらTPMやらをすべて回避することができる。
必要なのは、取り外すためのはんだ、こて、吸い取り線、ピンセント、カッター、治具(ワイヤーなど)があればいい。1000米ドルのハードウェアは不要だ。
コーティングとかされていなければそんなに難しくないよ。
きれいに仕上げたいならフラックス除去剤やワニスがあるといいかも。ESP32は大きいから熱を伝えるのに苦労しそうだけれどもね。
だから僕はハードウェアにアクセスされたらコードの内容が書き換えられることを現状完全に回避できないと考えている。問題という書き方がよくなかったかも。
ただこの方法はいくつか問題があって、その一つが攻撃ROMの内容はオリジナルとは異なるということだ。つまり攻撃者が1から開発する必要がある。
今回の方法はどうやら、1000米ドルのハードウェアを準備できればオリジナルのROMの内容を覗き見ることができるかもしれないという。
うまくいけば1から開発する必要がなくオリジナルのコードに攻撃コード追加できるかもしれない。これが重大な問題なのかなと考えた。あとは元コメのとおり。
Re:ハードウェアアクセスで書き換えできて何が問題なのかとおもったけど (スコア:1)
Re: (スコア:0)
少し、話はそれますが、破壊的攻撃以外にも、単に経済的利益を狙うとしたら、コピーＩｏＴ製品という方が現実的かもしれませんね。
（高級ブランドの偽造品、コピー商品に、ＩｏＴ製品も商材に入る時代がやってくる。）
フラッシュの暗号化が有効である前提では、復号鍵と暗号化されたフラッシュ（ファームウェア）は、攻撃者の手に渡るので、コピーＩｏＴ製品であれば現実的ですが、この場合、攻撃・改造コードの追加は技術的に不可能と評価できます。
（フラッシュの暗号化方式が非対称鍵（公開鍵暗号）方式（ＣＰＵモジュール側が復号鍵、製品開発者が暗号鍵を保持する応用法を用いるとする。）
>だから僕はハードウェアにアクセスされたらコードの内容が書き換えられることを現状完全に回避できない
完全な回避は、世の常として無理です。（これは、攻撃者と防御者の鍔迫り合い。上に政策、下に対策。なのですから。）
現実的な対策、攻撃の回避、攻撃への防壁を、おサイフと相談して、策を練るしかないです。
最近の特殊詐欺も、電話がダメなら郵便を使うの様に、スキを突かれるのですから。
Re: (スコア:0)
そらさずに話ができないなら自分の日記でやって下さい