アプリケーションでプライベートAPIキーを保存および保護するためのベストプラクティス[終了]

ほとんどのアプリ開発者は、いくつかのサードパーティライブラリをアプリに統合します。DropboxやYouTubeなどのサービスにアクセスする場合や、ロギングをクラッシュさせる場合。サードパーティのライブラリとサービスの数は驚異的です。これらのライブラリとサービスのほとんどは、なんらかの方法でサービスを認証することによって統合され、ほとんどの場合、これはAPIキーを介して行われます。セキュリティ上の理由から、サービスは通常、公開鍵と秘密鍵を生成します。これらの鍵は秘密鍵とも呼ばれます。残念ながら、サービスに接続するには、この秘密鍵を使用して認証する必要があるため、おそらくアプリケーションの一部である必要があります。言うまでもなく、これは巨大なセキュリティ問題に直面しています。公開および秘密のAPIキーはAPKから数分で抽出でき、簡単に自動化できます。

私がこれに似たものを持っていると仮定すると、秘密鍵をどのように保護できますか？

public class DropboxService  {

    private final static String APP_KEY = "jk433g34hg3";
    private final static String APP_SECRET = "987dwdqwdqw90";
    private final static AccessType ACCESS_TYPE = AccessType.DROPBOX;

    // SOME MORE CODE HERE

}

あなたの意見では、秘密鍵を保存するための最良かつ最も安全な方法は何ですか？難読化、暗号化、どう思いますか？

1. コンパイルされたアプリケーションには、キー文字列だけでなく、定数名APP_KEYおよびAPP_SECRETも含まれています。そのような自己文書化コードからキーを抽出することは、たとえば、標準のAndroidツールdxを使用すると簡単です。

2. ProGuardを適用できます。キー文字列は変更されませんが、定数名は削除されます。また、可能であれば、クラスとメソッドの名前を短く、意味のない名前に変更します。キーの抽出には、どの文字列がどの目的を果たしているかを把握するために、さらに時間がかかります。

   ProGuardの設定は、恐れるほど難しくないはずです。まず、project.propertiesに記載されているように、ProGuardを有効にするだけです。サードパーティのライブラリに問題がある場合は、proguard-project.txtで、警告を抑制したり、難読化されないようにする必要がある場合があります。例えば：

   -dontwarn com.dropbox.**
   -keep class com.dropbox.** { *; }

   これはブルートフォースアプローチです。処理されたアプリケーションが機能したら、このような構成を調整できます。

3. たとえばBase64エンコーディングを使用して、またはできればより複雑なものを使用して、コード内の文字列を手動で難読化できます。多分ネイティブコードです。ハッカーは、エンコードを静的にリバースエンジニアリングするか、適切な場所でデコードを動的にインターセプトする必要があります。

4. ProGuardの特殊な兄弟であるDexGuardのような商用の難読化ツールを適用できます。さらに、文字列とクラスを暗号化/難読化できます。キーを抽出するには、さらに時間と専門知識が必要です。

5. 独自のサーバーでアプリケーションの一部を実行できる場合があります。鍵を保管しておけば安全です。

結局のところ、それはあなたがしなければならない経済的トレードオフです：キーがどれほど重要であるか、どれだけの時間またはソフトウェアが余裕があるか、キーに興味を持っているハッカーはどれだけ洗練されているか、彼らがどれだけの時間を望んでいるかキーがハッキングされるまでの遅延の価値、どのくらいの規模で成功したハッカーがキーを配布するかなどです。キーなどの小さな情報は、アプリケーション全体よりも保護することが困難です。本質的に、クライアント側のすべてが壊れることはありませんが、確かにレベルを上げることができます。

（私はProGuardとDexGuardの開発者です）

私の考えでは、最初の1つだけがいくつかの保証を与えるいくつかのアイデア：

1. あなたの秘密をインターネット上のいくつかのサーバーに保管し、必要なときにそれらをつかんで使用してください。ユーザーがDropboxを使用しようとしている場合、サイトにリクエストして秘密鍵を取得することを妨げるものは何もありません。

