IoTデバイスでのレガシーSSL / TLS実装のセキュリティ評価
レガシーIoTデバイスの通信セキュリティのセキュリティ評価を行っています。目的は、現在の設計/実装におけるセキュリティギャップを評価して見つけることです。
評価のモードは手動で、主に既存の設計とコードを参照します。これは、デバイスのクライアント側のみです。サーバーはクラウドベースのサーバーです。デバイスはGSMモジュール（SIMCom SIM900）を使用しており、GSMATコマンドを使用してインターネット経由でサーバーとHTTPS通信を行います。
SSL / TLSに関する私の理解に基づいて、この評価のために以下のパラメーターまたは基準を検討しています。
a。TLSプロトコルバージョン
b。使用される暗号スイート
c。証明書とキーの管理
d。デバイスにインストールされているルートCA
e。デバイスID管理のための組み込みPKIアスペクト
f。ハードウェア暗号化の側面（SHE / TPM）
私はそれを正しい方法でやっていますか？上記のパラメータのリストはデバイスHW / SWプラットフォームに固有のものではないと思いますが。かなり一般的です。しかし、私はそれがどうあるべきかだと思います！つまり、パラメータリストはほとんど同じです。ただし、これらの実際の評価は、セキュリティ要件や、デバイスのフットプリントやそのプラットフォームなどの他の側面によって異なります。
私が検討している評価パラメータリストは適切で適切ですか？
回答
これは良いスタートですが、徹底的な評価はこれよりもはるかに深く行う必要があります。例えば：
クライアントはどのようにして乱数を生成しますか？CSPRNGを使用していますか？または、Netscape Navigatorの初期バージョンで使用されていたような弱い乱数ジェネレーターを使用しますか？パッシブな攻撃者はセッションキー用に生成された乱数を推測し、ネットワークを通過する暗号文を復号化できました。
クライアントは、パディングエラーが発生したときに情報をリークしますか？その場合、Steam Gaming Clientの場合と同様に、パディングオラクル攻撃の影響を受けやすい可能性があります。
クライアントはECDSAをどのように実装しますか？クライアントは、作成する署名ごとに新しいランダムkを生成しますか？そうでない場合、Sony Playstation 3の場合のように、受動的な攻撃者がいくつかの署名を観察した後に秘密署名キーを計算する可能性があります。
これらはほんの一例です。しかし、ご覧のとおり、暗号化の実装における微妙な間違いは悲惨な結果をもたらす可能性があります。これが、暗号化を正しく行うのが非常に難しい理由です。