5

まず、基本的に建設業界向けの eTendering ソリューションである当社のシステムに関する情報です。

そう：

  • リスト項目
  • 私たちのシステムには複数の会社があります
  • 各企業には複数のユーザーがいます
  • 各企業は複数のオークションを作成できます
  • その後、他の企業は利用可能なオークションに入札を送信できます。入札は数百または数千の個々のアイテムで構成されており、これらのレコードの「価格」セクションを暗号化するだけで済みます。

私たちが直面している問題は、大規模な顧客が、少なくとも入札が進行している間は、私たちが入札価格にアクセスすることを望んでいないことです。これは完全に理解できます。現在、対称暗号化を使用して価格を単純に暗号化しているため、価格はデータベースで効果的に暗号化されていますが、価格を復号化するための鍵を持っていることを懸念しています。

したがって、何らかの形式の公開鍵暗号化システムを検討しています。ソリューションに関する最初の考えは次のとおりです。

  1. 企業がサインアップすると、OpenSSL を使用して公開/秘密キーのペアを作成し、S3 または直接データベースに保存します。これを本当に便利にするには、秘密鍵に強力なパスワードを使用するようにユーザーに強制します。もちろん、秘密鍵はデータベースに保存されません。
  2. 企業がオークションに入札すると、オークションの所有者企業の公開鍵を使用して価格を暗号化し、データベースに保存します。
  3. オークションの入札期間が終了し、発行会社が最初にレポートを生成する場合、パスワードを入力し、それを会社の秘密鍵と一緒に使用して価格を復号化するよう依頼します。
  4. 後続のトラフィックを高速化するために、復号化されたデータをキャッシュします (単純な対称暗号化システムを使用して暗号化することもできます)。

質問は次のとおりです (残念ながら、私たちはセキュリティの専門家ではありません。ばかげた質問でしたら申し訳ありません)。

  • これは意味がありますか、それとも完全にばかげた、またはやり過ぎの解決策ですか?
  • OpenSSL、OpenPGP、または別のソリューションを使用してキーを生成しますか?
  • ユーザーが自分のパスワードを変更したり、新しいキーを生成したりしたい場合はどうなりますか? 新しいキーですべてを復号化/再エンコードする以外に方法はありませんか?
  • このソリューションにはどのような落とし穴がありますか?
  • 推奨できるより良い解決策はありますか?
4

3 に答える 3

5

暗号化を使用してこれを解決したい場合は、ここに私の提案があります...

  • 各ユーザーと各企業は、OpenPGP (またはGnuPG )の非対称公開鍵と秘密鍵のペアを生成する必要があります
  • これらの公開鍵のそれぞれを公開鍵サーバーにアップロードする必要があります
  • 企業は、必要に応じて、個々のユーザーの公開鍵に「署名」して、それらのユーザーとの信頼関係を指定することができます (その関係が変更された場合は、その署名を取り消します)。
  • 競売人または無党派の仲裁者も鍵ペアを生成し、その公開鍵を公開鍵サーバーにプッシュします。
  • オークション登録プロセスの一環として、各ユーザーはオークション主催者の公開鍵をインポートし、オークション主催者は各ユーザーの公開鍵をインポートします。
  • 信頼できるサード パーティ (オークション主催者以外のSaaSベンダーなど) が、ユーザーとオークション主催者が通信するためのサービスをホストします。
  • 入札ユーザーは、次の方法で入札を作成します。
    • 秘密鍵で入札に署名する
    • 提案された価格を2 つの鍵に暗号化する: 自身の公開鍵とオークション主催者の公開鍵
    • 信頼できるサード パーティ サービスに入札を送信します。これは、オークションの有効期限が切れる前に、ユーザーが入札を取得することを禁止する必要があります。
  • オークション終了時に、オークション終了後にのみ、オークション主催者はすべての入札を取得し、それらを復号化し、署名を検証します

いくつかの重要なポイント:

  • ユーザーまたは会社の秘密鍵がサービス内で共有または保存されないことが不可欠です。これが、質問で提案された方法論に見られる唯一の本当の「欠陥」です。その場合、サーバーの管理者が最終的にすべてのユーザーの秘密鍵にアクセスできるようになるため、1 人のユーザーが入札の「詐欺」または「改ざん」で管理者を非難する可能性が非常に高くなります。それらを自分で生成しました。
  • これらと同じ方針に沿って、すべての通信と「入札」が、各ユーザーによって真の秘密鍵で暗号化されて「署名」されることが不可欠です。これにより、入札が特定の 1 人のユーザーのみからのものであり、入札が改ざんされていないことがわかります。
  • 入札ユーザーとオークション主催者の公開鍵への入札を暗号化することで、サードパーティの SaaS ベンダーは、オークションが開かれているブラックアウト期間中に入札自体を内省できなくなります。説明したように、これが問題を解決するための最も重要なポイントであると思います。
  • 設計上、オークション終了後にすべての入札を公開したい場合は、すべての入札ユーザーのリングへの各入札を暗号化することが実際には好ましいかもしれないことに注意してください。これは、上記のアルゴリズムを少し変更したものです。

完全な開示と、おそらく微妙なマーケティングのために、私はたまたま Gazzang と呼ばれる会社のアーキテクト兼 CTO であり、zTrusteeと呼ばれる製品を実装しています。

于 2012-12-07T21:30:37.897 に答える
4

