自堕落な技術者の日記

基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通

Android

2014年10月26日10:25
カテゴリ
ガジェット
Android

(続き1)POODLE攻撃について本当にTLSv1.0なら安全なのか？(OpenSSLは安全)

前回はTLSv1.1以降とTLSv1.0とでパディング処理に関するRFC上の規定が違うのでPOODLE攻撃の影響を受ける実装があるのではないか、という話をしました。

影響を受ける可能性が高いのはTLSv1.0と、TLSv1.1やTLSv1.2とで パディング処理の実装を区別しているケースでは影響をうける可能性があります。

OpenSSLの最新のもの1.0.1jについて、ソースを見てました。 結論から言うと、TLSv1.xではPOODLEへの影響が無い事が確認できました。

OpenSSLのソースコードでは、sslディレクトリの下に SSL/TLS関係のコードがまとめられており、大まかに、

  • s3_*.c SSLv3(or TLSv1.x)のコード
  • d1_*.c DTLSv1のコード
  • t1_*.c TLSv1.xのコード
となっています。 CBCモードのパディング処理については、SSLv3、TLSv1.x共に、 ssl/s3_cbc.c に定義があり、以下の関数でパディング部分の削除とパディングのチェック を行っています。
  • ssl3_cbc_remove_padding
  • tls1_cbc_remove_padding
関数ssl3_cbc_remove_paddingでは、 確かにパディングの値をチェックしていないことが確認でき、 関数tls1_cbc_remove_paddingでは、 
# to_check：チェックが必要なパディングバイト数
# padding_length：パディング長の値バイト
# b：チェック対象の値バイト
for (i = 0; i < to_check; i++)
  {
  unsigned char mask = constant_time_ge_8(padding_length, i);
  unsigned char b = rec->data[rec->length-1-i];
  /* The final |padding_length+1| bytes should all have the value
   * |padding_length|. Therefore the XOR should be zero. */
   # XORを取ってゼロならばパディング長の値バイトと対象は一致
   good &= ~(mask&(padding_length ^ b));
  }
のようにTLSv1.0でもTLSv1.1でもTLSv1.2でも 共通で同じパディング値バイト列のチェックを行っているので、 TLSv1.0でPOODLE攻撃の影響が無い事が確認できました。

とりあえずOpenSSLについては、こんな所で。

タグ ：
#OpenSSL
#TLSv1.0
#TLSv1.1
#POODLE
#脆弱生
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2013年12月04日00:08
カテゴリ
Nexus 7 (2013)

Nexus 7 液晶タッチパネル落下破損(トホホ)

あまりにも悲しすぎて、誰にも言ってなく現実逃避していたんですが、 会社で打合せスペースを空けるようせかされてThinkPadとNexus 7を重ねて 持っていたらするっと手元を滑り床に落ち、液晶タッチパネルに大きくヒビが数本入り半分がタッチが反応しない 状態になってしまいました。ががーん。買ったばかりなのに泣きそうで とてもへこみました。割れた箇所はこんな感じです。

nexus7_glass1
nexus7_glass2

ルート化していないのでバックアップが面倒そうでしたが、Heliumが良さそうなので バックアップの準備を進めてました。

Appllio: 機種変更前に知っておきたい、Androidアプリデータのバックアップ・復元方法まとめ
http://appllio.com/20131023-4343-android-app-data-backup-restore
破損した液晶タッチパネルの交換のための下調べをしていました。 ASUSストアで買ったのですが、ASUSは対応よくやっていただけるようです。

交換費用は大体1万円ぐらいなんですが、クレジットカードの ショッピングプロテクション的なものが使えないのかと調べてもみました。 「 ○×カードを利用して購入した１個、１組１万円以上の商品です。但し、下記商品を除きます。 ：中略 (ｘ) 携帯式電子機器(移動電話、ポケットベル等の通信機器、ノート型パソコン、 ワープロ等の携帯式電磁事務機器及びこれらの付属品 」 ががーん、タブレットだめじゃん。

さて、バックアップの準備も整って、始めようとしてみたらログインできません。 最初は画面半分ちょいはタッチ入力できたので、 上下反転させながら何とか入力できていたんですが、 そのうちログインパターンの入力ができないような状態になってしまい バックアップすら取れなくなってしまいましたorz

バックアップやらなんやら全てをあきらめておとなしくASUSに修理に出す事にしました。サポート窓口のフォーム入力したら2日後メールが来て、修理依頼書を書いて着払いで以下を送って下さいとの事でした。

  • 本体＋付属品(ACアダプタ,USBケーブル)
  • 修理依頼書、保証書、レシート(納品書)

とほほ・・・どな・どな・ど〜な・ど〜な〜

続きを読む
タグ ：
#Nexus7-2013
#修理
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2013年11月17日22:29
カテゴリ
Cipher Suite
Android

JRE 1.4-1.6やAndroidのAPIを使ったHTTPS接続のCipherSuitesがRC4-MD5を優先しているかなりヤバい話

OWASP Night 8thに行ってきて、iOSやAndroidのいろんなアプリのHTTPS接続の検証がいい加減という話を聞いてきたんですが、それよりもAndroidのデフォルトブラウザChromeが失効検証をしない(=証明書の取り消し確認をしない)という事だって十分問題なんじゃないかなぁとか思ったりしてました。

そういえば以前、秋山さんにAndroidだとHTTPS通信がRC4-MD5になっちゃうという話を聞いて、実際にAndroid上のChromeやOperaやFireFoxを見て全く問題ないことを確認し「よしよし安心だ」などと思っていました。

あれれ?待てよ、秋山さんが言っていたのはブラウザではなく、APIで呼び出したときのCipherSuiteの順序関係の可能性もあるなと思ってグーグル先生に聞いて調べてみました。

(文献1)Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010 (2013.10.13)
http://op-co.de/blog/posts/android_ssl_downgrade/
(文献2)The Register: Android security relies on ZOMBIE CRYPTO, argues infosec pundit (2013.10.16) http://www.theregister.co.uk/2013/10/16/zombie_cipher_list_gives_android_weak_encryption/

あらら、こりゃやべーよ。なんか検索してみても日本では誰も騒いでないみたいだよ。一ヶ月も放っぽりぱなしだったんだなぁ。自分が第一発見者なら公開せずJPCERTとかに報告するんだけどグローバルには公表から1ヶ月も経っているので、国内で騒がれてないようだから書いとくかなと。

結論から言うと、Java 1.4から1.6ぐらい、Android 2.3以降の全てのバージョンで、ウェブブラウザではなくHttpURLConnectionやApacheのHttpClientなどのクラスのAPIを使ったクライアント実装でHTTPS接続する場合には、デフォルトではRC4-MD5といったとても弱い暗号が最優先で使われるために、「必ず」明示的に暗号設定を指定する必要がある。

という事です。JavaやAndroidのHTTPSクライアントを使用する開発者の方は是非対応をお願いしたいです。

AndrodのHttpURLConnectionクラスの利用

早速、簡単なAndroidのHTTPSクライアントをHttpURLConnectionクラスを使って書いて接続し、CipherSuitesを確認してみました。Android 4.0.3で確認しましたが、やはりRC4-MD5が優先になっていました。文献1によればAndroid 2.3.4以降、Android 4.3までダメなようです。 

Client Hello Version: TLS 1.0
TLS Version: TLS 1.0
Num Cipher Suites: 35
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008)
Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014)
Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

例えばAndroid 4.1のNativeCrypto.javaのソースコードを見ると確かにRC4-MD5が優先になっているように見えます。

Oracle JavaのHttpURLConnectionクラスの利用

文献1によれば、そのようなCipherSuiteのデフォルト設定はOracle(Sun) Java JRE/JDKの 設定から来ているもので、Java 1.4.2_19, 1.5.0 (2004)から Java 1.6 (2006)まで 弱いRC4-MD5が優先されていると書いています。

Windows版Sun JDK 1.6.0_21 b07では以下のようになっていました。確かにRC4-MD5優先です。 

Client Hello Version: SSL 2.0
Client Hello Version: TLS 1.0
Num Cipher Suites: 19
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x000004)
Cipher Suite: SSL2_RC4_128_WITH_MD5 (0x010080)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x000005)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x00002f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x000033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x000032)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a)
Cipher Suite: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x000016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013)
Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x000009)
Cipher Suite: SSL2_DES_64_CBC_WITH_MD5 (0x060040)
Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x000015)
Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x000012)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003)
Cipher Suite: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080)
Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000008)
Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000014)
Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x000011)

これが、Oracle(Sun) Java JRE/JDK 1.7.0 b147だと以下のようになり、 DHE-RSA-AES128-SHAが優先されており、1.7のとあるバージョンからは問題が直っているのだと思います。 

Client Hello Version: TLS 1.0
TLS Version: TLS 1.0
Num Cipher Suites: 21
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

この問題を解決するには開発側でなんとかするしかない

この問題を解決するにはHttpURLConnectionで明示的にCipherSuiteやSSL/TLSのバージョンを 指定してやる必要があります。SSLSocketクラスでsetEnablesCipherSuites()メソッドを使う プリミティブな方法もありますが、プロパティで設定する方が簡単かもしれません。 

System.setProperty("https.cipherSuites", 
                   "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA," +
                   "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA");
System.setProperty("https.protocols", "TLSv1.2,TLSv1.1");
URL url = new URL("https://www.verisign.com/");
BufferedReader in = 
  new BufferedReader(new InputStreamReader(url.openStream()));
String inputLine;
while ((inputLine = in.readLine()) != null)
  System.out.println(inputLine);
in.close();

国内でもこの問題が広く認知され、対応されるといいですね。

今日はこの辺で

タグ ：
#Android
#Java
#CipherSuite
#RC4
#MD5
#弱い暗号
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2013年11月12日06:41
カテゴリ
Android
Cipher Suite

(小ネタ)Android 4.3.1と4.4 KitKatのCipherSuiteの違いを見てみたぞ

新型Nexus 5をゲットしたgregさんが、週末SSLハンドシェイクしたところのパケットキャプチャを送ってくれたのでNexus 5 Android 4.4 KitKat上のChrome 30.0.1599.105のCipherSuiteを見てみました。結果から言うとAndroid 4.3.1 Chrome 30.0.1599.96と、サポートしているCipherSuiteも、優先順位も含めて全く変わりがありませんでした。まぁ、そりゃそうだよね。

CipherSuiteラヴな人にとってはNexus 5は喰いつきポイントは無かったってことで。gregさんいつもありがとう。

タグ ：
#Android
#KitKat
#CipherSuite
#4.4
#Nexus5
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2013年11月10日17:11
カテゴリ
Android
ルート認証局リスト

Android 4.3.1 と 4.4 KitKatのルート証明書リストの違いを見てみたぞ

gregさんが新しいNexus 5をゲットして、ルート証明書リストを Root CA Viewer Lite でエクスポートして送ってくれたので(gregさんありがとう)、 早速比較してみます。

で、比較してみると

差分はこんな感じ。

バージョンルート認証局数追加変更
Android 4.0.4134--
Android 4.3.1146122
Android 4.41504-
たった 4 つしか増えていないと・・・まぁ、そんなもんか。

新規追加されたのは

以下が、新規に追加された4個のルート認証局の一覧です。

認証局の識別名(DN)有効期間署名アルゴリズム鍵長
CN=ACCVRAIZ1, OU=PKIACCV, O=ACCV, C=ES2011-2030SHA1withRSARSA 4096bit
CN=Hellenic Academic and Research Institutions RootCA 2011, O=Hellenic Academic and Research Institutions Cert. Authority, C=GR2011-2031SHA1withRSARSA 2048bit
CN=Entrust Root Certification Auuthority - EC1, OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, O=Entrust, Inc., C=US2012-2037SHA384withECDSAECC secp384r1
CN=StartCom Certification Authority G2, O=StartCom Ltd., C=IL2010-2039SHA256withRSARSA 4096bit
ギリシャの認証局と、エントラストの楕円 SHA384withECDSA secp384r1なんかが 特徴的ですかね。

今日はこのへんで

関連記事

タグ ：
#Android
#Root
#CA
#ルート証明書
#Nexus
#5
#4.4
#KitKat
#ルート認証局リスト
#トラストアンカ
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2013年11月06日08:31
カテゴリ
Android
プログラミング

Android SDK 19だかJSONだかAdMobだかzipalignだかでハマった話

熱があって体調激悪ですが、なんか書いてみましたの第二弾です。

週末、自前のAndroidアプリの 手直しをしようとしててハマったので愚痴だと思って聞いてください。

Root CA Viewer Liteに証明書リストをエクスポートする機能を追加しようと思い、 幾つかのサイトを参考にしながら、でも、Android のプログラミングも超久しぶりなので ビルドどうやんだっけ？、コード署名どうやんだっけ？などもたもたしながら 2時間ほどで実機で動作することは確認できました。

実機確認はGoogle PlayにあげずにLAN内でやるわけですが、 AirDroidは すごく助かりますね。これをあげるとAndroid側がリモートサーバーになって 開発機からapkをアップしたり、SDカードみたりいろんなことができて実機テストが捗ります。

まず、zipalignでハマる

で、まぁ動いたから公開すんべぇとGoogle Playにアップしようとしたら zipalignされてないからアップロードできないと英語で怒られました。

minghaiさんの日記：apkファイルを最適化する zipalign
に説明があった。apkファイルがzipalignされてないとapk(zip)解凍の時、非常に メモリ効率が悪くなるのだそうです。

探してみるも zipalign などない。どうやら新しい Android SDK でないと 入っていないそうです。仕方ないのでAndroid SDK Managerで アップデートをかけました。Android 4.0.3 API 15 までしか入ってなかったんですが、 Android 4.4 API 19 まで上げてみます。APIのターゲットは15のままです。 ただし、Google AdMobは、コード手直ししないといけなそうだったりしたので、これだけ保留にしておきました。

で、アップデートすると、「そもそもEclipseのライブラリが古いよ」とこれまた 英語で怒られてヘコみます。これは従順に言われた通りに上げます。

参照関係に泣く

で、Root CA Viewerをリビルド、エミュレータで実行させようとすると、リビルドできない。

Unable to execute dex: java.nio.BufferOverflowException. Check the Eclipse log for stack trace.
その他にも、DEXが壊れててよめねーじゃねーかと英語で怒られます。 Eclipseのログ見ろっていってもログの場所がわからない。

Google大先生に聞いてみるとEclipseのログは $WORKSPACE/.metadata/.logにあることがわかりました。 ログにはあまり参考になりそうな情報はありませんでしたが、 多分、参照関係がおかしくなっているんでしょうね。 Google AdMobが古いせいなのかなと思い、AdMobライブラリも新しくしてみました。 一部、ソースコードやらXML設定ファイルやらを手直しして再度ビルドします。

再度ビルドしてみようとすると、

com.google.ads.AdView failed to instantiate. java.lang.ClassNotFoundException: org.json.JSONException at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
と怒られます。ええーーっ、JSON入ってないの？使っているJDKが古いのか、 Androidのライブラリが古いんでしょうねぇ。 Google大先生にJSONの件を聞いたら このページ(NoClassDefFoundError when trying to unit test JSON parsing in Android)を返してくれました。 APIのターゲットを上げると4.0そこそこのやつでは 動かなくなりそうだったので、org.jsonのソース探して、jar作って 置いてみました。

すると、またコレが出るようになりました。

Unable to execute dex: java.nio.BufferOverflowException. Check the Eclipse log for stack trace.
結局解決してなかったのね。

随分調べて このページ(Issue 61710:java.nio.BufferOverflowException When Building with 19 Build Tools) を見つけました。どうやらAndroid SDK 19 Build Toolの問題らしく、

  1. Android 19 Build Tools, API 19を削除する
  2. Target SDK を19から18に戻す
  3. extras/android/support/v7/appcompat/libs/android-support-v4.jarの参照を削除する
  4. 再度 android-support-v4.jar を追加する
なんか、書かれた通りにうまく行かない事もあったんですが、Eclipseを再起動したり、プロジェクトを閉じたり、開いたりしている うちに、書かれた方法で無事ビルドでき、動作するところまではこぎつけました。

最後にzipalignではまる

結局は署名済apkが出力される場所が間違っていたというオチなわけですが、 本来なら署名済apkを作った際に自動的にzipalignも実行されるとの事です。 結局コマンドラインでやってしまいました。

% tools/zipalign 4 RootCAViewerLite.apk RootCAViewerLite_.apk (*_.apkが出力先で署名済)
% tools/zipallgn -v -c RootCAViewerLite_.apk (チェック)
Verifying alignment of RootCAViewerLite.apk (4)...
62 res/layout/activity_cert.xml (OK - compressed)
655 res/layout/activity_main.xml (OK - compressed)
1252 res/layout/activity_textview.xml (OK - compressed)
1937 res/menu/activity_cert.xml (OK - compressed)
2256 res/menu/activity_main.xml (OK - compressed)
2604 res/menu/activity_textview.xml (OK - compressed)
2916 AndroidManifest.xml (OK - compressed)
4000 resources.arsc (OK)
7316 res/drawable-hdpi/ic_action_search.png (OK)
7788 res/drawable-hdpi/ic_launcher.png (OK)
9864 res/drawable-ldpi/ic_launcher.png (OK)
11236 res/drawable-mdpi/ic_action_search.png (OK)
11612 res/drawable-mdpi/ic_launcher.png (OK)
13272 res/drawable-xhdpi/ic_action_search.png (OK)
13828 res/drawable-xhdpi/ic_launcher.png (OK)
16458 classes.dex (OK - compressed)
570061 README (OK - compressed)
571082 jsr305_annotations/Jsr305_annotations.gwt.xml (OK - compressed)
571300 jsr305_annotations/v0_r47/V0_r47.gwt.xml (OK - compressed)
571474 META-INF/MANIFEST.MF (OK - compressed)
572232 META-INF/CERT.SF (OK - compressed)
573041 META-INF/CERT.RSA (OK - compressed)
Verification succesful
ファイルサイズが昇順になるんですね。というわけで、いろいろありましたが何とか新しいRoot CA Viewer Liteを 公開することができました。あーつかれた。

タグ ：
#Android
#apk
#zipalign
#SDK
#JSON
#AdMob
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2013年11月06日08:25
カテゴリ
Android
ルート認証局リスト

Android 4.0.4 と 4.3.1 のルート証明書リストの違いを見てみたぞ

熱があって体調激悪ですが、なんか書いてみましたの第一弾です。

4.4 KitKatが出る前に、手持ちのAndroid 4.0.4と4.3.1の信頼するルート証明書のリストの魚拓(=バックアップ)を取っておこうと Root CA Viewer Lite(for Android 4.x) に手を加えてみたんですが、別の会にでもお話をしようと思うハマったポイントがあり紆余曲折の末、 まぁ何とか半日かけてアップデートができたわけです。

今回のRoot CA Viewer Lite 1.2.2の機能追加では、Android 4.xのルート証明書をシステム登録されたものも、 ユーザ追加したものも全てASN.1 DERバイナリ形式で取り出し、ZIPで固めてこれをSDカードの領域に エクスポートするというものです。 (本当は処理中のグルグルとか表示させないといけないんでしょうけど、 手抜きでホントすみません。)

で、比較してみると

これで無事、ルート証明書は取り出せるようになったので、 比較してみましょう。差分の個数はこんな感じ。

バージョンルート認証局数追加変更
Android 4.0.4134--
Android 4.3.1146122
古いXperiaの時にもルート認証局のリストを調べていますが、 その時はAndroid 1.6 で 52のルート認証局でした その時から比べて随分増えていますよね。

新規追加されたのは

以下が、新規に追加された12個のルート認証局の一覧です。欧州が多い感じがありますが、セコムトラストさんも追加されてますね。 ほぼ、SHA256withRSAなんだなぁっていうのが特徴的かなと思います。