2. 秘密をjniコードに入れ、いくつかの変数コードを追加して、ライブラリを大きくし、逆コンパイルを困難にします。また、キー文字列をいくつかの部分に分割して、さまざまな場所に保管することもできます。

3. 難読化ツールを使用し、コードにハッシュされたシークレットを入れ、後で必要に応じてハッシュを解除します。

4. いずれかの画像の最後のピクセルとして秘密鍵をアセットに入れます。次に、必要に応じてコードで読み取ります。コードを難読化すると、コードを読み取るコードを非表示にするのに役立ちます。

APKコードの読み取りがいかに簡単かを簡単に確認したい場合は、APKAnalyserを取得します。

http://developer.sonymobile.com/knowledge-base/tool-guides/analyse-your-apks-with-apkanalyser/

別のアプローチは、そもそもデバイスに秘密を持たないことです！モバイルAPIのセキュリティテクニック（特にパート3）を参照してください。

インダイレクションの古くからの伝統を使用して、APIエンドポイントとアプリ認証サービスの間で秘密を共有します。

クライアントがAPI呼び出しを行う場合、アプリ認証サービスに認証を要求し（強力なリモート認証手法を使用）、シークレットによって署名された時間制限付き（通常はJWT）トークンを受け取ります。

トークンは、API呼び出しごとに送信されます。エンドポイントは、リクエストを処理する前に署名を検証できます。

実際のシークレットがデバイスに存在することはありません。実際、アプリが有効かどうかはまったくわかりません。アプリはリクエスト認証を削除し、結果のトークンを渡します。インダイレクションの優れた利点として、シークレットを変更したい場合は、ユーザーがインストール済みのアプリを更新しなくても変更できます。

したがって、秘密を保護したい場合は、そもそもアプリに秘密を持たないのがよい方法です。

安全でない古い方法：

3つの簡単な手順に従って、API /秘密鍵を保護します（以前の回答）

Gradleを使用して、APIキーまたは秘密キーを保護できます。

1. gradle.properties（プロジェクトプロパティ）：キーを使用して変数を作成します。

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle（モジュール：app）：アクティビティまたはフラグメントでアクセスするには、build.gradleで変数を設定します。以下のコードをbuildTypes {}に追加します。

buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}

3.アプリのBuildConfigでActivity / Fragmentにアクセスします。

BuildConfig.GoogleSecAPIKEY

更新：

上記のソリューションは、オープンソースプロジェクトでGitをコミットするのに役立ちます。（コメントをくれたDavid Rawsonとriyaz-aliに感謝します）。

マシューとパブロセガラのコメントによると、上記の方法は安全ではなく、デコンパイラーは誰かが私たちの秘密鍵でBuildConfigを表示することを許可します。

解決 ：

NDKを使用してAPIキーを保護できます。ネイティブC / C ++クラスにキーを格納し、Javaクラスでそれらにアクセスできます。

NDKを使用してAPIキーを保護するには、このブログに従ってください。

Androidにトークンを安全に保存する方法のフォローアップ

アプリシークレットキーは秘密にしておく必要があります。ただし、アプリをリリースするときに、一部の人がキーを逆にすることができます。

それらの人のためにそれは隠さないでしょうProGuard、コードもロックします。これはリファクタリングであり、一部の有料の難読化ツールは、jk433g34hg3 文字列を取得するためにいくつかのビット単位の演算子を挿入しています。あなたが3日間働くならば、あなたはハッキングを5-15分長くすることができます:)

最善の方法は、それをそのままにしておくことです。

サーバー側（PC）に保管しても、キーをハッキングして印刷することができます。多分これは最も時間がかかりますか？とにかく、それは数分または最良の場合は数時間の問題です。

通常のユーザーはコードを逆コンパイルしません。

