HTTPS を使ってるアプリを AppStore や Android Market で配信するときの輸出手続きについて（その3) - 暗号分類
'12/11/24: このブログの内容をもとに Amazon Kindle ストアで電子書籍を出版しました。
- 作者: 村上卓弥
- 出版社/メーカー: 村上 卓弥
- 発売日: 2012/11/23
- メディア: Kindle版
- クリック: 1回
- この商品を含むブログ (2件) を見る
前回のエントリで、EAR の Category 5, Part 2 に該当するかどうかの判定まで書きました。今回は、該当する場合に、さらに暗号の分類をする方法について書いてみます。分類によっては無許可で輸出できるケースがあります。
どこを見るかですが、今度は登録の「私は、暗号登録なしに、私の暗号品目を自己番号分類し、それを輸出することができますか？」 の中にあるフローチャート2をみて分類していきます。(原文はこちら)
なお、以下の説明で Q. の番号は説明のために私が勝手に振ってます （前回の Q. の番号と重複しないように振ってあります)
Q5. 一般に公開されている暗号ソースコードですか？
AppStore/Android Marketで配信するアプリはソースコードではなくてバイナリですから、ここは No になります。
蛇足ですが、オープンソースなどで一般公開されている暗号ソースコードは許可例外TSU(740.13(e))というものを使ってテロ支援国以外に輸出できるようになっています。
Q6. ベータテストソフトウェアですか？
普通は当然 No ですよね？
ただし、最近は Google Play でベータ版の配布もできるようになってます。この場合は Yes になりますが、この場合は 許可例外 TMP を使うこともできます。
Q7. 鍵長が対称鍵56ビット以下、非対称鍵512ビット以下、楕円暗号鍵112ビット以下ですか？
鍵長がこれ以下の場合は、5D992-NLR (No License Required)に分類され、申告なしで輸出できます。
HTTPS(SSL)の場合、鍵長はクライアントとサーバの組み合わせで決まります。DES-56bit だと対称鍵56ビットなので条件を満たしますが、今時そんなものは使わず対称鍵128ビットを使うので、ここは No ということになるでしょう。
Q8. 5A002の注釈(除外条項)通りに限定された暗号ですか？
5A002の注釈はこちらを見てください。２ページ目の注と書かれているところです。ここに挙げられているものは5D992-NLRに分類され、申告なしで輸出できます。
ここには、スマートカード、銀行業務、携帯用無線電話機関連、コードレス電話関連、無線PAN、などなどがあります。ちょっと量が多いので、注釈を読んでください（だんだんなげやりになってきた、、、)
銀行業務のくだりは、iTunes Connect の２番目の質問の d) が該当しますね。
Q9. 認証のみですか？
ここ結構重要。暗号機能が認証のためにだけ使われていれば、5D992-NLR として申告なしで輸出できます。
前回エントリで Twitter クライアントの例をあげましたが、Twitter API で HTTPS を使うのはおもに認証部分で、ツイートするところは HTTP を使いますので、本項目により申告なしにできる可能性があります(ダイレクトメッセージの取得など一部の API は HTTPS なので、これを使ってるとダメですが、、、)
なお、これは iTunes Connect の２番目の質問の c) が該当します。
Q10. マスマーケット製品ですか？
輸出したいものがマスマーケット品かどうかで判断がわかれます。
マスマーケット品の定義はこちらの注３に書いてあるので確認してください。AppStore/Android Marketで配信するアプリは、(a)電子取引により一般に入手可能で、(b)暗号機能が使用者によって変更不可能で、(c)インストール時に供給者による支援が不要で、(d)必要に応じて当局に詳細を提供できる、のでほぼマスマーケット品に該当するといえるでしょう。
10/11追記: 非標準暗号を使っている場合は、マスマーケット品にはなりませんので注意。これは§742.15(b)のところにかいてあります。
マスマーケット品の場合は、そうでないものよりだいぶ規制が緩くなります。以下の説明はマスマーケット品だとして説明しています。
Q11. マスマーケット品の場合、鍵長が対象鍵64ビット以下、非対称鍵768ビット以下、楕円暗号鍵128ビット以下ですか？
マスマーケット品の場合、Q7より鍵長の基準がちょっとだけ緩くなります。この条件を満たしていれば 5D992-NLR として申告なしで輸出できます。
んが、HTTPS は先に述べたとおり、No になるかと思います。
対称鍵64ビット超のマスマーケット暗号
Q11 が No だった場合、対称鍵64ビット超のマスマーケット暗号として、EAR §742.15 を使用することになります。
これについては§742.15の (b) にある「鍵長が64ビットを超えるマスマーケット暗号」云々を確認します。また、こちらにも簡単な表があります(原文はこちら)
(b)項には 1), 3), 4)の３つがあり、4) に該当した場合は 5D992-NLR として申告なしで輸出できます。
、、、が、下に書いた通り 4) は事実上使えませんので、1) か 3) を使わなければなりません。
742.15 (b)(4) マスマーケット番号分類請求、暗号登録及び自己番号分類報告の要求事項の除外
(b)(4)にはさらに i) と ii) があります。i) は短距離無線暗号(WLANとか)なので、アプリはあまり関係ありません。
ii) は、米国原産ソースコードやツールキットを使って開発されたもの、あるいは組み込んだものです。ただし、その暗号機能がすでに商務省BISにより番号分類されて、登録・承認されていることが条件です。
iOSに組み込まれている暗号機能は BIS により承認されているので、この条件が合致するはずです。
Apple 製品に搭載されている暗号機能については、Apple の Export Compliance に書いてあります。iOS SDK は 5D992.c で NLR (許可不要)。CCATS 番号は G136387 となっています。
なお、Android の場合は、含まれる暗号が承認されているかどうかも不明。Google のサイトかどこかに書いてあるんでしょうか？
10/12修正: 残念ながら、(b)(4)(ii) の条項は「米国からの」輸出には適用できないことが判明しました。したがって、AppStore や Android Market で配信するアプリではこれを使うことはできません。標準暗号のみを使っている場合は (b)(1) を、非標準暗号を使っている場合は (b)(3) を使うしかありません。
742.15 (b)(1) 即時のマスマーケット承認
これは暗号登録を BIS に提出し、ERN (Encryption Registration Number)を発行してもらえれば、5D992-NLRとして輸出ができます。ただし、以下の (b)(3)の品目を除きます。
ただし、この場合は自己番号分類報告というのを年に１度提出しなければなりません。まあ、CSVファイルを作ってメールで送るだけなんで、大した手間ではないですが。
742.15 (b)(3) 特定のマスマーケット貨物、ソフトウェア及び部分品に対して義務付けられる番号分類請求
(b)(3)に該当する条件はいくつかありますが、特に重要なのは「非標準暗号」を使っている場合。
(b)(3)の場合、ERNの発行の他に、番号分類請求をする必要があります。番号分類請求をして30日経過したら、5D992-NLRとして輸出が可能です。
まとめ
上記のとおり分類した結果、5D992-NLRで申告不要、となった場合は申告は不要です。iTunes connect の暗号の２番目の質問は Yes になると思います。
これが No になる場合は、米国商務省 BIS に暗号登録を申請し、ERN を取得しなければなりません(742.15(b)(3)の場合はさらに番号分類申請をしてCCATSを取得)。iTunes Connect では ERN や CCATS をアップロードする必要があります。Android Market では一切提出は求められないですが、ちゃんとやっておけよという項目はありますね（そーいうのは怖いって)。
なお、BISへの申請は全部 Web 上でできるようになっています。これは SNAP-R というシステムでできます。SNAP-RについてはSNAP-Rに記述があります。申請自体は30分あればできるよー、ということになっているようです（つーか、書類書くの３０分で終わらねーよ！と思うのですが）
ちなみに私は個人で SNAP-R のアカウントだけ取りました。でも、申告が必要な状態にはなってないのでまだ ERN 取得はしたことないですけどね。本当は ERN 取得までやって、そのやり方まで書けるとよかったんですが。→ 10/11追記 : ERN 取得しました。次のエントリに詳細を書いてあります。
以上で、暗号を使っているアプリを配信するときの輸出に関する説明は終わりです。この手の解説が全然なかったので、少しでも開発者の皆さんのお役に立てれば幸いです。
'2012/6/1 : リンク修正しました。
HTTPS を使ってるアプリを AppStore や Android Market で配信するときの輸出手続きについて（その2) - 規制対象になるかどうかの判断
'12/11/24: このブログの内容をもとに Amazon Kindle ストアで電子書籍を出版しました。
- 作者: 村上卓弥
- 出版社/メーカー: 村上 卓弥
- 発売日: 2012/11/23
- メディア: Kindle版
- クリック: 1回
- この商品を含むブログ (2件) を見る
今回は、暗号を使用しているアプリが、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 副次的暗号あたりが参考になります。というかこれ読め。
副次的暗号とは何か、というのは大変に説明がむずかしいのですが、誤解を恐れずにいえば「暗号を使う事自体が主目的ではないもの」と思っていただければ、当たらずとも遠からずです。
注４というのは暗号品目の特定内の「どの品目が、暗号規制から削除されますか？」に書いてあります。注４だけ抜粋。
条件として a, b, c があって、この３つを全部満たしていれば規制されません。
注4：カテゴリー５パート２は、"暗号"を組み込んでいる又は使用している品目であって、
次のすべての条件を満たすものには適用されない：
a. 品目の主たる機能又は一連の機能が次のいずれにも該当しないもの：
1."情報セキュリティー"；
2. コンピュータ（これらのためのオペレーティングシステム、部品及び部分品を含む）；
3. 情報の送信、受信若しくは保存（娯楽、マスコミュニケーション放送、デジタル著作権管理若しくは医療
記録管理を支援するものを除く）；又は
4.ネットワーキング（ネットワークの操作、管理、運用及び構築を含む）；
b. 暗号機能がこれらの品目の主たる機能又は一連の機能の支援のためにのみ用いられているもの；
並びに
c. 必要に応じて、上記のa項及びb項で定める条件に適合していることを確認するために、品目の詳細が
アクセスでき、かつ、請求があり次第、輸出国のしかるべき当局に提示されること。
判定のためには、まずソフトウェアの「主たる目的」を考える必要があります。ここでは例として 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) のように無許可で済むケースもあります。この判定については次のエントリで書きたいと思います。
HTTPS を使ってるアプリを AppStore や Android Market で配信するときの輸出手続きについて
'12/11/24: このブログの内容をもとに Amazon Kindle ストアで電子書籍を出版しました。
- 作者: 村上卓弥
- 出版社/メーカー: 村上 卓弥
- 発売日: 2012/11/23
- メディア: Kindle版
- クリック: 1回
- この商品を含むブログ (2件) を見る
AppStore でアプリ配信をしようとして iTunes Connect にアプリをアップロードしようとすると、「暗号使ってるかい？」(Export Complianceのところ)という質問がされますよね？皆さん、あそこちゃんと答えてますか？
ほとんどのサイトは No でいいよ、と書いてあります。が、これは間違い。アプリが暗号関連でなくても、アプリ内に暗号コードが入ってなくても、iOS の暗号を使っている場合はここは Yes と答えないといけません。
具体的には、HTTPS を使ってる場合は結構ありますよね。Twitter 連携なんかで OAuth 使う場合は https を使いますし、そもそも Web View なんか使って https なサイトにアクセスする場合は暗号を使ってます。
ちゃんと解説しているサイトが皆無なので、簡単にまとめておこうと思います。
そもそもなんで輸出許可が必要になるケースがあるのか？
Apple や Google は米国企業であり、AppStore や Android Market のサイトはすべて米国内にあります。ここにアプリをアップロードすることは日本からの輸出にあたり、またこのサーバから各国にアプリを配信する場合は米国からの輸出にあたります。
普通、アプリケーションの配布の場合に問題になるのは暗号関連です（それ以外もあるけど）。
日本からの輸出に関しては外為法（外国為替及び外国貿易法）で規制されますが、アプリ内に暗号のコードが入ってない限り基本的に規制はかかりません。仮に入ってたとしても、オープンソースの暗号ライブラリなどの場合は特例があったりするので無許可で輸出ができる場合があります。どういうモジュールを組み込んでいるのでどの特例の対象になっているか、はきちんと把握する必要がありますが。（←コメントいただいたので訂正しました)
米国からの輸出は、EAR (Export Administration Regurations) で規制されます。これは 1) 米国からの輸出、2) 米国製品or米国製品を含む製品の「米国外」からの再輸出（例えば日本から中国への輸出など)、の２つを規制しています。後者に関しては、米国製品の組み込み比率が低ければ許可不要になるルール（de minimis rule)があったりするのですが、前者にはそういうものがなく100%米国外製品であっても規制対象になります。で、AppStore とか Android Market 配布の場合は 1) の扱いになる (米国を経由する)ため、100% 米国外製品であっても規制対象になるわけです。
EAR の暗号規制は、日本の外為令の規制よりもはるかに厳しいです。何が厳しいかというと、アプリが暗号を使用しているだけで規制対象になる (OS標準の暗号を使っているだけであっても!)という点です。そんなわけで、AppStore はアプリ登録前に確認してくるわけです (Android Market は何も聞いてこないけど、あれは Google が不親切なだけです）
これをきちんと理解するためには、EAR をある程度理解しておく必要があります。
EAR についての資料
EAR はもちろん英語で書かれていますが、読むのは結構しんどいです（法律関係なので余計）。日本語の翻訳をしてくださっている方がいるので、そちらのサイトをまず見るのがよいと思います。
以下に、EAR 翻訳されているサイトと、特に良く読む箇所をリンクしました。
- EAR日本語情報サイト
- EAR本文
- EARのうち暗号に関連する部分
- 暗号関連のガイダンス
、、、長くなってきたので、今回はここまで。
アプリが暗号規制対象になるかどうかのやり方については、次のエントリで書こうと思います。
'2012/6/1 : リンク修正。
Facebook に CashFlow ページを作ってみた
Facebook に CashFlow のページを作成しました。URL は以下。
http://www.facebook.com/pages/CashFlow/169299753127869
Facebook ページを作るのは初めてなのですが、細かいところでよくわからない点がたくさん、、、
更新情報などはこのページで発信していこうと思っていますので、いいねボタンを押してくれると嬉しいです。
MEDIAS N-06C の PC Link に Mac からつなぐ
docomo の MEDIAS WP N-06C を無事にゲット。
N-06C には PC Link という機能があって、パソコンからN-06C内の電話帳や写真にワイヤレス(無線LAN)でアクセスできます。
いちいち線を繋がなくてよいので便利。
PC Link Tool はここにありますが、残念ながら Windows 用のツールしかなく、Mac ではこのツールを使用できません。また、ツールなしでブラウザだけでも PC Link を使用することができるのですが、Mac からだと MEDIAS 側で表示される URL を入れてもそのままではうまく繋がりません、、、
試行錯誤して、Mac からブラウザ経由で繋げられる方法がわかったので、メモしておきます。
- 無線LANの設定を行い、接続を済ませておきます。
- 「設定」→「ワイヤレスとネットワークの設定」の下のほうにある「PC Link設定」を開きます。
- 「接続URL表示」で ホスト名 を確認します。デフォルトでは「N-06C」になってます。ホスト名を変更したければ「ホスト名変更」からどうぞ。
- 「PC Link 」をオンにします。
- Mac 側で「ターミナル」を起動します。
- ターミナル上で "smbutil lookup ホスト名" と入力します。デフォルトの場合は "smbutil lookup N-06C"
- IPアドレスが表示されるので、ブラウザをひらいて http://IPアドレス を開きます。
- ブラウザ上に「MEDIAS PC Link」が表示されます。
いじょ。
$100 使って AdMob に出稿したみたけど、、、
以前、AdMob に CashFlow (有料版)の広告を出稿したことがあったけど、今回は CashFlow Free の方を出稿してみることにしました。最近、DL数がだいぶ下がってきたので。
AdMob にはダウンロードトラッキング機能があって、これを使うとコンバージョン率、すなわち広告がクリックされたあと実際にアプリがダウンロード・実行された割合を取得することができるようになっています。これはアプリがダウンロードされて初回起動されたときにAdMobに通知を出すことによって実現されてます。
で、とりあえず $100 を使い、一日$25で４日間出稿してみました。単価は最低の $0.05 にしたのでクリック数は2,000回ほどいくはずです。対象は日本と米国の２箇所。
結果は暫定ですが以下のとおりです。
- インプレッション数(表示回数): 277,102回
- クリック数: 1,872回
- クリック率(CTR:Click Through Rate) : 0.68%
- ダウンロード数: 16回
- コンバージョン率: 0.85%
- ダウンロード単価: $5.86
インプレッション数、クリック数、クリック率あたりはまあ妥当というかこの際どうでもいいです。問題はダウンロード数・コンバージョン率の方。
ダウンロード数、たったの16回です。$100使って、たったの16回ダウンロードかよ！！コンバージョン率はわずか 0.85%。１ダウンロードしてもらうのに $5.86 払ってる計算です。しかも無料アプリで。
これは、、、なかなか厳しい数字ですね。$100 なんていうしみったれた単位ではなく、大量に広告打って一気にダウンロード数あげてランキング狙うとかしないといけないのか、、、あと、肝心のアプリ紹介ページももっと魅力的にしないといけないのでしょうね。
これに懲りず、今度は Android 版のほうも広告を打ってみようかと思ってます。残念ながら、Android 版のほうはダウンロードトラッキング機能がないので、コンバージョン率は分かりませんが。ちなみに、CashFlow Android 版はこちらにあるので、よろしくー。
Xcode4 に対応した symbolicatecrash を作った
iOS の開発環境には、クラッシュログ解析を行う symbolicatecrash ツールが付属しているのですが、困ったことに Xcode4 になってからまともに動かなくなってしまいました。
特に Archive したバイナリの中のシンボルをちゃんと読んでくれません。これができないとなると、AppStore で配布したアプリのクラッシュログを貰っても解析できないんですよね。
ということで、symbolicatecrash を修正しました。修正したものは以下の場所においてあります。
https://github.com/tmurakam/cashflow/blob/develop/util/symbolicatecrash
なお、https://github.com/chrispix/symbolicatecrash-fix の内容も取り込んであります。
しっかし、perl 読みにくいなー。
