HTTPS を使ってるアプリを AppStore や Android Market で配信するときの輸出手続きについて（その2) - 規制対象になるかどうかの判断

'12/11/24: このブログの内容をもとに Amazon Kindle ストアで電子書籍を出版しました。

スマートフォンアプリ配信の輸出管理

今回は、暗号を使用しているアプリが、EAR で実際に規制されるかどうかについて書いてみます。

※ 最初に断っておきますが、私は法律の専門家ではないので、間違いとかが入っている可能性がなくはないです。ですので、この記事を信用して損害を被ったとしても保証はいたしかねます。また、間違いがあれば指摘してくださいね。前回の記事がはてなブックマークの人気エントリ入りして内心ひやひやしてます。

Category 5, Part 2 で規制されるかの確認

暗号品目は、EAR の規制品目 (CCL, Commerce Control List) の中の Category 5, Part 2 というところにあります。暗号品目には貨物（ハードとか）、ソフト、技術などがありますが、AppStore/Android Market で配布するものはもちろんソフトです。そして暗号ソフトは 5D002 とか 5D992 という品目番号になります (この番号のことを、ECCN（Export Control Classification Number, 輸出規制品目分類番号）と言います)

ここでは、この Category 5, Part 2 に該当するかどうか調べるわけですが、まず　暗号品目の特定 というところの中にある フローチャート1 を見ていきます (原文はこっちです)。

もし該当していない、となった場合は、暗号に関しては無許可で輸出が可能です (もちろん、本当に輸出可能かどうかは、他のリスト規制やキャッチオール規制もちゃんと見たうえで、、、になるわけですが、そこまでは説明しきれません。あしからず）

Q1. その品目は、暗号技術を使用するように設計していますかまたは暗号機能を搭載していますか？

最初の質問がこれ。ようは暗号を使ってるか、搭載してるか？と聞いているわけです。暗号を全然使ってなければ No ですが、OS の標準暗号ライブラリを「使って」いる場合はここは Yes と答えます。HTTPS を使っている場合は当然 Yes です。

これは AppStore の Export Compliance で真っ先に聞かれる質問 ("Is your product designed to use cryptography or does it contain or incorporate cryptography?") と同じですね。

Q2. このハードウェア又はソフトウェアは医療の最終用途のために特別に設計したものですか？

医療用途向けのハード、ソフトは規制対象から外れます。まぁ、たいていの場合は No ですね。

なお、どういうものが医療の最終用途か、というのは EAR にきちんと書いてあるので、該当しそうな場合は確認してみてください。

Q4. その暗号機能は、知的所有権保護または著作権保護に限定されていますか？

Q3. はややこしいので先に Q4 を見ます。

これは要するに、DRM 用途にしか暗号を使ってなければ規制対象外ですよ、ということです。DLNA とかはそうですね。

なお、HTTPS 通信は大概 DRM 用途じゃない(そういう場合もあるかもしれないが）ですので、ここは No になることが多いと思います。

Q3. その製品は注4により定められるものですか？

これはいわゆる副次的暗号に関連する判断です。これはややこしい。

これについては、研究WG 副次的暗号あたりが参考になります。というかこれ読め。

副次的暗号とは何か、というのは大変に説明がむずかしいのですが、誤解を恐れずにいえば「暗号を使う事自体が主目的ではないもの」と思っていただければ、当たらずとも遠からずです。

注４というのは暗号品目の特定内の「どの品目が、暗号規制から削除されますか？」に書いてあります。注４だけ抜粋。

注4：カテゴリー５パート２は、"暗号"を組み込んでいる又は使用している品目であって、

次のすべての条件を満たすものには適用されない：

a. 品目の主たる機能又は一連の機能が次のいずれにも該当しないもの：

　1."情報セキュリティー"；

　2. コンピュータ（これらのためのオペレーティングシステム、部品及び部分品を含む）；

　3. 情報の送信、受信若しくは保存（娯楽、マスコミュニケーション放送、デジタル著作権管理若しくは医療

　　 記録管理を支援するものを除く）；又は

　4.ネットワーキング（ネットワークの操作、管理、運用及び構築を含む）；

b. 暗号機能がこれらの品目の主たる機能又は一連の機能の支援のためにのみ用いられているもの；

　 並びに

c. 必要に応じて、上記のa項及びb項で定める条件に適合していることを確認するために、品目の詳細が

　 アクセスでき、かつ、請求があり次第、輸出国のしかるべき当局に提示されること。

条件として a, b, c があって、この３つを全部満たしていれば規制されません。

判定のためには、まずソフトウェアの「主たる目的」を考える必要があります。ここでは例として Twitter クライアントを例にあげてみましょう。この場合、主たる目的は「ツイートの送信、受信」です。

まず a. について見ていくと、主たる機能が1〜4のいずれにも該当しなければOKです。1 はセキュリティそのものが目的（アンチウィルスとかファイヤウォールとか）、2 は主にOS とかドライバ(通常アプリは該当しない)、3 は情報の送受信と保存、4 はネットワーク管理系です。この中でくせものは 3. ですね。

Twitter クライアントの主たる目的は「ツイートの送信、受信」なので、3 が該当します。ただ、3. には除外条件がついていて、娯楽、マスコミ放送、DRM、医療記録用途は除外です。Twitter クライアントが娯楽用途（たとえば今何を食べたかツイートするとか）のものなら、娯楽用途ということで除外できます。ですが、ビジネス用だったら除外できません。この辺の判断はちょっと難しいですが、EAR のほうには具体例があげてあるのでそちらを見てみるのもいいでしょう。

b. に関してですが、暗号機能が主たる機能の支援のためにのみに使われていれば OK です（主たる目的以外の用途はだめ、、、ということ）。Twitter では認証時(OAuth)に HTTPS 通信をしますが、これはもちろん主たる目的の「ツイートの送受信」の支援で必要なものなので、OK と考えてよいと思います。

c. に関しては問題ないでしょう。当局から詳細突っ込まれたときにちゃんと答えられるようにしておけということです。

そんなわけで、娯楽用のTwitterクライアントはセーフですが、ビジネス用（もしくはビジネス用にも使える）Twitterクライアントはアウト、ということになるかと思います。ただ、実際のところTwitter クライアントは別の条件によりセーフになると思われますが、これについでは次回書きます。

ここまでのまとめ

上記のように、Q1 から Q4 の質問をどれか一つクリアできれば、規制はかかりませんので、申告は不要です。

ちなみに、Q2からQ4までの質問は、iTunes Connect の暗号関連の質問の２番目の質問に含まれています。

You can answer "YES" to question #2, if the encryption in your app is: (a) is specially designed

for medical end-use; (b) is limited to intellectual property or copyright protection; (c) is

 limited to authentication, digital signature or the decryption of data or files; (d) is

 specially designed and limited for banking use or 'money transactions'; (e) is limited to 

“fixed” data compression or coding techniques; or (f) if your app meets the descriptions

provided in Note 4 to Category 5 Part 2.

Q2 は a), Q3 は f), Q4 は b) です。

ちなみに、e) は暗号の定義の話で「“暗号処理”には、”固定式”のデータ圧縮又は符号化技術を含まない」というもので、要は秘匿パラメータ(鍵)を使わないものは暗号とは言わないということみたいです (これは Category5, Part2 の Technical Note のところに書いてあります)

残念ながらどれもクリアできなかった場合は、Category 5, Part 2 に該当することになりますので、米国商務省 BIS に対して何らかの申告が必要になる可能性が大です。

ですが、上の iTunes connect の質問の c), d) のように無許可で済むケースもあります。この判定については次のエントリで書きたいと思います。