認証局の識別名(DN)有効期間署名アルゴリズムRSA鍵長
CN=D-TRUST Root Class 3 CA 2 2009,O=D-Trust Gmbh,C=DE2009-2029SHA256withRSA2048bit
CN=T-TeleSec GlobalRoot Class 3,OU=T-Systems Trust Center,O=T-systems Enterprise Services GmbH,C=DE2008-2033SHA256withRSA2048bit
CN=Buypass Class 3 Root CA,O=Buypass AS-983163327,C=NO2010-2040SHA256withRSA4096bit
CN=Swisscom Root CA 2,OU=Digital Certificate Services,O=Swisscom,C=CH2011-2031SHA256withRSA4096bit
CN=Izenpe.com,O=IZENPE S.A.,C=ES2007-2037SHA256withRSA4096bit
CN=Certinomis - Autorité Racine,OU=0002 433998903,O=Certinomis,C=FR2008-2028SHA1withRSA4096bit
CN=Buypass Class 2 Root CA,O=Buypass AS-983163327,C=NO2010-2040SHA256withRSA4096bit
CN=EC-ACC,OU=Jerarquia Entitats de Certificacio Catalanes,OU=Vegeu https://www.catcert.net/verarrel (c)03,OU=Serveis Publics de Certificacio,O=Agencia Catalana de Certificacio (NIF Q-0801176-I),C=ES2003-2031SHA1withRSA2048bit
CN=A-Trust-nQual-03,OU=A-Trust-nQual-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT2005-2015SHA1withRSA2048bit
OU=Security Communication RootCA2,O=SECOM Trust Systems CO.,LTD.,C=JP2009-2029SHA256withRSA2048bit
CN=D-TRUST Root Class 3 CA 2 EV 2009,O=D-Trust GmbH,C=DE2009-2029SHA256withRSA2048bit
CN=Root CA Generalitat Valenciana,OU=PKIGVA,O=Generalitat Valenciana,C=ES2001-2021SHA1withRSA2048bit

変更されたのは???

認証局の識別名(DN)有効期間署名アルゴリズムRSA鍵長
CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA1996-2021SHA1withRSA1024bit
CN=Thawte Server CA/emailAddress=server-certs@thawte.com,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA1996-2021SHA1withRSA1024bit
両方ともThawteのやつなんですが、証明書の変更された差分を見てみると、認証局の鍵は1024bitのやつ同じものを使ったまま、署名アルゴリズムをMD5withRSAからSHA1withRSAにして、 有効期限を1年延ばして、シリアル番号を変更して証明書をロールオーバーしちゃってます。 鍵長もそうですが、同じ鍵を使い続けててこれ、ホント大丈夫なんですかね。運用規定違反になったりしないのかな。

おまけ

Root CA Viewer Liteで証明書をエクスポートすると、個々の証明書のファイルは「system_4fbd6bfa.0」みたいない感じになっており、JCEの証明書ストアの証明書のalias 「system:4fbd6fa.0」に対応しています。「4fbd6fa.0」はOpenSSLの認証局の証明書ファイルの保管方法によるもので、証明書の識別名のハッシュみたいなものから作られています。 この名前の決まり方はJNSAのセミナー「OpenSSL 1.0.0のリリースについて」でお話しており、 スライドのページ番号32、33をご覧頂ければと思います。 この記事思い出して確認したんですが、 ハッシュファイル名は -subject_hash_old の方、つまりOpenSSL 0.9.8ベースのハッシュファイル名になったままのようですね。 とはいえ、ベースとなっているOpenSSLは0.9.8とは限らないので、どのなのかは調べる方法あるんですかね。

今日はこのへんで

関連記事

タグ ：
#Android
#ルート証明書
#ルート認証局
#ルート認証局リスト
#トラストアンカ
#RootCAViewerLite
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2013年11月04日02:18
カテゴリ
Android
Java暗号プログラミング

(小ネタ)Android 4.0.4と4.3.1とでJCEプロバイダはどう違うのか

新しいNexus 5がリリースされ新しいOSであるAndroid 4.4 KitKatも お目見えしたわけで、Nexus 7 2013を持っている私としては 早くアップデートが出るのを心待ちにしています。

さて、アップデートが出てしまう前に、Android 4.0.4 (CUBE U20GT) と、Android 4.3.1 (Nexus 7 2013)とでJCEプロバイダがどう違うのかを みておきました。調べるのにはJCE Provider Checkerを使いました。