考えられる解決策の1つは、アプリでデータをエンコードし、実行時に（そのデータを使用する場合）デコードを使用することです。また、アプリの逆コンパイルされたソースコードを読みにくく、理解しにくくするために、プログラムを使用することをお勧めします。たとえば、アプリにエンコードされたキーを配置し、アプリでデコードメソッドを使用して、実行時に秘密キーをデコードします。

// "the real string is: "mypassword" "; 
//encoded 2 times with an algorithm or you can encode with other algorithms too
public String getClientSecret() {
    return Utils.decode(Utils
            .decode("Ylhsd1lYTnpkMjl5WkE9PQ=="));
}

保護されたアプリの逆コンパイルされたソースコードは次のとおりです。

 public String c()
 {
    return com.myrpoject.mypackage.g.h.a(com.myrpoject.mypackage.g.h.a("Ylhsd1lYTnpkMjl5WkE9PQ=="));
  }

少なくともそれは私には十分に複雑です。これは、アプリケーションに値を格納する以外に選択肢がない場合の方法です。もちろん、それが最善の方法ではないことは誰もが知っていますが、私にとってはうまくいきます。

/**
 * @param input
 * @return decoded string
 */
public static String decode(String input) {
    // Receiving side
    String text = "";
    try {
        byte[] data = Decoder.decode(input);
        text = new String(data, "UTF-8");
        return text;
    } catch (UnsupportedEncodingException e) {
        e.printStackTrace();
    }
    return "Error";
}

逆コンパイルされたバージョン：

 public static String a(String paramString)
  {
    try
    {
      str = new String(a.a(paramString), "UTF-8");
      return str;
    }
    catch (UnsupportedEncodingException localUnsupportedEncodingException)
    {
      while (true)
      {
        localUnsupportedEncodingException.printStackTrace();
        String str = "Error";
      }
    }
  }

そして、あなたはグーグルで少しの検索で非常に多くの暗号化クラスを見つけることができます。

@Manohar Reddyソリューションに追加すると、firebase Databaseまたはfirebase RemoteConfig（デフォルト値がNull）を使用できます。

1. 鍵を暗号化する
2. それをfirebaseデータベースに保存します
3. アプリの起動時または必要なときにいつでも入手できます
4. キーを解読して使用する

このソリューションの違いは何ですか？

• firebaseの信任状なし
• firebaseアクセスは保護されているため、署名付き証明書を持つアプリのみがAPI呼び出しを行う権限を持っています
• 中間者の傍受を防ぐための暗号化/解読。ただし、Firebaseに対してすでにhttpsを呼び出します

この例には、さまざまな側面があります。他の場所で明示的にカバーされていないと思われるいくつかのポイントに言及します。

輸送中の秘密の保護

最初に注意する点は、アプリの認証メカニズムを使用してDropbox APIにアクセスするには、キーとシークレットを送信する必要があるということです。接続はHTTPSです。つまり、TLS証明書を知らないとトラフィックを傍受できません。これは、モバイルデバイスからサーバーへの移動中に人がパケットを傍受して読み取るのを防ぐためです。通常のユーザーにとっては、トラフィックのプライバシーを確​​保するための本当に良い方法です。

悪意のある人物がアプリをダウンロードしてトラフィックを検査するのを防ぐのが得意ではありません。モバイルデバイスに出入りするすべてのトラフィックにman-in-the-middleプロキシを使用するのは本当に簡単です。この場合、Dropbox APIの性質上、アプリのキーとシークレットを抽出するためのコードの逆アセンブリやリバースエンジニアリングは必要ありません。

サーバーから受信したTLS証明書が期待どおりのものであることを確認するピン留めを行うことができます。これにより、クライアントにチェックが追加され、トラフィックの傍受がより困難になります。これにより、処理中のトラフィックを検査することが難しくなりますが、ピン留めチェックはクライアントで行われるため、ピン留めテストを無効にすることも可能です。しかし、それは難しくなります。

安静時の秘密の保護