はっきりさせておきますが、あなたのクライアントは、システムに暗号化の一部を管理させることで得られる便利さをすべて犠牲にするつもりはないだろうという予感があります。おそらく、いくつかのオプションと、それらの弱点と利便性を提示する必要があります。

一般的なポイント

何よりもまず、考えられるすべての可能な攻撃をカバーする明示的な脅威モデルから始めます。一部の攻撃に対処しないことを選択した場合でも (すべてを処理するのは非現実的です)、より明白な攻撃を探し出し、他の攻撃が発生した場合に対処するための基本的な手順を少なくとも用意します。

Re: 意味あるの？

一般的な前提は、顧客の側ではやり過ぎですが、セキュリティの観点からは理にかなっていると思います。クライアントは、暗号的に安全なシステムを望んでいます。けっこうだ。

ただし、提案されたソリューションに関するいくつかのポイント：

  • クライアントがネットワーク経由でパスワードを渡すことを許可することで、攻撃者 (クライアントはあなたである可能性があると考えているようです) は、価格設定データにアクセスするためにそのパスワードの中間にいるだけで済みます。

    • SSL はこれを軽減するのに役立ちますが、行のどこかに誤ったログ行があると、クライアントのパスワードが誤って公開される可能性があります。

クライアントが価格データにアクセスできないようにする唯一の真に暗号化された安全な方法 (私が見ているように) は、クライアントが価格データを暗号化することであり、システムは暗号化されたデータのブローカーとして機能します。これにより、事実上、暗号化されたパケットと公開鍵のブローカーになりますが、システムは秘密鍵を決して見ることはありません。

問題は、クライアントが自分の鍵を管理する意思があるか、それとも負担が大きすぎるかということです。少なくとも、そのほとんどを自動化できる可能性があります (クライアント アプリ/ウェブサイトは、秘密鍵をローカルに保存する処理を行い、暗号化された入札を復号化するために他の関係者の公開鍵を収集する責任も負います)。

Re: OpenSSL、OpenPGP、または別のソリューションを使用してキーを生成しますか?

実際にはそれほど重要ではありません。これらの各オプションは、公開/秘密キーとメタデータのコンテナー形式を定義するだけです。言語/プラットフォームに最も適したものを使用してください。

主な決定ポイントは、どの暗号化アルゴリズムとキーの強度である必要があります: RSA-2048? RSA-4096? 楕円曲線？他の何か？

Ruby に固有: OpenSSL ライブラリは標準ライブラリの一部であるため、おそらくOpenSSLライブラリを使用したいと思うでしょう。しかし、上記の私のポイントを繰り返します。サーバーが秘密鍵をまったく見ない場合はさらに良いです (クライアントが利便性よりも優れたセキュリティのトレードオフに問題がない場合)。

Re: ユーザーがパスワードを変更したり、新しいキーを生成したりしたい場合はどうなりますか?

パスワードの変更は簡単です。秘密鍵自​​体は、対称アルゴリズムで暗号化されているだけです。パスワードを変更するには、既存のキーを復号化し、新しいキーで再暗号化する必要があります。クライアントがパスワードを紛失した場合、回復はありません。

新しいキーを生成する方がおそらく安全ですが、より慎重に行う必要があります (暗号化されたペイロードは、一致するキーを識別する必要があり、クライアントは一度に複数のキーをアクティブにすることができます)。ただし、これは良いことです。鍵が危険にさらされていなくても、鍵を定期的にローテーションするのが一般的な方法です。

于 2012-12-06T18:22:44.137 に答える
3

会社がサインアップすると、OpenSSLを使用してパブリック/プライベートキーペアを作成し、S3またはデータベースに直接保存します。これが本当に役立つように、秘密鍵に強力なパスワードを使用するようにユーザーに強制します。もちろん、これはデータベースに保存されません。

私はこのステップに少し懐疑的です。あなた（開発会社）が暗号化に使用される公開鍵と秘密鍵の両方を生成する場合、それはあなたが暗号化を破ることができるようになることを50％意味します。顧客を保護する唯一のものはパスワードです。これはブルートフォースできる可能性があります（私はあなたがそうすることを示唆していませんが、あなたにはそうする能力があります）

PKI（または説明した内容）を使用する場合は、システムでキーの作成が行われないようにする必要があります。クライアントは、システム上でペアを作成してから、価格を暗号化するために使用する公開キーを提供する必要があります。その後、クライアントは、クライアントが単独で制御できる秘密鍵を使用して復号化できるようになります。

このソリューションの落とし穴にはどのようなものがありますか？

落とし穴は、複雑なソリューションを作成していることです。特に上記の私のアドバイスに従う場合は、秘密鍵（および/またはパスワード）を「紛失」しないように顧客に信頼を置いてください。そうしないと、顧客は価格を解読できなくなります。さらに、キーが彼らの側から漏れた場合、アプリケーションが「無実」であることを証明することは困難です

OpenSSL、OpenPGP、または別のソリューションを使用してキーを生成しますか？

顧客が鍵を紛失するという落とし穴を防ぐために、PGP（商用バージョンは確実にこれを行います）とADK（追加の復号化鍵）および「分割鍵」の概念を調べることをお勧めします。顧客の公開鍵で暗号化するだけでなく、x人のうちy人が集まった場合にのみ使用できる「企業」鍵で暗号化するという考え方です（たとえば、10人が鍵の一部を所有できます）そして、それらのうちの6つが一緒になった場合、それらはキーを再構築できます）。部品はあなたの会社、クライアント、彼らの弁護士などの間で共有することができます

于 2012-12-07T09:35:23.640 に答える