ユーザーのパスワードを iPhone アプリに保存する必要があります。
アプリをアプリ ストアに投稿するとき、輸出目的でアプリに暗号化があるかどうかを Apple に通知する必要があります。
アプリを米国のみに制限したくありませんが、パスワードをクリア テキストで保存したり、ネット経由で送信したりしたくありません。
基本的に問題は、アプリが制限されないようにパスワードを暗号化できるかということです。
ユーザーのパスワードを iPhone アプリに保存する必要があります。
アプリをアプリ ストアに投稿するとき、輸出目的でアプリに暗号化があるかどうかを Apple に通知する必要があります。
アプリを米国のみに制限したくありませんが、パスワードをクリア テキストで保存したり、ネット経由で送信したりしたくありません。
基本的に問題は、アプリが制限されないようにパスワードを暗号化できるかということです。
パスワードをキーチェーンに保存するだけです。これは Apple が提供するシステム API であり、暗号化について何も知る必要はありません。Apple はそれを出荷し、システム フレームワークの輸出コンプライアンスを確保する責任があります。おそらく、彼らが禁止されている場所でデバイスを販売している場合、より弱い暗号化を使用する (または使用しない) と思われますが、利用可能な API を使用すると、輸出制限された暗号化コードをバイナリで出荷することはなく、解釈される可能性のある唯一の方法です。そうすることは、Apple がすべての iPhone に同梱することを意味するからです。
とは言っても、私は弁護士ではありませんので、心配な場合は弁護士に相談することをお勧めします。他のプログラマーのアドバイスはどれも、基本的に法的な問題に特に関連するものではありません。
まず、ユーザー名とパスワードが電話で暗号化および復号化されている場合、復号化キーも明らかに電話上にあり、ほとんど価値がありません。電話で暗号化されたユーザー名とパスワードを保存することについて心配する必要はありません。
セキュリティで保護された通信のために、既に電話にあるライブラリにおそらくある SSL を使用する必要があります。電話OSの一部であるライブラリを使用している場合、それはアプリに「暗号化が含まれている」という意味ではないと思います.
もちろん、私は弁護士ではありません。誰が知っていますか - 法律は「ピッグラテン」を有効な暗号化技術と見なすかもしれません.
提供された crypt() 関数をパスワードに使用できるようです。
このライブラリ (FreeSec 1.0) は、USonly libcrypt 暗号化ライブラリの邪魔にならない代替品として、アメリカ合衆国外で開発されました。crypt() インターフェースに対してリンクされたプログラムは、crypt() を認証認証の目的のみに使用し、上記の他のプログラマーインターフェースの使用を避ける場合にのみ、米国から輸出することができます。crypt() インターフェイスのみを使用するプログラムが他のコンポーネントを取り込まないように、ライブラリには特別な注意が払われています。
(crypt(3) の iphone ドキュメントから)