最初のステップとして、プロガードのようなものを使用すると、秘密がどこに保持されているかがわかりにくくなります。NDKを使用してキーとシークレットを保存し、リクエストを直接送信することもできます。これにより、情報を抽出する適切なスキルを持つ人の数を大幅に減らすことができます。値を直接メモリに直接保存しないことにより、さらに難読化できます。別の回答で提案されているように、使用する直前に暗号化および復号化できます。

より高度なオプション

アプリにシークレットを配置することに偏執的で、より包括的なソリューションに投資する時間とお金がある場合は、サーバーに資格情報を保存することを検討してください（いずれかがあると仮定します）。サーバーを介して通信する必要があるため、APIへの呼び出しのレイテンシが増加し、データスループットの増加によりサービスの実行コストが増加する可能性があります。

次に、サーバーを確実に保護するためにサーバーとの通信方法を決定する必要があります。これは、内部APIで同じ問題が再び発生するのを防ぐために重要です。私が与えることができる最良の経験則は、中間者の脅威のために秘密を直接送信しないことです。代わりに、シークレットを使用してトラフィックに署名し、サーバーに送信されるリクエストの整合性を確認できます。これを行う1つの標準的な方法は、シークレットをキーとしたメッセージのHMACを計算することです。私はこの分野でも動作するセキュリティ製品を持っている会社で働いているので、この種のものに興味があります。実際、これは私の同僚の1人によるブログ記事で、これの大部分について説明しています。

どれくらいすべきですか？

このようなセキュリティアドバイスを使用すると、誰かが侵入するのをどれだけ困難にしたいかについてコスト/メリットの決定を行う必要があります。何百万もの顧客を保護している銀行の場合、予算はアプリをサポートしている誰かとはまったく異なります余暇。誰かがあなたのセキュリティを破るのを防ぐことは事実上不可能ですが、実際にはすべてのベルとホイッスルを必要とする人はほとんどいません。

最も安全なソリューションは、サーバーにキーを保持し、そのキーを必要とするすべてのリクエストをサーバー経由でルーティングすることです。そうすれば、キーがサーバーを離れることはありません。サーバーが安全である限り、キーも安全です。もちろん、このソリューションにはパフォーマンスコストがあります。

秘密を守り、firebase databaseアプリの起動時にそこから取得します。Webサービスを呼び出すよりもはるかに優れています。

秘密鍵を保護するために何をしても、実際の解決策にはなりません。開発者がアプリケーションを逆コンパイルできる場合、キーを保護する方法はありません。キーを非表示にすることは、あいまいなことによるセキュリティであり、コードの難読化も同様です。秘密鍵の保護に関する問題は、それを保護するために別の鍵を使用する必要があり、その鍵も保護する必要があることです。キーでロックされているボックスに隠されたキーを考えてください。部屋の中に箱を置き、部屋をロックします。保護する別のキーが残ります。そして、そのキーはまだアプリケーション内にハードコーディングされます。

したがって、ユーザーがPINまたはフレーズを入力しない限り、キーを非表示にする方法はありません。ただし、そのためには、帯域外で発生する、つまり別のチャネルを介して発生するPINを管理するためのスキームが必要です。Google APIのようなサービスのキーを保護するのは確かに実用的ではありません。

古くからの投稿ですが、それでも十分です。.soライブラリーにそれを隠すのは素晴らしいことだと思います。もちろん、NDKとC ++を使用します。.soファイルは16進エディターで表示できますが、それを逆コンパイルしてください：P

これらをプライベートに保つ唯一の真の方法は、それらをサーバー上に保持し、アプリが何であれそれをサーバーに送信し、サーバーがDropboxと対話することです。この方法では、秘密鍵をいかなる形式でも配布しないでください。

苦い経験に基づいており、IDA-Proの専門家に相談した後の最良の解決策は、コードの主要部分をDLL / SharedObjectに移動し、それをサーバーからフェッチして実行時にロードすることです。

次のようなことは非常に簡単なので、機密データをエンコードする必要があります。

$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD