トップページ > 記事閲覧
Android版:DXアーカイブの暗号化機能について
名前:was-blue.0793 日時: 2018/10/31 18:52

DXアーカイブにはパスワードで内部ファイルを暗号化する機能がありますが、 Android(iOS)アプリをストアに公開する上では、日本及び米国の法律で暗号化技術を含むアプリに規制があるようです。 参考:http://tmurakam.hatenablog.com/entry/20111009/1318137457 Android(iOS)のアプリをストアに公開することは日本及び米国からの輸出にあたり、鍵長によって規制対象となるかが変わります。 概ね共通鍵方式で56bit、公開鍵方式で512bit以上の鍵を使う暗号化は、アルゴリズムに関わらず規制対象となる暗号化になります。 DXアーカイブに使っている暗号化の鍵長・方式によってはDXライブラリを使うAndroidアプリ全体の問題になると思います。 Android(iOS)版に限り、DXアーカイブの暗号化・復号化機能を外した方がよいかと思いますが、いかがでしょうか。
メンテ

Page: 1 | 2 | 3 |

Re: Android版:DXアーカイブの暗号化機能について ( No.3 )
名前:was-blue.0793 日時:2018/10/31 18:54

書き込みを一部修正しました。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.4 )
名前:管理人 日時:2018/11/01 01:57

ご指摘ありがとうございます ご紹介いただいたサイトのこちらのページ <HTTPS を使ってるアプリを AppStore や Android Market で配信するときの輸出手続きについて(その2) - 規制対象になるかどうかの判断> http://tmurakam.hatenablog.com/entry/20111010/1318173222 に、規制の対象にならない条件の一つとして 『Q4. その暗号機能は、知的所有権保護または著作権保護に限定されていますか?』 がありますが、DXライブラリのDXアーカイブの暗号化されたファイルを読み込む機能はこちらに該当しないでしょうか? ( DxaEncode.exe は暗号化の処理を行いますが、DXライブラリには暗号化されたデータを複合化する機能しかありません ) > 共通鍵方式で56bit、公開鍵方式で512bit以上の鍵を使う暗号化 こちらは規制対象となるようなケースの場合に、更に規制を緩くするための制限なので、もし上記 Q4 によって 規制対象から外れる場合はこの bit数制限は関係がなくなるはずです と、思ったのですが如何でしょうか? 世の中にはクラッキング対策用にプログラム中の文字列やファイルを暗号化する DexProtector などのソフトも 複数あるようなので、解析されるのを防止するためにデータファイルを暗号化するのは問題ないように思います
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.5 )
名前:was-blue.0793 日時:2018/11/01 17:05

ご返答ありがとうございます。 DexProtectorなどのクラッキング対策用ライブラリは明らかに「知的所有権・著作権保護」のみを目的として導入されるもので、規制からは除外されると思います。 (管理人さんのご指摘通り、鍵長のビット制限も、暗号が「知的所有権・著作権保護」など一部の特定の目的のみで使われる時点で外れます) しかし一方で、この「知的所有権・著作権保護」目的の暗号化は、DRMがわかりやすく、暗号化の目的が「知的所有権・著作権保護」に限定されている必要があるように思います。 DXライブラリ自身が復号化しかできなくても、配信されるapkには暗号を含んでいて、その復号化に共通鍵方式で56bit以上の鍵が必要ということになりますので、 まさに「DXアーカイブに暗号を含み、それをDXライブラリで復号化する」ことが「知的所有権・著作権保護」のみを目的とするかがポイントになりそうです。 (暗号化されたDXアーカイブがない、無理矢理復号化しようとしたなどDXアーカイブに異常がある時に起動できない、まともに動かないなど、DRMの役割を果たせるかというところにあります)
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.6 )
名前:管理人 日時:2018/11/04 00:26

ご返信が遅くなり申し訳ありません > DXライブラリ自身が復号化しかできなくても、配信されるapkには暗号を含んでいて、その復号化に共通鍵方式で56bit以上の鍵が必要ということになりますので、 > まさに「DXアーカイブに暗号を含み、それをDXライブラリで復号化する」ことが「知的所有権・著作権保護」のみを目的とするかがポイントになりそうです。 > (暗号化されたDXアーカイブがない、無理矢理復号化しようとしたなどDXアーカイブに異常がある時に起動できない、まともに動かないなど、DRMの役割を果たせるかというところにあります) はい、DXライブラリとしては「知的所有権・著作権保護」のみを目的としてDXアーカイブの機能がありますので、 もしそれ以外の目的でDXアーカイブが使用された場合は規制の対象となると思います
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.7 )
名前:was-blue.0793 日時:2018/11/04 02:18

