web-dev-qa-db-ja.com

組み込みLinuxデバイスのパスワードを管理するためのベストプラクティス

強力なパスワードをオフラインで生成し、それを厳重に保護し、デバイスのすべてのコピーで同じパスワードを使用する必要がありますか？ブートドライブは、PCBにeMMCフラッシュはんだ付けされており、OSをバイパスして読み取るのは困難です。または、最初の起動時にパスワードをデバイスのシリアル番号のソルトハッシュに変更するコードを記述する必要がありますか？または、他によく知られている方法はありますか？

デバイスにはネットワーク機能がありますが、インターネット接続はオプションであり、そのまま維持したいと考えています。インターネットに接続せず、ネットワークに接続していなくても機能するはずです。

現在、デバイスにSSHで接続する必要があるかどうかはわかりませんが、問題を修正するのに役立つと思います。組み込みソフトウェアの開発中、私は常にsshとscpを使用して、新しいビルドのデプロイ、ログの読み取りなどを行っています。このデバイスは重くて高価です。交換するとコストがかかりすぎます。ユーザーに配信された後にソフトウェアが壊れた場合に手動でソフトウェアを修正するためのエスケープラッチとして、sshアクセスまたは同様のものを希望します。

linuxpassword-managementsshembedded-system
3
Soonts

強力なパスワードをオフラインで生成し、厳重に保護し、デバイスのすべてのコピーで同じパスワードを使用する必要がありますか？

絶対違う。攻撃のリスク（可能性x影響）を高くする2つの主要な問題があります。

  1. 1つ目は、可能性を過小評価している可能性が高いことです。自分の会社で何かを秘密に保つことは非常に困難です。現場でそうすることはほとんど不可能です。たとえば、物理的手段を使用してeMMCの内容をダンプするのは簡単です。 1 を参照してください。
  2. 2つ目は影響に関するものです。デバイスごとに異なるシークレットを使用した場合、攻撃者は（たとえば）eachデバイスに対してeMMCダンプを実行する必要があり、これは非常にスケーリングが困難です。ただし、1つのシークレットのみが使用されている場合、すべてのデバイスが余計な手間をかけずに侵害される可能性があります（つまり、攻撃者の作業量は線形のw.r.tターゲットではなく一定です）。

初回起動時にパスワードをデバイスのシリアル番号のソルトハッシュに変更するコードを記述すべきか

これにより、状況は少し改善されますが、それほど改善されません。

ソルトがすべてのデバイスで共有されている場合、前述の問題と非常によく似た問題が発生します。攻撃者は単にメモリダンプを実行する必要があるone時間で、すべてのデバイスが脆弱になります（シリアル番号は明らかに暗号学的に強力ではないため）、ベストプラクティスは、攻撃者が（共有）パスワードと（共有）ソルトを使用してシリアル番号を推測し、ほとんど労力をかけずにターゲットデバイスごとに正しいパスワードを計算できると想定することです。

一意デバイスあたりのソルトを使用すると、実際のパスワードをどこにも保存しない（ソルトされたハッシュのみを保存する）と仮定すると、確実に改善されます。これは、提案されているように「[最初の起動時に]パスワードを変更する」べきではないことを意味します。これにより、攻撃者が最初の起動前にメモリをダンプし、パスワードを取得する機会が得られます。その時点で、すべてのデバイスが再び脆弱になります。

他によく知られている方法はありますか？

上記の問題のほとんどは、公開鍵暗号化に依存することで軽減できます。各デバイスのバックオフィスで秘密/公開キーのペアを生成し、デバイスファイルシステムに公開キーを配置し、バックオフィスの「キー管理システム」に秘密キーを配置します。

ログインするには、基本的に一部のデータに（秘密鍵を使用して）「署名」し、これをデバイスに送信します。デバイスは、格納された（一意の）公開鍵を使用してそれを検証します。 SSHはすでにこれをサポートしています。 2 を参照してください。

分析

次に、攻撃の可能性と影響を見てみましょう。

目標：悪意のある攻撃者がSSH経由でデバイスにログインできないようにします。

可能性：攻撃者は、適切なプライベート証明書を提示せずにログインすることはできません（これは、十分に長いキーを推測することになります：非現実的）ORデバイスのメモリを改ざんしてログイン手順のソフトウェア実装のバグが原因で、公開証明書を置き換えますOR.

オプション1は非現実的です。オプション2は可能ですが、多少時間がかかり、スケーラブルではありません。オプション3がおそらく最も可能性が高いですが、SSHの無効化が許可されない限り回避するのは困難です。

影響：ここでの分析は簡単です。各デバイスに一意のキーペアが割り当てられているため、攻撃者がターゲットデバイスのキーペアをクラックまたは変更するために何らかの作業を行うと、他のターゲットでその作業を再利用できなくなります。この「低」の影響を呼びましょう

この場合、リスクは可能性x影響=低/中x低=〜低リスク

もちろん、組織とアプリケーションに対するリスクモデル/許容範囲を調整する必要があります。たとえば、これらのデバイスが飛行機や車の安全上重要な機能を制御するために使用されている場合、1回限りの物理的な攻撃でさえ容認できない可能性があります。

追加のリソース

キー管理に関するNISTの多くのガイドラインも確認すると役立つ場合があります。 https://csrc.nist.gov/Projects/Key-Management/Key-Management-Guidelines

具体的には、パートの第10章。

参考文献

1： https://www.blackhat.com/docs/us-17/wednesday/us-17-Etemadieh-Hacking-Hardware-With-A- $ 10-SD-Card-Reader-wp .pdf

2： https://www.ssh.com/ssh/key/

3： https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf

2
Josiah