トップページ > 記事閲覧
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 |

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アーカイブを無効化できないので… )
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.23 )
名前:yumetodo 日時:2018/11/09 19:46

> yumetodoさんは何か「知的所有権・著作権保護」以外の目的で利用する方法を思いつきますか? 一般的な用途はもちろん知的所有権・著作権保護になると思いますが、例えばHTTP over DXAとかをやれないことはないかなと。 あと忘れてましたがDxLibのbinaryの再頒布をする場合は再頒布する人が許可例外TSUの届け出を投げないとだめですね。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.24 )
名前:管理人 日時:2018/11/11 01:24

> yumetodoさん > 一般的な用途はもちろん知的所有権・著作権保護になると思いますが、例えばHTTP over DXAとかをやれないことはないかなと。 すみません、HTTP over DXA とは何でしょうか? DXAファイルを通信で何処かに送るなどでしょうか…? > あと忘れてましたがDxLibのbinaryの再頒布をする場合は再頒布する人が許可例外TSUの届け出を投げないとだめですね。 なるほど うーんやはり柵が少ないほうが色々扱いやすくなる( あと、暗号関係の専用ソフトでもないのに暗号規制を 気にしなくてはいけないのは煩わしい )ので、やはり鍵を56bit化する方向で進めようと思います 旧バージョンの DxaDecode.cpp は配布し続けるので許可例外TSUの届け出は投げるとして、最新版を使う分には 暗号規制のことは気にしなくて良いようにしようかと その変更をしたとしても、影響を受けるのは   A.現在暗号化DXアーカイブを使ったソフトの開発を進めていて、且つDXライブラリを最新バージョンに更新した方   B.暗号化DXアーカイブを使用して作成したソフトの更新する際にDXライブラリを最新バージョンに変更した方 のみなので、( 旧バージョンのDXアーカイブでも暗号化していないファイルについては普通に読み込めるように しようと思います ) 暗号化DXアーカイブを使用されている方には、お手数をお掛けしてしまいますが一度 最新バージョンで再度暗号化DXアーカイブファイルを作成していただくという形で… Aの方もそこまで多くないと思いますし( 開発中の間は暗号化はしていないかもしれませんし )、Bの方に至っては 殆ど居られないと思います( バグ修正や追加要素でソフトを更新する場合もDXライブラリのバージョンは更新しない方が多い )
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.25 )
名前:yumetodo 日時:2018/11/11 13:57

>DXAファイルを通信で何処かに送るなどでしょうか…? 普通やらないでしょうが不可能ってわけでもないかなと。 いや、そもそもDxLibのbinaryを再頒布する人がまずいないのでは・・・。NuGetあるわけで。 わざわざ強度を下げるのは理解に苦しみます。 --- いやまてよ、更に混乱してきたんですが 質問 G(1): 機械可読コード形式のソフトウェアの輸出又は再輸出は、 このソフトウェアのソースコードが一般に入手可能な場合、 EARの対象となりますか? 答:ソフトウェアプログラムのソースコードが一般に入手 可能な場合、ソースコードからコンパイルされた機械可読 コードは、一般に入手可能なソフトウェアであり、従って EAR の対象とはなりません。 これはどう解釈したらいいんだろう。DxLibのソースコードは公開されているから再頒布は規制対象外ってこと?
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.26 )
名前:管理人 日時:2018/11/11 21:51

