セキュリティ上の理由から、IoTのファームウェアイメージを暗号化する必要がありますか？
モノのインターネットデバイスを使用する場合、クライアントにプッシュされたファームウェアイメージを難読化または暗号化することをお勧めしますか？これにより、リバースエンジニアリングが困難になります。
（もちろん署名する必要があります）
オープンソースのコードは多くの人が監査できるため、バグはほとんどないと主張する人もいます。一方、攻撃者は同じ簡単にアクセスでき、これらの同じ脆弱性を探します。ここには間違いなく、以前の回答で正しく説明されていないトレードオフがあります。
他の人は、コードは本質的に安全であるべきであり、そのため難読化/暗号化/非表示を必要としないと述べています。たとえシステムがどのように機能するかを知っていても、システムが安全であるように設計されるべきであることは事実です。これは、これが常に当てはまること、および実装が完璧であることを意味するものではありません。実際には、コードは100％安全ではありません。 （Webアプリのセキュリティを見てください：Webアプリケーションに脆弱性がない場合にXSSおよびCSRF攻撃から保護するためにセキュリティヘッダーが必要なのはなぜですか？）暗号化と難読化によってコードを隠そうとすることで、追加のセキュリティ対策を講じることができます。 。モバイルの世界では、リバースエンジニアリングは深刻なリスクと見なされています： OWASPモバイルトップ10リスク 。
100％安全なシステムはないので、それを壊すために必要な労力を増やすことしかできません。
したがって、今、オープンソース/簡単に入手できるコードと暗号化されたコードと難読化されたコードのトレードオフです。ソースコードの公開レビューを許可すると、バグの数を減らすのに役立ちます。ただし、コードを自由に監査するインセンティブがほとんどない小さな会社の場合、善意で誰もそれを見ることがないため、コードを公開してもメリットはありません。ただし、攻撃者が脆弱性を発見するのははるかに簡単になります。 （すべてのセキュリティ研究者が解読しようとしている最新のiOSバージョンについて話しているわけではありません）。
この場合、公開レビューのためにコードをオープンソース化することさえ話していません。転送中のファームウェアの暗号化について話している。セキュリティの研究者は、脆弱性を発見して公開するためのコードを入手するためにデバイスを購入することはないでしょう。そのため、善良な人が脆弱性を発見する可能性と、悪者が発見する可能性が減少します。
いいえ。ファームウェアを暗号化/難読化するかどうかに関係なく存在しない潜在的なセキュリティの脆弱性を隠すために、ファームウェアのあいまいさに頼るべきではありません 。
私は根本的な提案をしています。正反対のことをしてください。ファームウェアバイナリを公開およびダウンロード可能にし、必要な人が自由にアクセスできるようにします。セキュリティの問題について連絡する方法の詳細を記載したページをサイトに追加します。セキュリティコミュニティと協力して、製品のセキュリティを向上させます。
間違いなくそれは有益でしょう。クローズドソースよりもオープンソースをプッシュする方がはるかに良いオプションです。最初はばかげていて物議をかもすように見えるかもしれませんが、プロジェクトを一般に公開することには多くの利点があります。
悪意のある人がいる一方で、インターネットをより良い場所にしたいと考えている人もいます。オープンソースにより、潜在的な機能、バグ、および問題について表示するだけでなく、「もの」のセキュリティと安定性を向上させるだけでなく、プロジェクトをより多くの目で見ることができます
また、Polynomialの答えに同意するために、コミュニティに参加し、セキュリティを支援する人々の基盤を構築することで、クライアントベースが大幅に増加します。
適切に設計されたファームウェアは、システム設計に対する攻撃者の無知に依存するのではなく、そのアクセスキーの強度に依存する必要があります。これは、 Kerckhoffsの公理 として知られる基本的なセキュリティエンジニアリングの原則に従います。
情報システムは、システムの鍵を除いて、システムに関するすべてが公開知識であっても安全でなければなりません。
アメリカの数学者、クロードシャノン 推奨 「敵はシステムを知っている」、つまり「敵はすぐにシステムに慣れるという前提の下でシステムを設計するべきである」という仮定から始まります。
19世紀後半までは、セキュリティエンジニアが情報を保護する有効な手段として obscurity and secrecy を提唱することが多かったことにお気づきでしょう。ただし、これらの知識に拮抗するアプローチは、いくつかのソフトウェアエンジニアリング設計の原則、特にモジュール性とは正反対です。
2つの暗号化方式を混同していないと確信していますか？
セキュリティ上の理由から、ファームウェアのアップデートは必ずsignにする必要があります。これにより、デバイスはそれらがあなたからのものであることを確認できます。
それらを暗号化するために少しあいまいさが追加され、それだけです。復号化デバイスはあなたの管理下にないため、遅かれ早かれ誰かがそれをハッキングし、復号化キーを抽出してインターネットで公開します。
「ファームウェアの暗号化は私のコードの脆弱性の検出を防ぎますか？」という意味で他の回答はその核心に対処しました。一部の攻撃者を思いとどまらせるかもしれませんが、あいまいなことによるセキュリティは、不利益であるという誤った感覚をもたらし、逆効果になります。
しかし、私は私の経験に基づいて余分なビットを追加したいと思います。ファームウェアパッケージが暗号化されていることもありますが、その動機は攻撃者に対する制御ではなく、企業の知的財産を保護することだけです。
もちろん、ハッカーはこの「コントロール」を回避する方法を見つけることがよくありますが、それは別の話です。
あなたは自分自身にこの質問をする必要があります。誰かがあなたのファームウェアをダウンロードして、キーを明らかにしなければならない追加のファームウェア暗号化レイヤーによって阻止される脆弱性を探し始めるのに十分な利口で興味がありますか？
これは、ジャンプするためのもう1つのフープであり、ファームウェアイメージがどのディスクフォーマットであるかを理解することと同じです。これは、ジャンプするのに特に難しいフープすらありません。 DRMに相当するすべてのFARより洗練された方法がすべて壊れていることに注意してください。
オッズとは、インターネットに接続されたコーヒーメーカー/食器洗い機をハッキングするのに十分な能力があると判断された人で、追加の暗号化レイヤーによって阻止されることはありません。