2016-04-12 14 views
2

IoTベースのソリューションに採用する暗号化/セキュリティ戦略を理解しようとしています。 ここに私の評価があります。IoTソリューションの暗号化/セキュリティ戦略

  1. セキュリティシステムの基本的な前提は、アルゴリズムがクラックする可能性があるため、鍵を保護する必要があるということです。

  2. TLSは、無線で送信されるパケットの保護レイヤーとして機能します。これは、主に無線デバイスによって注意を払われます。これは十分ではない&データをさらに保護する必要があります。

  3. 暗号化する必要があるデータは、さまざまな暗号化アルゴリズムを使用できます。そのAESの中で、最も信頼できるものと思われます。私は、AESがパブリック - プライベートキーアルゴリズムか対称キー(エンコード - デコード用の単一キー)であるかどうかを確認することはできません。これにもっと光を当ててください。

    1. すべてのデバイス/ノードは異なる暗号鍵を持っている:

    は、誰もがここ戦略渡って来ています。これは、ハッカーが基礎となる暗号化を理解せずに特定の定期的なデータをシミュレートできるため、非常に重要です。したがって、ハッカーがxyzパケットがデバイス内で特定の動作を生成することがわかった場合、暗号化はほとんど影響しません。

  4. 秘密鍵を変更することができます。セッションごとに作成されたように、次の接続の鍵を更新しますか?

私の前提は正しいですか?また、IoT環境でのセキュリティのベストプラクティスを教えていただければ幸いです。

よろしく、

Chaitannya

+3

セキュリティアドバイスを求めると[情報セキュリティスタックエクスチェンジ](https://security.stackexchange.com/)がスタックオーバーフローに適しているので、このトピックをオフトピックとして閉じることにしました。 –

+1

* TLSはどういう意味ですか...十分ではなく、データをさらに保護しなければなりません。あなたがデバイス間で通信するためにTLSを使用しているなら、それ以上の暗号化は必要ありません。 –

+1

私は投票する能力はありませんが、私はスコットとは話題にならないことに同意します。トピックに関する質問の例は、そのようなセキュリティをどのように拡大するかです。 –

答えて

3

あなたの評価は完全に正しくありません。

  1. 仮定は、アルゴリズムがひび割れすることができることではなく、キー以外のアルゴリズムと、全ての入力データが攻撃者に知られています。 AESの場合、標準が広く公開されていますが、キーを適用せずにデータを簡単に復号できないように設計されているため、これは有効ではありません。 AES128と他の(より高い)鍵のサイズは、現代のブルートフォース攻撃に耐えられるほど十分に安全であると考えられています。

  2. ワイヤレスデバイスは、WPA/WPA2を使用していると仮定して無線でトラフィックを暗号化しますが、無線アクセスポイントでパケットが受信されると暗号化が適用されなくなります。アクセスポイントと最終的な宛先の間では暗号化されません。

  3. AESは対称キーアルゴリズムです。考慮すべき暗号化戦略は2つあります。送信元と送信先の間での暗号化、残りの暗号化2人のうちのどちらがあなたに言及しているかは不明ですが、それぞれ個別の検討と実施が必要です。サーバ間での転送中の暗号化について言及している場合は、さまざまな暗号を使用して転送中のデータを暗号化するように設計されたHTTPS/SSLなどの暗号化されたプロトコルの使用を検討してください。AESは、ファイルシステムレベルで、またはデータベースに格納する前にデータをエンコードするライブラリを使用して、安静時の暗号化に適切な暗号として広く使用されています。

  4. HTTPSの場合、各クライアント/サーバーには独自の秘密鍵があることを強く推奨します。 AESの場合も、各サーバは自分自身の鍵を使ってデータを暗号化する必要があります。

  5. パケットをキャプチャして再生する可能性が懸念されていますが、SSLと同様のプロトコルを使用するとセッションごとに異なるキーを使用して盗聴によるパターン分析を防止します。送信するデータを自分で暗号化している場合は、単純なタイムスタンプまたはシーケンス番号をエンコードされたデータに追加すると、そのたびに暗号化された出力が大幅に異なることが保証されます。たとえば、CONTROL|START|10:20pmの場合、完全に異なる暗号化データがCONTROL|START|10:21pmになります。 AESでは、ランダムシードを使用することによって、同じデータを毎回完全に異なる出力にエンコードする初期化ベクトル(IV)としても知られているものを使用することができます。

あなたに役に立つかもしれない暗号化戦略の一部を含んで、マイクロソフトやアマゾンなどのクラウド・プロバイダーが提供するIOTのメッセージングシステムも多数あります。ベストプラクティスに関しては

、しかし私は、このリンクは、このようなセットアップが動作できるかをお見せすることが有用である、任意の特定のベンダーを推奨するわけではない:私はのIoTのためのオープンなプロトコル通信プロジェクトで働いていますAWS IoT Security

+0

私の問題のほとんどが取り上げられています。ポイント番号の時点で。 3安心して暗号化を話していました。この問題は依然として残っていますが、デバイス/ノードごとに異なる暗号鍵を使用することをお勧めしますか? – chai

+0

異なるサーバー/ノードに異なるキーを使用して、1つの侵害されたサーバーまたはノードが残りのセキュリティに影響を与えないようにすることは理にかなっています。最大の問題は、データ自体とは別の場所にキーを格納する方法を見つけることです。多くの場合、デバイス内のデータを暗号化し、必要に応じてオフデバイスのデータベースまたはストレージバケットに格納することで、この問題を回避できます。また、物理的またはネットワークベースの攻撃者からデータを保護しようとしているかどうかによっても異なります。 –

+0

IoTのセキュリティ上の考慮点については、このサイトの開発者のセクションも参照してください。https://www.owasp.org/index.php/IoT_Security_Guidance –

-1

。このプロジェクトはAES(symetric keys)とRSA(assymetric keys)暗号化プロトコルで動作し、AESは文字列要求を暗号化し、RSAはRSA公開鍵を使用してAES鍵を暗号化します。これらの暗号化プロトコルは、各要求に対して一緒に機能します。

の通信もあります。要求がネットワーク経由で「スニッフィング」され、「再送信」された場合、要求は一度だけ有効なので、機能しません。新しい要求があるたびにに新しいシーケンス番号が必要で、シーケンス番号も暗号化されています。

各アプリケーションと各デバイスには、それぞれ独自のRSAキー(公開キーと秘密キー)のペアがありますが、公開キーのみがローカルデータベースに保存されます。

これらの機能は、通信プロセスと両方(アプリケーションとデバイス)のセキュリティを向上させ、RSA秘密鍵をお互いに保持する必要はありません。秘密鍵はプロジェクトデータベースに格納されます。

followzupプロジェクトwikiをご覧ください。

+0

これはIoT暗号ドメイン専門家と協力して開発されていますか? – zaph

+0

更新 - 1. WiKiを見て、使い勝手よりも先に「スタイル」が置かれていることは明らかです。 2.秘密鍵はどのようにして安全に保たれ、HSMで保護されていますか?これは不正確です:* "公開鍵で暗号化されたものは、対応する秘密鍵でのみ解読でき、**逆も同様です**" *強調します。また、「RSAアルゴリズムで要求されるCPUリソースのため、このプロトコルは制限されたサイズの文字列を暗号化するために表示されます」*。 – zaph

+0

** **は使用しないでください。最低限、RSAの不参加でセキュリティ書面に欠陥があることは明らかです。したがって、コードは信頼できません。 – zaph