> yumetodoさん 許可例外TSU届け出メール送信しました。 > 普通やらないでしょうが不可能ってわけでもないかなと。 そうなんですよ、普通やらないようなことに対してそのような注釈を入れると、 普通に使っているだけでも何か気をつけなければならないのではないかと 思われてしまうのではないかと… > いや、そもそもDxLibのbinaryを再頒布する人がまずいないのでは・・・。NuGetあるわけで。 実際にDXライブラリを使用したプログラミング解説などのサイトで ダウンロードできるサンプルプログラムにDXライブラリのパッケージが 同梱されている場合もありますので、これらのことを仕様とする際に その都度許可例外TSUを届け出るのは大げさですし、かといって 『DXライブラリは別途”DXライブラリ置き場”からダウンロードしてください』 とすると利便性が下がりますし、規制外にするメリットはあります > わざわざ強度を下げるのは理解に苦しみます。 強度は下がるかもしれませんが、思えば件のツールもDXアーカイブのヘッダの中で 固定の値になってしまう箇所を狙い打ちにして鍵を取り出していたので、ヘッダの 中からそのような部分を除いてしまえば各ファイルの鍵の長さが7byteになって しまったとしても、少なくとも『プログラムによる固定処理』で鍵が割り出されて しまうことはなくなるのではないかと思いまして ( そういう意味では、SHA-256 を使う最新版以前の簡易的な xor処理でも、ヘッダから 固定値部分を除いてしまうだけでも良かったかもしれません ) > 質問 G(1): > 機械可読コード形式のソフトウェアの輸出又は再輸出は、 > このソフトウェアのソースコードが一般に入手可能な場合、 > EARの対象となりますか? >  > 答:ソフトウェアプログラムのソースコードが一般に入手 > 可能な場合、ソースコードからコンパイルされた機械可読 > コードは、一般に入手可能なソフトウェアであり、従って > EAR の対象とはなりません。 >  > これはどう解釈したらいいんだろう。DxLibのソースコードは公開されているから再頒布は規制対象外ってこと? こちらの日本語訳をそのまま受け取れば規制対象外となりそうですが…
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.27 )
名前:8127 日時:2018/11/11 22:24

管理人様、 >少なくとも『プログラムによる固定処理』で鍵が割り出されて >しまうことはなくなるのではないかと思いまして pngファイルに必ず含まれるバイナリは16byte = 128bitで、89504E470D0A1A0Aなのですが、 暗号化キーが56bitだと暗号文に片っ端から89504E470D0A1A0Aとのxorをとり、結果が56bitでループする場所を探すことで キーを『プログラムによる固定処理』で割り出せます。 >( そういう意味では、SHA-256 を使う最新版以前の簡易的な xor処理でも、ヘッダから >固定値部分を除いてしまうだけでも良かったかもしれません ) ファイルごとに異なるキーを使用するようになったので、上記の方法でもpngファイルしか取れないという点で、 (56bitだとしても)最新版の方が断然安全性が高いと考えます。 私自身の意見としては、議論を尽くした結果、もしも今のままでまずいのであれば、56bit化もやむを得ないと思います。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.28 )
名前:yumetodo 日時:2018/11/12 00:23

そろそろESRの解釈についてはStackOverflowあたりに投げるべきかもしれない。ここを見ている人よりは詳しいはず。。。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.29 )
名前:was-blue.0793 日時:2018/11/12 22:25

>>yumetodo様、管理人様 私はこの一文について、DxLibに関係する場所以外でもすべてのソースコードを公開しなければならないと解釈しています。 私としては、(少なくとも国内、セキュリティ研究目的以外でDMCAにおいては)DXアーカイブの暗号化を無理矢理解除することは法的にアウトと考えていますので、 (実効性はともかく)法的な意味では鍵長に関係なくDXアーカイブの暗号化を無理矢理解除することはできないことになっていると考えます。 また、暗号化関連については、Play Consoleヘルプによると、より詳しいガイドを提供できる連絡先を掲載しているページがあるとのことです。 support.google.com/googleplay/android-developer/answer/113770?hl=ja 英語で質問しなければなりませんが、参考になれば。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.30 )
名前:管理人 日時:2018/11/13 01:08

