アプリケーションでクライアントの電話番号を使用して、Web サービスの一意の ID を生成する必要があります。もちろん、電話番号は一意ですが、保護する必要があります。そのため、対称暗号化を使用して実装できます (リソースのリークのため、非対称は後で実装されます) が、暗号化キーを保存する場所がわかりません。
理由はわかりませんが、キーを静的フィールドとしてコードに格納するのは良くないようです。アプリケーションを実行していなくても、ここから読み取るのは簡単すぎるためかもしれません。
Keychain にキーを格納し、リクエストによってここから取得する方がよいようです。ただし、#1 を回避するには、インストール プロセス中にキーチェーンにキーをインストールする必要があります。出来ますか？どうやってするか？
証明書が何をするのかわかりません。それらは問題の解決に役立ちますか?
サーバーからキーを転送することも、非常に簡単に傍受できるため、悪い考えです。
スニッフィングの問題を解決する方法は、WebサービスのHTTPSを介して通信することです。NSURLConnectionはこれを簡単に実行し、私が知っているすべてのWebサービスエンジンは問題なくHTTPSを処理します。これにより、問題の多くがすぐに解消されます。
100-1000xがボトルネックを解読するのはどのマシンですか？サーバーが非常にビジーで、asym復号化を実行できませんか？あなたはそれが無関係であるべきであるように電話でこれをあまり頻繁に行うべきではありません。ここでasymが答えだと言っているのではありません。パフォーマンスのオーバーヘッドが、一度復号化された単一の文字列を保護するための問題ではないということだけです。
あなたのサービスは、すべてのユーザーが自分の電話番号を提供しなければならないようにSMSを必要としますか？電話番号の取得を自動化しようとしていますか、それともユーザーが自分で電話番号を入力できるようにしていますか？プライベートAPI（またはプライベートではないが文書化されていない構成データ）を介して電話番号を自動的に取得し、それをサーバーに送信すると、利用規約に違反する可能性があります。これは、Appleがユーザーを保護したい特定のユースケースです。UIでこれを行っていることを明確にし、明示的なユーザー権限を取得する必要があります。
個人的に私は次のように認証します：
ObfuscationKeyは、サードパーティが偽のクライアントを作成するのを困難にするためにプログラムとサーバーにハードコーディングする秘密鍵です。クライアントだけがサーバーと通信できることを安全に保証することは不可能であり、期間も不可能です。ただし、obfuscationKeyは、特にリバースエンジニアリングがより困難なiPhoneで役立ちます。UUIDを使用すると、電話番号よりもサードパーティに知られていることがはるかに少ないため、役立ちます。
そこにある「userPassword」に注意してください。ユーザーは、ユーザーだけが知っているものを使用して認証する必要があります。UUIDも電話番号もそのようなものではありません。
上記のシステムとHTTPSは、実装が簡単で（私は多くの言語で何度も実行しました）、優れたパフォーマンスを備え、幅広い「適切な」ものに対して適切なレベルに安全である必要があります。
対称暗号化で安全にやりたいことができるとは思えません。asym を使用すると、あまり気にせずに公開鍵を送信し (脅威は誰かが自分の鍵を自分の鍵に置き換えていることだけです)、秘密鍵を使用してサーバー上の暗号化された一意の ID を検証できます。