4

システムが使用するサービスへのアクセスを許可する前に、モバイル デバイス クライアントを証明書で認証する必要があるシステムの証明書認証スキームを実装するための情報を収集しています。他のログイン資格情報に加えて、システムの信頼できるユーザーに一意の証明書を発行して、モバイル デバイスで使用できるようにするソリューションを探しています。

具体的には、Android アプリケーションなどのクライアント デバイス上のモバイル アプリケーションによって消費される WCF REST サービスがあり、クライアントが正しい証明書を持っているかどうか、およびユーザーによって提供された有効なユーザー資格情報を持っているかどうかを確認する必要があります。 . また、この場合のセキュリティは重要であり、非常に重要です。

私の質問は、今説明したようなシナリオで、一意の証明書認証を実装し、セキュリティを重視することは可能ですか? そうでない場合、これを達成するためのさまざまな代替手段または最良の方法は何ですか?

さらに、PIV/CAC カードに使用される個別に発行された証明書の場合、モバイル デバイスを使用した認証にこれらの証明書を活用する方法はありますか?

4

1 に答える 1

1

この性質のセキュリティは、常に取り組むのが難しい問題です。この種の主な方法の 1 つは、キー システムを最初に確立するために diffie hellman キー交換を使用することです。各ユーザーは独自の一意のキーを持ち、最初のハンドシェイクのみがプロセス集約的になります。次に、この時点で、認証のたびにキーを検証するために、任意の数の暗号化アルゴリズムを実行できます。

そのため、キーを送信する前にキーを確立する方法と、モバイル クライアント側でキーを作成するために使用できる一意の情報についての質問が生じます。これを行うにはさまざまな方法があり、すべてに独自の考慮事項があるため、これは灰色の道をたどります。たとえば、Android OS のネイティブ アーキテクチャを使用して、電話の一意の ID を取得したり、ユーザーの Google Play アカウント ID を元のキーのハッシュとして使用したりできます。ただし、diffie hellman は匿名であるため、鍵を交換する前にまずユーザーを認証する方法が必要であることに注意してください。その後は、署名されたリクエストを使用できます。

基本的に、これは、与えられたリソースを利用して十分に検討する必要があるセキュリティの領域を掘り下げ、モバイル プラットフォーム上にいることを知っているため、CPU サイクルを低く保つ必要があります。これは、集中的な暗号アルゴリズムがないことを意味します。上記の方法は、実装できるソリューションの 1 つにすぎません。

また、Android アプリケーションを開発する場合、この認証はプッシュによってアプリケーション インターフェイスを介して簡単に行うことができます。基本的に、アクセスを呼び出すか取り消すアプリケーションに証明書をプッシュすることができるので、それが最も簡単な方法です。これを Symbian OS で使用したい場合は、上で説明したような作業をさらに行う必要があります。また、基本的には完全な暗号化ではなくサインオンを要求しているため、鍵署名システムのオーバーヘッドはそれほど難しくはありませんが、クロスプラットフォームの実装が難しくなる可能性があります.

さらなる調査とアイデアの出発点となることを願っています。

于 2012-06-18T01:57:58.297 に答える