> 8127さん > pngファイルに必ず含まれるバイナリは16byte = 128bitで、89504E470D0A1A0Aなのですが、 > 暗号化キーが56bitだと暗号文に片っ端から89504E470D0A1A0Aとのxorをとり、結果が56bitでループする場所を探すことで > キーを『プログラムによる固定処理』で割り出せます。 はい、それは私も思いついていたので、pngファイルや jpegファイルなどのメジャーなファイルは固定のヘッダ部分を 潰すような小細工をしようと思います( デコードの際に復元 ) > was-blue.0793さん > 私はこの一文について、DxLibに関係する場所以外でもすべてのソースコードを公開しなければならないと解釈しています。 『すべてのソースコード』とは、『DXライブラリの全てのソースコード』という意味でしょうか? あと、文面のどの部分からそのように解釈されたのか教えていただけないでしょうか? > また、暗号化関連については、Play Consoleヘルプによると、より詳しいガイドを提供できる連絡先を掲載しているページがあるとのことです。 > support.google.com/googleplay/android-developer/answer/113770?hl=ja >  > 英語で質問しなければなりませんが、参考になれば。 ご情報ありがとうございます 英語で質問できないので、質問はできませんが…
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.31 )
名前:was-blue.0793 日時:2018/11/13 20:42

>>管理人様 "ソフトウェアプログラムのソースコードが一般に入手可能な場合、"という一文より、(規制対象となる暗号機能のある)DXライブラリを使用しているアプリは、 DXライブラリ部分のソースコードだけでなくアプリ全体をオープンソース化、つまりソースコードを全て公開しなければならないと解釈しています。 これはGPLのライブラリを使った場合とほぼ同様という意味合いになります。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.32 )
名前:管理人 日時:2018/11/13 23:52

> was-blue.0.793さん > "ソフトウェアプログラムのソースコードが一般に入手可能な場合、"という一文より、(規制対象となる暗号機能のある)DXライブラリを使用しているアプリは、 > DXライブラリ部分のソースコードだけでなくアプリ全体をオープンソース化、つまりソースコードを全て公開しなければならないと解釈しています。 >  > これはGPLのライブラリを使った場合とほぼ同様という意味合いになります。 『規制対象となる暗号機能のあるDXライブラリを使用しているアプリは』 ではなく 『DXライブラリの暗号機能を規制対象となる使い方をしたアプリは』 ですよね? ともあれ、鍵の 56bit化をして、規制に関する解釈に頭を悩ませる必要はなくなるようにしますので少々( 何週間か掛かるかもしれませんが… )お時間をください m(_ _)m
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.33 )
名前:was-blue.0793 日時:2018/11/14 15:21

>>管理人様 そうでした……現在でも「知的所有権・著作権保護」に目的が限定されているなら規制対象外でした!すいません! しかし、DXアーカイブを規制対象となる使い方をしていた場合はソースコードを公開する必要が出てきます。 暗号強度が下がることは少し不安もありますが、暗号規制という壁を考えると致し方なしと考えます。
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.34 )
名前:yumetodo 日時:2018/12/09 02:51

DxLib Advent Calendar 2018 9日目の記事としてまとめさせていただいたので報告までに。 DxLibのDxArchiveの暗号化する機能とExport Administration Regulations 輸出管理規則 ttps://qiita.com/yumetodo/items/89af53d3cf8bc236de2f
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.35 )
名前:管理人 日時:2018/12/10 23:42

記事拝見いたしました 分かりやすく纏められていて改めて勉強になりました 一点気になったのが 『というわけで、議論の末Hash関数にSHA-256を採用しつつ暗号化するように変更がなされました。12bitから一気に増えたね。』 という文章なのですが、12bitという数字はどのように算出されたものでしょうか? SHA-256以前はパスワード文字は最大12文字だったのですが…
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.36 )
名前:8127 日時:2018/12/13 02:21

代わりに編集リクエストしておきました。 (僕もこの掲示板で2回bitとbyteの間違いをやらかしました・・・)
メンテ
Re: Android版:DXアーカイブの暗号化機能について ( No.37 )
名前:管理人 日時:2018/12/14 20:10

> 代わりに編集リクエストしておきました。 ありがとうございます 現在は『12byte』となっているようです m(_ _)m
メンテ

Page: 1 | 2 |

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

   クッキー保存