オフラインソフトウェアの認証はどのように機能しますか？
Spotifyなどのプレミアムモードのソフトウェアがオフラインでどのように動作するのか疑問に思っています。ユーザーがインターネットに接続していない場合、リモートサーバー経由で認証できません。ユーザーのデータベースとそのアカウントの有効期限。私が考えることができる唯一の説明は、ソフトウェアがアカウントの有効期限をローカルに保存し、ユーザーがオンラインのときにこのファイルを暗号化することです。ただし、これをオフラインで機能させるには、復号化キーとメソッドもサーバーから取得するのではなく、ローカルに保存する必要があります。この場合、認証はマシンコードの暗号化方法とキーの難読化によってのみ保護されているようです。
上記はオフライン認証が処理される典型的な方法ですか、またはこれを達成するためのより良い方法はありますか？
それがそのように機能した場合、はい、あなたは正しいです。しかし、それはここで必要なものではありません。
クライアントは、データがサーバーによってある程度確実に作成されたことを確認するだけで済みます。証明書の内容自体は公開されている可能性があります。ベアラはこれらのリソースにアクセスできます。タイムアウト自体は、証明書の有効期限です。
これは解決された問題です。このWebサイトを閲覧するために既に使用している最も有名な実装。 Webサーバーはブラウザーに証明書を送信して、その身元を証明し、ドメイン名に代わってデータを提供することを信頼する必要がある理由を正当化します。
サーバーは証明書を生成し、署名機関に承認を求めます。その署名機関は、公開鍵暗号を使用して署名を生成します。署名は、サーバーの証明書に追加され、サーバーのクライアントに送信されます。
署名機関自身が署名を証明するために必要な公開鍵を含む証明書を発行しました（ただし、署名の生成には使用できません）。別の署名機関にこの証明書への署名を依頼しました。
これは、ルートCA（通常は2つまたは3つのホップのみ）に到達するまで何度も行われます。ルートCAには、マシンにすでにインストールされている証明書があり、Webブラウザーによって明示的な信頼が与えられています。
証明書を偽造することは困難であり、コンピュータは、有効期限が切れる証明書を信頼することを拒否します。したがって、サーバーはファイル内の権利を合理的に説明し、信頼の連鎖によって検証された証明書でそのファイルを証明できます。
その後、クライアントはファイルと証明書を後から自由に検証できます。
パズルの最後のピースは、それらのルートCA証明書は信頼できる必要があるということです。多くの場合、これは、ルートCA証明書自体を格納するか、ルートCA証明書に署名する、信頼できるコンピューティングモジュールによって実現されます。いずれにせよ、悪意のあるユーザーがそのモジュールに証明書を強制的に追加したり、モジュールの署名を偽造したりすることは非常に困難です。
サーバーによって署名されたユーザーアカウント情報を含むファイルをデプロイします。署名の検証に使用される公開鍵は、安全に一緒に展開できます。これにより、アプリケーションは署名を検証でき、ユーザーアカウント情報がサーバーによって検証されたことを確認できます。
もちろん、ユーザーはすべての必要なファイルと一緒にアプリケーションを移動し、それを別のデバイスで機能させることができますが、心配ですか？
アカウント情報として、プラットフォームのフィンガープリント（ボリュームシリアル番号など）を含めることができます。これにより、アプリケーションは、実行中の現在のプラットフォームと一致するかどうかを確認できます。
もちろん、ユーザーはデバッガーなどを使用してソフトウェアをだますことができます。それは問題ですか？
アプリケーションがデバッガ（通常、高価な専用ソフトウェアで使用される）を接続して実行されているかどうかを検出するソリューションがあります。
仮想化ソフトウェアの検出に関するJoanna Rutkowskaの取り組み（青い錠剤）も知っています。実際に目にしたことはありません。しかし、その仕組みに興味があるかもしれません。
最後に、コードのどこかで条件付きジャンプで終了します。クラックに必要なのは、条件付き（難読化の決定）を反転することだけです。無効な資格情報があれば、アクセスが許可されます。これは問題ですか？
これを軽減するためにできることの1つは、実行可能ファイルに署名することです。Ern...はい、ユーザーは無効な署名でアプリケーションを実行できます... hmm ...
アカウント情報のハッシュから派生したカスタムキーを使用して、アプリケーションの（プレミアム）コンポーネントを暗号化して保存できます。次に、ソフトウェアはアカウント情報をハッシュし、鍵導出アルゴリズムを実行し、鍵を使用してアプリケーションコンポーネントを解読します。
これを行うことにより、アプリケーションコンポーネントを使用する唯一の方法は、適切なキーを持つことです。 申し分なく、これも完璧なセキュリティではありません。クラッカーはすでに解読されたコンポーネントを展開し、上記のルーチンをバイパスします。
有効期限？
有効期限はアカウント情報とともに保存できます。これにより、ユーザーは署名を失敗させずに変更することはできません。また、（アプリケーションがそのように変更されていないと仮定すると）アプリケーションは無効な署名を持つアカウント情報を拒否します。
ただし、ユーザーはシステム時刻を制御できます。アプリケーションは、所定のイベントをシステム時間でチェックして、それが前進していることを確認する必要があります。これはまた、アプリケーションが最後に表示されたシステム時刻を保存する必要があることを意味します。そのため、実行されていないときにクロックを変更しても、トリックは行われません。
ああ、最後に見たシステム時間はどこに保存されていますか？ユーザーはそれを変更できます。それが暗号化されているか署名されている場合、鍵はマシン上にある必要があります...そうです、うーん... ポーカーフェイス。実際、それはおそらくほとんどの人を抑止するのに十分です。
Spotifyの機能がわかりません。以下は私が思いついた解決策です。サーバーを持っている：
- ファイルを作成します。オプション：ファイルの初期コンテンツをシード値にします。
- 固定サイズの値を生成します。
- ファイルに追加します。
- ファイルのコンテンツに秘密鍵で署名します。
- ファイルに署名を追加します。
- 手順2から繰り返します。
これを数百または数千回繰り返します。数メガバイトのファイルが必要です。このファイルを暗号化カウントダウン™と呼びます。
暗号化カウントダウンとそれを生成するために使用した公開鍵をアプリケーションと一緒にデプロイします。数分（たとえば、再生時間の10分）または使用（たとえば、曲の再生）ごとに、アプリケーションは暗号化カウントダウンに移動し、最後の有効なエントリをランダムな値に置き換えます（フォレンジックツールによる回復を困難にするため）秒読み）。
時間をカウントしている場合は、ステップ2でサーバーが日時値（ランダムなパディングを含む）を使用している可能性があります。使用する場合は、完全にランダムにすることができます。
アプリケーションが起動すると、公開鍵を使用して暗号化カウントダウンを確認できます。有効なエントリの数は、トライアルに残っている量を示します。最後の有効なエントリの番号を保存してすばやくアクセスできるようにすることもできます。その後、アプリケーションはそのエントリを直接確認できます。
この暗号化カウントダウンが別のユーザーによって使用されないようにするには、アカウント情報からシードを取得できます。
ああ、これを回避するには、インストール時にバックアップを作成する必要があります。バックアップがなくなったら、バックアップから暗号化カウントダウンを復元します（時間ベースの場合は、システム時間を元に戻します）。アプリケーションこのプロセスは自動化できます。不便です。これは抑止力になります。
（十分な時間とリソースがあれば）ここで説明した対策を回避して、クラックされたバージョンを作成する可能性があることに注意してください。そして、クラックされたバージョンを作成し、それをすべての人に展開するのに必要なのは1人だけです。
海賊行為を本当に防止する唯一の方法は、あなたの管理下にサーバーを置くことです。
IOSでは、開発者は必要な情報をキーチェーンに格納するだけです。変更したり削除したりすることはできますが（難しいことです）、認証することはできず、別のデバイスでは機能しません。アプリの削除と再インストール後も存続します。
アプリがデバッガーの下で実行されているかどうかを確認することは、少しあいまいなOS呼び出しです。