専用の Web Api を利用するための固定の文字列をクライアントに安全に保持する方法について

Question

なぜ、クライアントに固定の文字列（以降、秘密鍵とする）を保持したいのか？

ストアアプリで利用するApiは、広くコンシューマ向けに公開したいものではなく、社内でつくる各種アプリ向けのApiです。
そこで秘密鍵を用いてこのApiの利用を特定のクライアントに限定することを考えました。

以下の流れでapiの利用を特定のクライアントに限定することを考えています。

1. 
認証リクエストとして id, password, 秘密鍵（固定文字列） を送ってもらう。
※秘密鍵は固定の文字列

2. 
id, passwordで認証を行い、秘密鍵でクライアントが期待するクライアントであることを確認する。

※通信はSSLを使用する

質問
秘密鍵は、予め暗号化してクライアントに埋め込むことを考えていますが、復号化できるアプリを専用のストアアプリに限定する方法はあるのでしょうか？
下記リファレンスを参考にしましたが、特定のクライアントに復号化を限定するという方法まで見つかりませんでした。
http://msdn.microsoft.com/ja-jp/library/windows/apps/windows.security.cryptography.dataprotection.dataprotectionprovider

そもそも今回実現したことが実現できるのかも含めて、ご回答いただけると助かります。

Answer 1

これって、ストアに公開しない前提だと予想していますが、合っていますか？（企業レベルのサイドローディング）
そうであれば、クライアント（デバイス）に情報を保持するという話をしなくても問題なさそう（アプリを入手できる人だけが実行できる）と考えていますが、違いますか？

ストアに公開するつもりで、でも実行に制限を課そうという考えであれば、何か間違えているように思います。
ストアの認定を受ける上では、認定を実施する人がそのアプリが十分に使える状態に持って行く必要があるので、その秘密鍵を Microsoft に提示することになりますが、それでいいのでしょうか？（認定要件 の 1.2）
独自のアカウントが必要なサービスを利用する場合、そのアカウントの登録方法が用意されていることが必要そうに思います。（認定要件の 6.3）

こういうことから、このスレッドにおける要求では「ストアに公開はできない」と考え、すなわち「ストアに公開しない前提である」と考えたいところでしたが、質問文からはその前提が疑わしかったために、冒頭の質問をさせていただきました。

Answer 2

コメントありがとうございます。認定要件の確認できておらず、前提に不備がありすみません。適切なコメントとても助かります。
頂いた質問に回答いたします。つくっているアプリは独自のアカウントが必要なサービスです。ストアに公開する前提で開発を進めています。

認定を実施いただく方にはデモアカウントを発行することを考えています。アカウント登録方法の用意については、認定要件（6.3）にある通り、アプリダウンロードまでを可能とし、アカウントの発行の仕組みは別途用意することを考えています。

避けたいのは、悪意を持ったアプリ入手者がアプリダウンロード後にアプリのコードを参照し、WebApiのUriを知り、こちらが用意したストアアプリ以外からApiを利用できてしまうことです。復号化を特定のストアアプリに限定した秘密鍵を利用すればこれを防げるのではないかと考えています。

ストアアプリは html5+javascript で実装しています。もろもろ前提が抜けて申し訳ありません。

Answer 3

アカウントごとにユニークなトークンを発行することを考えてはいかがでしょうか。
（もしくは、Web API 自体、アカウント認証とセットにすることを要求するか）

私は、復号を限定することは難しいか、無理だと思っています。（私が知らないだけの可能性もあります）
ストアアプリが格納される領域も、データが保存される領域もローカルにあるわけですから、そのローカルストレージの所有権を持つ他者に復号できないようにすることは難しいと思われます。（労力をかければ、いつかは解読できるという意味で）
そう考えると、鍵の漏洩は起きうるものとして、漏れても後から防げる形、漏洩を検出できる形を考えた方がよいと考え、冒頭の提案に至りました。
アカウントごとのトークンであれば、そのトークンの利用状況を参照して不正が起きていないかを確認したり、時間あたりのリクエスト数に制限をかけて漏洩しても使い物にならないようにしたり、異常なリクエスト数を持つトークンやアカウントを無効にしたりすることができます。

// アカウント発行の手段は提供（公開）されると受け取りましたが、それで間違っていませんよね？
// 社内クローズのアカウントだとすると、ストアに公開する意義がなさそうだったため、そうとらえました。

Answer 4

コメントありがとうございます。とても参考になります。

後出しの情報ばかりで申し訳ないのですが、認証後に、対象のユーザに期限付きのユニークなアクセス用のトークンを発行することを考えています。認証後はそのトークンをもって認証を行います。今回は、トークン取得のApi、つまり認証用のApiの利用を秘密鍵を使って限定したいと考えていました。

しかし、コメントいただいた通り、復号を限定することは難しいか、無理という前提に立ち、不正利用の検出、あるいは仮に不正利用された場合もその影響を最小に抑える仕組みを考える方に視点を変えてみようと思います。とても助かりました。ありがとうございました。

//アカウント発行の手段はユーザに提供しますが、事前に契約等を必要とする形を考えています。