ソースコードでAPIキーを非表示にする最良の方法


12

アプリケーション、特にac#.NETアプリケーションでプライベートAPIキーを保護する方法についてのアイデアが必要です。

まず、ソースコードに何かを隠すことは理論的に不可能であることを理解しているので、別のアイデアを思いつきましたが、それがどれほど妥当かはわかりません。とにかく、なんらかの方法でWebサーバーと通信して秘密鍵を検証し、アプリケーションに戻って正当なハンドシェイクであることを確認することは可能でしょうか?

作業する2つのキーがあります。公開キー(名前が示すように、プライベートと同じように扱う必要はありません)と、他から保護されている必要があるプライベートキーです。

私がこれをどのように行うことができるかについてのアイデアは大歓迎です。


4
展開されたバイナリアプリケーションにアクセスできる人がキーを読み取れないようにする(タイトルが示すように)か、キーを変更できないようにする(サーバー経由で検証するという考えが示すように)ためにしようとしていますか?最終的な最終目標は何ですか?
グレマック14

3
APIキーの概念を不慣れ読者のために概説することは有益かもしれません。APIキーは、サービス(通常はWebサービス)と対話するソフトウェアの開発者に与えられる秘密です。これは、トラフィックのソースの特定、制限の解除と匿名アクセスの解除、およびサービスの使用に対するキーの所有者への請求に使用されます。適度に隠しておくことが期待され、侵害された場合は取り消すことが望まれます。サービスに完全に伝達する必要があるため、常に失われます。
ラースヴィクルンド14

@gregmacはい、アプリケーションの第三者ユーザーがキーを読み取れないようにしています。
スペンサー

そこに置かないでください
CodeART

回答:


12

要約する:

  • ベンダーからAPIキーが発行されているため、そのAPIを使用できます。また、このキーが他人に知られることを防ぐ義務があります。
  • アプリケーションコードで、そのベンダーのAPI(APIキーが必要)を呼び出しています
  • お客様がバイナリにアクセスできるシステムにアプリケーションを展開しているため、コードを逆コンパイル/難読化解除したり、トラフィックをインターセプトしたりする可能性があります。

このキーの侵害を防ぐ最善の方法は、キーを制御し続けることです。これは、あなた以外の誰かがバイナリを読むことができるサーバーに決してデプロイしてはならず、あなたがコントロールしていない通信リンクを決して越えないことを意味します。

最終的に、バイナリが制御できない場合、それらのすべてが制御できなくなります。同様に、誰かがトラフィックを傍受できる場合、APIキーをキャプチャできます(SSLを使用している場合でも)。

これを実現する主な方法は2つありますが、どちらもデプロイされたアプリケーションにプライベートAPIキーが含まれていません。

展開ごとに一意のAPIキーを取得する

これには、ベンダーとの追加の関係が必要になります。ベンダーでは、キーを取得するか、顧客にキーを取得させることができます。

これは、実際には、たとえばGoogle Maps APIを使用する製品では非常に一般的です。ソフトウェアの作成者は、コピーの開発/実行中に使用する独自のキーを持っていますが、ソフトウェアにそれを含めず、代わりに、ソフトウェアをインストールするユーザーとして、Googleにアクセスして独自のAPIを取得する必要がありますキー。ソフトウェアには、使用するGoogle Maps APIキーを設定するための設定オプションがあります。

実際、APIキーを発行する多くのベンダーは、この方法で契約を結んでいる必要があるため、とにかく間違った道を進んでいる可能性があり、ベンダーの利用規約に従って使用が許可されている唯一のソリューションである可能性があります/またはそれらとの法的契約。

プロキシを使用する

アプリケーションが(サーバー上で)APIを呼び出すプロキシAPIをセットアップし、次に、キーを使用してAPIがベンダーのAPIを呼び出します。

APIをさらに保護する必要がある場合があります。たとえば、アプリケーションのみがAPIを使用していることを確認するためのものです。これは次の方法で実行できます。

  • 機能を非常に具体的にするだけですが、アプリで使用できます
  • IPホワイトリスト
  • サーバー用に既に持っている既存のライセンス/承認メカニズム
  • 顧客にキーを発行できる独自のAPIキーシステム

ここで心に留めておくべきことは、これを行うことが許可されていない可能性があるということです。ベンダーには、「集約サービス」またはプロキシの構築を妨げる利用規約または法的契約がある場合があるため、確認する必要があります。


不正行為の処理

キーが侵害されなくても、顧客の1人がベンダーにキーをブロックさせるようなことをしている場合、突然すべての顧客が無効になり、唯一の修正方法は他の全員を更新することです。

同様に、もしあなたがあなたの顧客の1を(例えば、彼らは払って停止し、ソフトウェアなどを海賊版している)をブロックしたい、あなたは他の皆に更新を発行せずにそれを行う、し、キーを無効にすることはできません。

ほんの一握りのクライアントを超えたものに対するこれのロジスティクスは、すぐに受け入れられなくなります。

プロキシとして機能する場合でも、インストールごとに一意のキーを使用する場合でも、これらの状況を比較的簡単に処理できます(他の人にほとんど影響を与えずに)。


ソフトウェアに組み込まれているキーを保護しようとすることは、最終的には無駄な努力です。何をするにしても、バイナリ、ソース、および/または通信チャネルにアクセスでき、キーを取得するのに十分であると判断された攻撃者は誰でもアクセスできます。

だから、それを埋め込まないでください。「勝つ唯一の動きはプレーしないことです。」


2
「デプロイメントごとに一意のAPIキーを取得する」ための+1。プロキシと組み合わせて使用​​することもでき、いたずらなキー/クライアントを無効にする[制限付き]機能を提供します。
svidgen 14

@svidgen非常に良い点、それについて議論するセクションを追加しました。ありがとう。
グレックマック14

+1、ユニバーサルキーはほとんど常に***であなたを噛みます
ワイアットバーネット14

非常に詳細な応答。残念ながら、プライベートAPIキーは1つしか割り当てられていないため、ネットワークプロトコルを使用してNDAを使用しているため、ユーザーにキーを取得するように依頼することはできません。プロキシもおそらく問題外です。どういうわけかそれを人間が読めない形式に変換してソースのどこかに置くことに頼らなければならないかもしれません-素晴らしいオプションではありませんが、多くのオプションは残っていません。
スペンサー14

4

オブジェクトコードにキーがある場合、そのキーは定義上パブリックです。オブジェクトコードをすばやく逆コンパイルする難読化ツールのハッキングがあります。秘密キーは、オブジェクトコードの外部および別のファイルにあります。難しいのは、この秘密鍵をユーザーに提供することです。提供されたら、ファイルの最後に付加された秘密鍵の署名とアプリケーション内の公開鍵を使用して、秘密鍵の整合性を検証できます。安全な通信チャネルがある場合、Webサーバーもこの検証を実行できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.