>>管理人様 ご返答ありがとうございます。 暗号化されたDXアーカイブを使う一般的な目的は著作権保護だと思いますので、"暗号化されたDXアーカイブを著作権保護の目的にのみ使う限り"問題はなくなってくると思います。 (無料で入手可能なフリー素材を入れていると少し微妙になってきそうではありますが……) 「DXアーカイブの機能を著作権保護の目的以外に使う場合アプリの配信に規制がかかる」旨の文章はどこかに書いておいた方がいいかもしれません。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.8 )
名前:yumetodo 日時:2018/11/04 14:46

でたよ、PGPのソースコードを書籍出版する必要に迫られた闇の規制。 ところでこれはDxArchiveの暗号機能を利用していなくてもDxLibとリンクすると対象となるように思われます。 つまり自力で当該部分を除去してビルドしない限りにおいて、すべてのケースで少なくとも届出が必要と読めてしまいませんかね・・・? PC向けについても、米国内、ないしワッセナー・アレンジメントでの合意等に基づき同様の法拘束をかけている国 (日本では外為法第25条?範囲がいまいちわからない) に拠点を置く企業のサービスを利用して配布した場合同様に対象になるように見えます。 したがってDxArchiveの暗号機能はDxLibに含めず、別のライブラリとするべきではないでしょうか?
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.9 )
名前:was-blue.0793 日時:2018/11/05 14:23

>>yumetodo様 以前mp3の特許が生きていた頃に私がmp3を非対応化する質問をした時も似たような問題があったと記憶していますが、 Windows向けかつ国内のみを対象とした場合でも暗号化には似たような規制があるのでしょうか? アメリカから輸出する場合の暗号の規制はDXアーカイブを使う目的が「著作権保護に限定されていれば」規制の対象から外れると理解しましたが、 このような法的な問題(日本にも同様の規制がある?こと)を考えると、yumetodo様の提案通りDXアーカイブの機能はDXライブラリから独立させた方がいいように思います。 SHA-256を使うだけなら一方向性で復号不可能なので、(ファイルの同一性を検査することを目的とするなどで)SHA-256ハッシュを取得することは問題ないようにも思いますが…… (Wikipediaにもアルゴリズムが公開されていますし)
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.10 )
名前:管理人 日時:2018/11/06 01:26

> was-blue.0793さん > 「DXアーカイブの機能を著作権保護の目的以外に使う場合アプリの配信に規制がかかる」旨の文章はどこかに書いておいた方がいいかもしれません。 ご提案ありがとうございます 検討してみます > このような法的な問題(日本にも同様の規制がある?こと)を考えると、yumetodo様の提案通りDXアーカイブの機能はDXライブラリから独立させた方がいいように思います。 別ライブラリにしてしまうと使い勝手の良さが大幅に低下するので独立させるのは避けたいところです > yumetodoさん > ところでこれはDxArchiveの暗号機能を利用していなくてもDxLibとリンクすると対象となるように思われます。 > つまり自力で当該部分を除去してビルドしない限りにおいて、すべてのケースで少なくとも届出が必要と読めてしまいませんかね・・・? 規制の対象にならない場合は届出の必要はないという認識なのですが、そうではなくて規制の対象外でも届出は必要なのでしょうか? > 8127さん すみません、No.1 のお書き込みで『DXアーカイブのver1.05以前は共通鍵方式で12bit』と仰られていますが、 こちらはどのような計算で 12bit と導き出されるのでしょうか? ver1.05では鍵文字列の最大長は12文字なので、12 * 8 = 96bit ではないのでしょうか?
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.11 )
名前:yumetodo 日時:2018/11/06 05:23

