アプリとIoTデバイス間の通信を保護するにはどうすればよいですか？

現在、モバイルアプリケーション（現在はIonicプラットフォームを使用）と組み込みデバイスの間のBluetooth通信を含むプロジェクトに取り組んでいます。比較のために、当社の製品はスマートロックに似ています。

セキュリティは最大の関心事であり、ハードウェアとソフトウェアがハッキングされないようにする方法を検討しています。システムの安全を確保するために、どのような手順を踏む必要がありますか

編集：はい、現在、通信を暗号化し、デバイスがサーバーと通信するときにHTTPSを使用しています。

デバイスが十分に安全であることを確認するために、いくつかのヒントがあります。

1. Bluetooth通信に暗号化を追加します。暗号化キーを空中に保つことをお勧めします。たとえば、モバイルアプリの初期設定時にデバイスにある、QESコードを箱に印刷したなど、AESキーを使用してQRコードをスキャンするようにユーザーに要求できますか？あなた次第。これは、プレーンテキストで空中に送信されたパスワードを誰かが見るのを防ぐためです。
2. 可能であれば、選択した暗号化アルゴリズムのECB（CBCを使用）モードから離れてください。送信されるデータに関する情報が得られる可能性があります。詳細については、こちらをご覧ください。
3. Bluetoothデータ送信では、メッセージが繰り返されないように、一意のIDを必ず含めてください（たとえば、タイムスタンプを含めることができます）。また、TOTPに似たシステムを実装することもできます。
4. 簡単にフラッシュできるようにポートをデバイスに配置します。これにより、ソフトウェアにバグがある（そして何らかの理由でOTAを更新できない）場合、デバイスは高価な文鎮ではなく、単なるデバイスになります。それをPCに接続し、新しいソフトウェアにフラッシュする必要があります。
5. 追加：不正なルート証明書（おそらく自己発行され、クライアントデバイスにインストールされている）を持つユーザーがサーバー通信を傍受できないようにするには、HTTPS証明書を確認します。Androidにそれを要求するSOがあります。iOSにも同様のリソースを見つけることができる必要があります。

また、デバイスを保護するために使用する暗号化と暗号化について詳しく知りたい場合は、この（無料の）電子ブックをチェックしてください。暗号化アルゴリズムの良い実装と悪い実装について多くのことを語っており、製品の保護に役立つはずです。（注1：独自のアルゴリズムを作成しないでください。注2：私はcrypto101またはlvhと提携していません。）

エンドツーエンドTCPを使用できる場合は、エンドツーエンドTLSを使用します（たとえばHTTPSを使用）。

特に暗号化に関しては、車輪を再発明しないでください-ほとんどの人は間違っています。デバイスがTLSをサポートするにはリソースの制約が厳しすぎる場合を除き、AESのレベルに達した場合、それは間違っています。＃1間違いは、暗号化して認証を忘れることです。サーバーとデバイスの間に暗号化されたチャネルではなく、サーバーと中間者の間に暗号化されたチャネルがある場合、暗号化によるメリットはありません。 。TLSを使用できない場合は、使用しているプロトコルがすべてを認証し、機密情報を暗号化することを確認してください。

TLSを安全に使用するには、各参加者の観点から、必要な保証について考えてください。通常、デバイスは正当なサーバーと通信していることを知る必要があります。つまり、サーバーの証明書を確認する必要があります。デバイスには、信頼できるものとして記録された認証局のX.509証明書が必要です。これには、攻撃者が変更できないストレージが必要ですが、ストレージの機密性は必要ありません。サーバーの証明書を直接ハードコード化しないでください。これにより、証明書が侵害された場合、その証明書を簡単に置き換えることはできません。代わりに、デバイスは予想されるIDを保存します（ホスト名）、および特定の公開鍵が予想されるホスト名に属することを保証する認証局の証明書。繰り返しになりますが、車輪を再発明することはせず、TLSライブラリまたはアプリケーションによって提供される証明書チェックに依存してください。

サーバーが正当なクライアントと通信していることを知る必要がある場合、各クライアントは独自のクライアント証明書を持っている必要があります。そのためには、クライアントに機密ストレージが必要です。クライアント証明書をTLSライブラリからTLSセッションオープニング関数に渡すか、アプリケーション構成で設定します。

これにより、サーバーとデバイス間の通信のセキュリティが保護されます。モバイルアプリケーションがデバイスと直接通信できる場合（ローカルWi-Fiネットワーク上で切断操作を許可する場合など）、まずスマートスイッチと携帯電話の間でペアリングを実行する必要があります。ペアリングとは、鍵の交換、できればリソースが許せば公開鍵の交換、そうでなければ秘密鍵の合意を意味します。このペアリングの目標は、各デバイスが通信相手を確実に把握することです。

モバイルデバイスからスマートスイッチに直接移動する場合でも、サーバー経由で移動する場合でも、制御チャネルも保護する必要があります。承認について考えてみてください。スイッチへのアクセスにはさまざまなレベルがありますか。たとえば、再構成を許可する制御レベルや、オン/オフの切り替えを許可する基本チャネルなどがありますか？これは通常、安全なチャネル（可能であればTLS）を確立した後の認証手順で処理されます。

もう1つの考慮事項は、ファームウェアの更新です。それは注意が必要なことです。一方で、絶対的なセキュリティというものは存在しないため、セキュリティパッチを時々適用することになります。一方、ファームウェアアップグレードメカニズムは複雑なものであり、それ自体にバグがある可能性があります。少なくとも、ファームウェアのアップグレードが署名されていることを確認してください。アップグレードのために通信チャネルのセキュリティのみに依存しているのは危険です。セキュアチャネルに基づく信頼は静的なセキュリティ検証よりも大きく、ネットワーク接続なしでファームウェアの更新を適用したい場合があるためです。署名を検証することに加えて、理想的には、ロールバックに対する保護が必要です。