違いのまとめ

  • AndroidOpenSSLプロバイダ
    • Mac: HmacSHA{1,256,384,512}の追加
    • Cipher: AES,DES,3DES等追加
    • Signature: {MD5,SHA{1,256,384,512}with{RSA,ECDSA}, SHA1withDSAの追加
    • SecureRandom: SHA1RPNGの追加
    • SSLContext: TLSv1.1, TLSv1.2の追加
  • BCプロバイダ
    • バージョンが1.46から1.48へ
    • 実装クラス名やAliasの変更がほとんどか？
  • AndroidKeyStoreプロバイダが新たに追加された

AndroidOpenSSLでTLSv1.1, v1.2がサポートされるようになったのは重要ですかね。 JCE Provider Checkerはデータのコピペが面倒だとわかったのでこれは改善しないといけません。

タグ ：
#Java
#JCEプロバイダ
#JCE
#Android
#暗号ライブラリ
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2013年10月28日00:33
カテゴリ
Android
Emacs

(祝) Nexus 7 購入記念：Emacsな人に向く外部キーボードとスタンドとテキストエディタを求めて三千里

先日、台風で足止めを食った勢いで Nexus 7 (2013) を買ってしまい、最近遊び倒しています。前の中華パッド Cube U20GT ではBluetoothがついていなかったので外部キーボードが使えずに悲しい思いをしていたんですが、 Nexus 7はこれが使えるので嬉しいところです。外部キーボードとスタンドで、EmacsやEmacs風キーバインディングのエディタなど使ってなんとか我慢できるようなキー入力環境ができつつあるのでブログにで紹介しておこうと思います。 (この記事は頑張ってポケモンキーボードで書いています。)

試したBluetoothキーボードは手持ちだったり購入した次の３つです。他にも会社のiMacのBluetoothキーボードがあったはずなんだけど、取り上げられちゃったなぁ。返してほしいなぁ。

  • Nexus 7のアルミカバー兼キーボード
  • ポケモンタイピングDSに付属のポケモンキーボード★
  • サーバー感あふれるレーザー投射タイプのキーボード
スタンドはとりあえず買ってみた2つです。 EmacsチックなAndroidのエディタで比較したのはこの3つ
  • カスタムBusyboxで動作する本家Emacs
  • キーバインディングカスタマイズできるJota+
  • 斬新なUIながらもまだベータ版のKyoro Text

Nexus 7のカバーつきキーボード

【F.G.S】nexus 7 2013 専用Bluetoothワイアレスキーボード nexus 7 第二世代　キーボードnexus 7 2013 キーボード カバー シルバー シルバー+日本語取扱説明書付き USキーボード配列
【F.G.S】nexus 7 2013 専用Bluetoothワイアレスキーボード nexus 7 第二世代　キーボードnexus 7 2013 キーボード カバー シルバー シルバー+日本語取扱説明書付き USキーボード配列 [エレクトロニクス]
お店によっては結構高いんですが、ちゃんと選ぶと2980円で買えちゃうし、ネットで見てたらレビューの評価も良さそうだったので買ってみました。スタンドにもなるしキーボードにもなるし、カバーにもなるしで一石三丁みたいな感じでよさげだったんですが、かなりイマイチ。 (今日見たらその店は2850円になってた。1980円から9000円ぐらいと同じ商品なのに値段の開きが随分あるので注意して購入してみてください。)

a1 (Custom)
Nexus 7にぴったりのカバーで質感もNexus 7の背面とそっくり。
a2 (Custom)
外すとこんな感じ。
a3 (Custom)
キーボードの上に溝があってタブレットスタンドにすることもできます。一見決まってるように見えます。
a4
キートップはこんな感じ。

  • ESCが無く、Altが右側だけでEmacsを使うには辛い
  • 入力方法がよくわからないキーがある。"+", "-", "|" とか。
  • 記号入力が結構ないかも
  • 逆にボリュームコントロールとかAndroidのソフトボタン相当はありこれは余計
  • キーピッチはかなり狭いのだが、キーストロークが意外に深くてとても打ちにくい
  • カバーを兼ねているのでキートップがアルミの外の縁よりも窪んだところにあり縁に手が当たって不快
  • アルミだし、Bluetoothのためのバッテリーもあって重め
というわけで、かなりイマイチ。プログラムを書いたりする人には向かないかもしれません。

ポケモンキーボード

中華パッドで使えるかと思って購入し繋がらず、iPhoneにも不要だったので、ずっと眠ってたポケモンキーボードでしたが、使ってみるとホント快適。キーピッチもキーストロークも悪くない。 1年半ぐらい前に1900円ぐらいで購入した記憶がありますが、アマゾンのタイムセールだと1400円で売っていたこともあったそうです。
b1(Custom)
キーボードの方がタブレットより若干大きいのは仕方ない。でも、とても打ちやすい。
b3
キートップはこんな感じ。必要なキーはちゃんとあると思います。無くて欲しいのはHome KeyとかPage Up/Downぐらいでしょうか。

  • 一般の人にもプログラマにも必要なキーはほとんどすべてある
  • 日本語、英語入力の切り替えも「半角・全角」でワンキーですむ。カーソルキーも助かる。
  • Emacsな人は「日本語106,109キーボード 」アプリをいれればCtrl, CapsLockを入れ換えられる
  • ポケモンキーボードの問題ではないが、iWnn IMEだとキー"「","」","\"の入力がおかしいようだ。Google日本語入力ではうまくいく
というわけで、いやー、プログラムでもテキストでもサクサク入力できてとても快適です。

レーザー投影型キーボード Magic Cube

2年前買ったっきりほっぽらかしになっていたレーザー投影型キーボード Magic Cube です。当時ブログに記事書いてました。(「サイバーなレーザー投影タイプのBlutoothキーボード「MagicCube」ユーザーレビュー」)

キーボードとしてのレビューは前と変わらないですが、レーザー投影なのでタブレットとMagic Cubeを角度つけたり離して置かなきゃならないのでイラっときますね。 本当はタブレットを置いた位置にMagic Cubeを置きたい。 いや、待てよ。Magic Cubeの上にタブレットが乗るようなタブレットスタンドを作ればいいんじゃないか？とも思いました。(いやいや、それほど手間をかけたくなるほど、入力しやすくないかw)
c1 (Custom)
キーボードがタブレット画面の正面に来ないので気持ち悪い。
c2
キートップはこんな感じ。カンマなど記号の並びがとても気持ち悪い。

アマゾンで買った777円のタブレットスタンド

とにかくデカすぎてかさばる。こりゃ、デカイiPadとか10インチクラスのタブレット向けでNexus 7にはToo Muchだよな。

iPad/タブレットPC用 携帯型折りたたみ式スタンド ( カラー：ブラック ) 【SsSlctブランド】
iPad/タブレットPC用 携帯型折りたたみ式スタンド ( カラー：ブラック ) 【SsSlctブランド】 [エレクトロニクス]

d1 (Custom)
ほら、やっぱりかなり大きい。太いし。
d2 (Custom)
上からはみだしちゃってます。安定感はありますけど、こりゃ10インチタブレット用だ。

ドンキホーテで買った398円のタブレットスタンド

う〜ん、こりゃよい。コンパクト。おススメ。
e1 (Custom)
畳めば薄い。
e2 (Custom)
こんな感じで開いて
e3 (Custom)
うむ、完璧だ。安いし。

Emacs (for Android by zielmicha)

zielmichaさんのEmacsはカスタムのBusyBox上で動かしている本家GNU Emacsみたいだ。 ただ、外付けキーボードだ記号などうまく入力できず、日本語の入力もできないみたいだ。 頑張るには道のりが遠すぎて心が折れてしまった。

Jota+(イオタプラス)

Jota+(イオタプラス)は標準的な機能はきちんと網羅したテキストエディタだが、キーバインディングがカスタマイズできるのでEmacs風な編集ができる。CapsLockとCtrlを入れ替えればEmacsな人は快適にタイピングできると思う。

Kyoro Text

Kyoro Text (Mega Byte)は、UI表示が凝った標準的でないEmacs風キーバインディングのテキストエディタ＆ビューアなんですが、完全にアルファ版の域を出てない感じでとても使いにくいです。

日本語キーボード106/109キーボードレイアウト

日本語106/109キーボードレイアウトは外付けの日本語キーボードのレイアウトを追加するアドオンだそうだ。 CtrlとCapsLockを入れ替えたバージョンも利用できるのでEmacsな方には重宝すると思う。

おわりに

e3 (Custom)
とりあえずは、ストレスあまりなくキーボード入力できる環境がととのってよかったです。 若干かさばるのさえ気にしなければ、それほど重くないしいいかなと思います。

今晩はこの辺で

タグ ：
#Android
#Nexus
#Nexus7
#Nexus7-2003
#キーボード
#Bluetooth
#タブレットスタンド
#Emacs
#テキスト入力
  • kjurk_urushima
  • コメント( 0 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
2012年10月24日22:00
カテゴリ
Android
ルート認証局リスト

(小ネタ)Root CA Viewer Lite for Android(Free)の公開

JCE Provider Checkerに引き続き、 Android 4.0以降のルート証明書ストアを表示させるための ツール"Root CA Viewer Lite (for Android)"という無料アプリを 昨日公開しました。
bana_google_play
rootcaview1

標準機能でもルート証明書ストアは見られるんですが、 国名、組織名、部署名といった証明書の識別名の一部と 有効期間、フィンガープリントぐらいしか見られないんですよね。 「それじゃあ証明書の特定はフィンガープリントでしか できないだろー!!!」みたいな••• いくつ証明書が入っているのかも地味に数えないとわからないし•••

とりあえずJavaのX509Certificateクラスをベースに 証明書の基本領域、拡張領域など 取得可能なものは表示できるようにしました。

識別名は文字列で処理してんるんですが、 emailAddressやserialNumberなどのマイナーな属性の相対識別名が OID.1.2.840.113549.1.9.1=#1615616161... みたいな表現になっちゃってた やつを文字列処理で "E=hoge@hoge.com"みたいに見やすいように変換しています。

このツールの残念なのは、 Javaの標準機能だけだとサポートしてない拡張領域の解析が面倒臭くて やってないのと、 楕円の証明書の鍵長が取得できないんですよね。 拡張領域の並び順もわかんなくなっちゃうし、、、 その辺りはちょっとプログラムサイズの大きい無料の PRO版出すかなと思っているので乞うご期待ってことで、、、

クリティカルフラグの表示が"[!]"はクリティカル、"[-]"はノンクリティカルとか ダサ過ぎるのと、基本領域を表すListViewの要素が"*** BASIC FIELD ***" って ダサ過ぎるので、このあたりは色づけしたりアイコンつけたり何とかしたいと思ってます。 (時間があればorz) しっかし、JCE Provider CheckerもRoot CA Viewerも同じようなListViewの 見てくれで芸が無いっすねぇorz。

またDigiNotarと似たような事件とか勃発して「おーい、 どのルート証明書を無効にしていいのかよくわかんないよー」とか いうときに思い出して活用していただければと思います。

ではでは

タグ ：
#ルート認証局リスト
#トラストアンカ
#ルート証明書
#Android
#RootCAViewerLite
  • kjurk_urushima
  • コメント( 3 )
  • トラックバック( 0 )
  • このエントリーをはてなブックマークに追加
記事一覧(手作り)
カテゴリ | 酒 | 食 | 出張・旅行 | XAdES | SSL証明書 | OpenSSL | タイムスタンプ | コード署名 |
はてなブックマーク
された記事
最新記事
Mozilla FirefoxのCRLiteで遊ぶ (moz_crlite_queryの話)
(小ネタ)サンフランシスコに行った時のSIM(Lycammobile)の話(2018年7月版)
Google Open Source Peer Bonus Award受賞しちゃいました
jsrsasignの寄付金を募ることにしてみました(やりがいって何だっけ？)
最近の証明書の話題(3): デジタル証明書形式の電子委任状のプロファイルに関する考察
最近の証明書の話題(2): CloudFlare DNS 1.1.1.1サイトのIPv6証明書
最近の証明書の話題(1) 韓国政府PKIのマズいワイルドカード証明書発行
(小ネタ) Chrome 60で証明書を表示させるフラグ設定
GmailアカウントでS/MIME 署名/暗号メールを使う(その1 iOS標準メーラー編)
Amazon AWSの認証局が少し怪しい件
追悼 Adobe CDS
HPKP(HTTP Public Key Pinning)公開鍵ピニングについて考える
X.509証明書の識別名などで使われるMulti-valued RDNとjsrsasignのサポートについて
バルセロナでプリペイドSIMの購入(2016年11月版)
ヨーロッパでPokemon Goに最適？なSIMフリースマホ
SSL Pulseの統計情報でみるSSL/TLSの引越しについて
SSL Pulseの統計情報で見るSSL/TLS (2015年12月版)
(小ネタ)Let's Encryptベータ証明書発行記念！11/5までの本番環境の証明書発行推移
SSL Pulseの統計情報で見るSSL/TLS (2015年10月版)
Deep Inside Certificate Transparency (その1)
(小ネタ)ソニーSENのChromeの警告
(小ネタ)スマホでS/MIME署名・暗号メール使うならdocomoはおやめなさい
Certificate TransparencyでわかったというThawteによるgoogle.com証明書の不正発行？？？
SSL Pulseの統計情報で見るSSL/TLS (2015年8月版)
SSL Pulseの統計情報で見るSSL/TLS (2015年6月版)
CRYPTREC/IPA「SSL/TLS暗号設定ガイドライン」の公開と非公式設定ファイル生成ツールの公開
SSL Pulseの統計情報で見るSSL/TLS (2015年5月版)
Windows信頼するルート認証機関コンプへの道(第一回)
「RFC 7525 TLSとDTLSの安全な利用に関する推奨事項」の公開
Windowsルート証明書の更新プログラム(2014.09)と戯言など
I♡S/MIME(Mac、iPhone、Outlook 2013、Office 365のS/MIME署名暗号メールの設定与太話)
ISO/IEC 18014-4 Time-stamping services - Part 4: Traceability of time sourcesの制定について
(小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件
世の中のDSAやECDSA公開鍵のサーバー証明書の利用状況
ChromeのSHA1証明書対応計画の一部延期(2015年3月12日発表)
SSL Pulseの統計情報で見るSSL/TLS (2015年3月版)
go.jpドメインのHTTPSサイトの状況について私もみてみました(2015年3月4日時点)
(小ネタ)4月10日(金)のJNSA PKI Day 2015でSSL/TLSの話をさせてもらいます
SSL Pulseの統計情報で見るSSL/TLS (2015年1月版)
W3C Web Cryptography APIとの果てしなき戦い(第3回 動くサンプル1)
W3C Web Cryptography APIとの果てしなき戦い(第2回 RSA署名生成と検証)
W3C Web Cryptography APIとの果てしなき戦い(第1回)
Chrome 39安定版のリリースと、有効期限が2017年1月以降のSHA1証明書の警告表示
Internet Week 2014パネルで話しそびれたネタ2: イントラ内でSSLサーバー設定を確認するツールsslaudit
Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS
POODLE対策としてのApache TomcatのSSL/TLSプロトコルバージョンの設定方法の調査
(続き1)POODLE攻撃について本当にTLSv1.0なら安全なのか？(OpenSSLは安全)
POODLE攻撃について本当にTLSv1.0なら安全なのか？
様々なサーバーのPOODLE SSLv3脆弱性(CVE-2014-3566)対策のまとめ(更新3)
全くスマートじゃないスマートウォッチARES EC309を買ったぜっ！
自前管理サイトリンク
自堕落な技術者のヰキ(公開版)
Favotter (@kjur)
自堕落な技術者のためのヰキ避難所(限定)
自堕落な技術者のヰキ(公開版跡地)
FriendFeed (@urushima)
Twitter (@kjur)
Twilog (@kjur)
Ourdoings (@kjur)
Flickr (@kenji-urushima)
Flickr (@kenji-urushima2)
Googleプロフィール(kenji.urushima)
セキュリティ関連リンク
ウィルス・マルウェア関連
リンク集一覧
Categories
Archives
Twitter
記事Google検索

本ブログ内をGoogle検索
Yahoo!アクセス解析
Travel Advisor

Cities I've visited.
記事検索
タグクラウド
QRコード
QRコード
  • ライブドアブログ