ええっと自分でも何を言っているかわからなくなりつつありますが、改めて整理を試みます。 ttp://dsas.blog.klab.org/archives/52146838.html をみつつ話を進めます。 まずDxLibとリンクしたすべてのアプリケーションおよびDxLib自身(暗号機能部分を自力で除去した場合を除く)が対象と言ったのは >02 “Software” as follows > (see List of Items Controlled) >(中略) > c.1. “Software” having the characteristics, or > performing or simulating the functions of the > equipment, controlled by 5A002; が根拠と思われたからです。 DxLib自体には明らかに暗号機能が含まれているので該当し、 利用するアプリケーションもリンクする(GPLとおなじく静的/動的の差異はないと思われる)以上、 その実行可能binaryを含む可能性があります(Link Time Optimizationで運良く吹き飛んだら別ですが) ただし、 1. ESRのCategory 5, Part 2 で規制されるか 2. 1のときにECCNによる番号分類による手続きの差 を考える必要があり、1で規制されない場合は届け出すら不要です。 先に届け出と言ったのは2で「一般に公開されている暗号ソースコード」に該当するので許可例外TSUが適用でき、 それが届け出するだけだという話でした。 で、具体的に見ていくわけですがちょっと眠いので寝ます。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.12 )
名前:8127 日時:2018/11/06 07:34

管理人さま、 >ver1.05では鍵文字列の最大長は12文字なので、12 * 8 = 96bit ではないのでしょうか? 12bitではなく12byteの間違いです(もうしわけない) 個人的には、 A.別ライブラリに分離 B.マクロで変更できるようにする(暗号化を排除したいユーザーはdxlibを自前ビルドしないといけない) C.むしろkeyを56bitに落としてしまう D.暗号化のあるなしのビルド済ライブラリを両方配布する くらいですかね・・・(管理人さまの手間が増えてしまいますが私はD推しです)
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.13 )
名前:yumetodo 日時:2018/11/06 23:06

というかlibを分ければいいのではないかなと。そしてVSユーザー向けには#pragmaによるlib自動読み込みはやらないようにして必要な人は各自libを依存追加する。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.14 )
名前:管理人 日時:2018/11/07 00:27

> yumetodoさん > 1. ESRのCategory 5, Part 2 で規制されるか > を考える必要があり、1で規制されない場合は届け出すら不要です。 私はこちらの『届け出すら不要』という認識なのですが、yumetodoさんの認識は違うのでしょうか? > 8127さん > 12bitではなく12byteの間違いです(もうしわけない) なるほど、了解です > A.別ライブラリに分離 > B.マクロで変更できるようにする(暗号化を排除したいユーザーはdxlibを自前ビルドしないといけない) > C.むしろkeyを56bitに落としてしまう > D.暗号化のあるなしのビルド済ライブラリを両方配布する DXライブラリをビルドしなければならなかったり、別ライブラリにするとプログラム中級者以上の方しか 使えなくなり、且つ使おうとする方も減ってしまうので選択肢としては C か D に絞られますが、 現状配布するライブラリの容量がかなり大きくなってしまっていますので D も選択肢から外れ、 選ぶとしたら残る C になります 56bit でも自動解析で暗号化解除されないような仕組みを考える必要がありますね… というか、個人的には  E.現状のままで問題ない だと思っているのですが、8127さんの認識もこちらではないのでしょうか?
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.15 )
名前:was-blue.0793 日時:2018/11/07 01:03

>>管理人様 暗号化の目的が「知的所有権・著作権保護」に限定されていれば確かに届け出の必要はないのですが、この辺りはライブラリ利用者がDXアーカイブをどう扱うかによって変わってきます。 (暗号機能を含むことが日本でいう"技術的保護手段"に該当するかということです) しかしライブラリ自体は現状維持で問題ないとしてもアプリを配信する時、「このアプリは暗号機能を含んでいますが、その目的は知的所有権・著作権保護目的に限定されています」というような一文を アプリ内、もしくはGoogle Playの説明などに含む必要が出てくるように思います。 さらにそのことの証明を求められた時、どうするかはまた考える必要がありますが……
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.16 )
名前:yumetodo 日時:2018/11/07 13:04

ゆっくり読み直した結果 1. DxLib自体→届け出(許可例外TSU)が必要(例えばGithub Releaseとかchocolateyとかその他パッケージマネージャ経由でbinaryを配布するとき。 日本での配布は調べていないので不明、ワッセナー・アレンジメントがどう効いてくるのか次第) 2. DxLibのDXA暗号化機能を「知的所有権・著作権保護」のために利用するアプリケーション→届け出不要 3. DxLibのDXA暗号化機能をその他の目的で利用する場合→ECCN番号分類に従って手続きが必要 ちなみにパスワードや公開鍵認証などで開発者のみにアクセスが限定されている配布でも(VPSとか)、まねきTV事件を考えるとグレーかなと思われます。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.17 )
名前:8127 日時:2018/11/07 15:13

>というか、個人的には >E.現状のままで問題ない >だと思っているのですが、8127さんの認識もこちらではないのでしょうか? はい、基本的にはそう考えています。 Dxlibのユーザーの中でAndroid(iOS)アプリをストアに公開する人&著作権を厳密に気にする人は多くない(10人に一人もいないのでは) と考えているので、"E.現状のままで問題ない"のスタンスを維持しつつ、そういう一部の人にはマクロを定義してリビルドをするなどで 対応できるようにするので良いかなと思っています。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.18 )
名前:管理人 日時:2018/11/07 23:30

> was-blue.0793さん > しかしライブラリ自体は現状維持で問題ないとしてもアプリを配信する時、「このアプリは暗号機能を含んでいますが、その目的は知的所有権・著作権保護目的に限定されています」というような一文を > アプリ内、もしくはGoogle Playの説明などに含む必要が出てくるように思います。 すみません、『「このアプリは暗号機能を含んでいますが、その目的は知的所有権・著作権保護目的に限定されています」 というような一文をアプリ内、もしくはGoogle Playの説明などに含む必要がある』というような解説がどちらかのウェブサイトか 書籍で言及されていたということでしょうか? もしくは EAR の原文や日本語訳でそのように解釈できる部分がありましたら、教えていただけないでしょうか? m(_ _;m > yumetodoさん ご確認ありがとうございます > 1. DxLib自体→届け出(許可例外TSU)が必要(例えばGithub Releaseとかchocolateyとかその他パッケージマネージャ経由でbinaryを配布するとき。 > 日本での配布は調べていないので不明、ワッセナー・アレンジメントがどう効いてくるのか次第) こちらは現在でも NuGet で配布しているので引っ掛かりますね… > 8127さん > Dxlibのユーザーの中でAndroid(iOS)アプリをストアに公開する人&著作権を厳密に気にする人は多くない(10人に一人もいないのでは) スマホアプリの開発者の方があまり気にされないのは Androidアプリや iOSアプリは 従来型のWindowsアプリほど簡単にはアプリのファイルに アクセスできないからかもしれません 従来型のWindowsアプリの場合はインストールされているフォルダを開けば誰でもアプリのファイルにアクセスできてしまうので、 簡単に中身を見られないようにしたいと考える方は多いです( そもそもDXアーカイブのセキュリティ強度を上げたのもそのようなご要望あってのことですし ) was-blue.0793さん、yumetodoさん、8127さんの『DXアーカイブの機能を分離( 若しくはデフォルトでは無効に )すべき』というご意見と 私の『DXアーカイブの機能を内包したままにしたい』という要望を同時に叶えるにはやはり鍵の長さを56bitにするしかなさそうです ( 同時に 56bit前のバージョンの暗号化されたDXアーカイブファイルが使えなくなってしまいますが… ) 現在手をつけている作業が終わり次第 56bit化に取り掛かろうと思います すみません、56bit化するに当たって皆様にお訊ねしたいのですが、SHA-256 で導き出される 256bit のハッシュ値の内、 先頭の 56bit( 7byte ) だけ使うようにすれば『鍵の長さは 56bitである』と考えてしまって良いのでしょうか? (・・;
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.19 )
名前:was-blue.0793 日時:2018/11/08 00:12

>>管理人様 すいません、「著作権保護〜」についての一文は私の解釈なので、この一文だけでは足りないかもしれません。 (本当に目的が「知的所有権・著作権保護」に限定されているなら書く必要はないのかもしれませんし……) 暗号化機能を維持しつつ規制に抵触しないようにするためには、やはり鍵を56bit以下にするしかないと思います…… 鍵の長さはSHA-256ハッシュの先頭から7byteだけを使うようにすれば問題なさそうではありますが、もととなるSHA-256自体は256bitあるのでそこから鍵の長さが256bitと扱われるかもしれません。 あるいはそのようなハッシュ関数があるかはさておき、出力が7byte以下となるハッシュ関数を使用するという手もあります。 (余談ですが以前話題になっていたDXアーカイブの暗号化を無理矢理解除するツールですが、DXアーカイブの暗号化は技術的保護手段になるので法的にはアウトな代物です)
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.20 )
名前:yumetodo 日時:2018/11/08 12:09

いや待ってください。許可例外TSUに基づく届け出をしさえすればDxLibは問題ないはずです。届け出なので投げつけて終わりです。 まあうちはちゃんとやってるんやで!というアピールはしておいて損はないと思いますが。 あとは利用者への注意喚起として、 DxLibのDXA暗号化機能をその他の目的で利用する場合→ECCN番号分類に従って手続きが必要 ということをどこかに書いてあげれば親切だと思います。 なにもbreaking changeをする必要はないです。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.21 )
名前:8127 日時:2018/11/08 12:43

管理人様、ちょっと待ってください、勘違いです。 >8127さんの『DXアーカイブの機能を分離( 若しくはデフォルトでは無効に )すべき』 デフォルトで有効(今のまま)で、無効にする場合だけマクロを変えてビルドする必要があると言っています。 (要するにAndroid(iOS)アプリをストアに公開する人は自分で#define DX_NON_ARCHIVE してビルドしてということ、そうでない大半のユーザーは何もしなくていい)
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.22 )
名前:管理人 日時:2018/11/09 01:17

> was-blue.0793さん > すいません、「著作権保護〜」についての一文は私の解釈なので、この一文だけでは足りないかもしれません。 > (本当に目的が「知的所有権・著作権保護」に限定されているなら書く必要はないのかもしれませんし……) 普通に使う分にはDXアーカイブの暗号化機能は「知的所有権・著作権保護」として使うことしかできないので、 記述は必要ないのではないかと思います > 鍵の長さはSHA-256ハッシュの先頭から7byteだけを使うようにすれば問題なさそうではありますが、もととなるSHA-256自体は256bitあるのでそこから鍵の長さが256bitと扱われるかもしれません。 > あるいはそのようなハッシュ関数があるかはさておき、出力が7byte以下となるハッシュ関数を使用するという手もあります。 ご見解&ご意見いただきありがとうございます yumetodoさんのご指摘で許可例外TSUに基づく届け出をするだけで問題はなさそう、とのことで56bit化は なくなりそうですが、仮に 56bit化する場合は別のハッシュ関数を探してみます > (余談ですが以前話題になっていたDXアーカイブの暗号化を無理矢理解除するツールですが、DXアーカイブの暗号化は技術的保護手段になるので法的にはアウトな代物です) そうなのですね、ズルをするソフト、というイメージではありましたが、明確に違法なものと分類されるとは思いませんでした > yumetodoさん > いや待ってください。許可例外TSUに基づく届け出をしさえすればDxLibは問題ないはずです。届け出なので投げつけて終わりです。 > まあうちはちゃんとやってるんやで!というアピールはしておいて損はないと思いますが。 すみません、許可例外TSUの届け出関係を確認してみました 本当にメールを送るだけなのですね、週末に送ってみます ( ただ、当然といえば当然ですが、配布先 URL などが変わったらその都度届出なければならないのですね… ) > あとは利用者への注意喚起として、 > DxLibのDXA暗号化機能をその他の目的で利用する場合→ECCN番号分類に従って手続きが必要 > ということをどこかに書いてあげれば親切だと思います。 普通に使う分にはDXアーカイブ内のファイルを読み込む時にしか暗号関係の処理は行われないので、 そのような記述があるとかえって利用者の方が『何か良くないことがあるのか?』と訝しんでしまわないでしょうか? 寧ろDXライブラリの暗号関係の処理を「知的所有権・著作権保護」以外の目的で利用する方法というのが思いつきません… yumetodoさんは何か「知的所有権・著作権保護」以外の目的で利用する方法を思いつきますか? > 8127さん > 管理人様、ちょっと待ってください、勘違いです。 > デフォルトで有効(今のまま)で、無効にする場合だけマクロを変えてビルドする必要があると言っています。 すみません、8127さんのお察しの通りの勘違いをしていました m(_ _;m ご提案の案とは少し異なりますが、暗号機能だけを無効化するためのマクロを追加しようと思います ( DXアーカイブの機能はDXライブラリ内でも使用してしまっていて、現在のバージョンでは DXアーカイブを無効化できないので… )
メンテ

Page: 1 | 2 | 3 |

題名
名前
コメント
パスワード (記事メンテ時に使用)

   クッキー保存