自堕落な技術者の日記

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

Android

バルセロナでプリペイドSIMの購入(2016年11月版)

バルセロナでプリペイドSIMを購入された、先人の方のありがたい情報を参考に、私も使ってみましたので、記録として残しておきます。よかったら参考にしてください。

土曜夜着だったので空港で購入

今回は家族でバルセロナに旅行に行きましたが、旅行中の連絡用にプリペイドSIMを2枚買おうと思っていました。土曜の午前発で夜の19:30頃空港着でしたので、街に出て探してSIMを買うというのも疲れそうで、バルセロナでは翌日の日曜は、ショッピングモール以外ほとんどの店が閉まっているらしく、空港でvodafoneのSIMを買ってしまうことにしました。


vodafone-es
(vodafone esサイトより)

いろんな記事でも紹介しているように、ルフトハンザでバルセロナ・エルプラット国際空港のターミナル1に到着し、税関を抜けるとすぐ左手にCRYSTALの看板が見えますのでそこで売っています。(ピンクの店全景, エリアマップ) 混んでいることがあるように書いていましたが、私が行った土曜の20:30頃には誰もいませんでした。紹介されていた、店に並んでるSIMを指差して「これください」ってな感じでvodafoneのプリペイドSIMを2枚を購入しました。
image

  • 60分の通話料
  • 1GBのデータ通信
  • SMSも通話料の範囲で無制限で利用可能(だけどなぜか使えなかった(後述))
  • こみこみで15ユーロ
ぶっきらぼうにSIMを渡して終わりにしようとされましたが、あらかじめiPhone SEとAndroidスマホを英語表示にしておいたので、「設定してください」とお願いし、動作確認もなくただSIMを挿すまではしてくれました。iPhone SE用のnano SIMだと追加料金を5ユーロ取られるような情報もありましたが、特に追加はありませんでした。 店の前で、自分で起動と通話の確認だけはして、2台の間で通話ができることは確認しました。

他のプリペイドSIMも幾つかあるようですが、空港ですぐ使えるという気軽さと、初期費用も少ないという事から、1週間以内の滞在ならvodafoneでいいのでは?と思います。

  • vodafone (60分通話、1GBデータ利用料込で15ユーロ) 料金は若干高めだそう
  • Movistar (10ユーロ分の利用料込で15ユーロ)
  • Orange (通話0.18ユーロ/分、1GBデータ利用料込で10ユーロ)
  • Orange Tu Mundo (14ユーロ分の利用料込で28ユーロ)

とりあえずパッケージとSIMとメモっておく事


q1small
パッケージの表面はこんなの。
q2
縦横比がおかしいですが、裏面の「N. Tel.」の所にSIMの電話番号が書いてあります。スペインでは61で始まる9桁の番号(61xxxxxxx)です。下で拡大しましょう。
q3
SIMカードのサイズは、通常SIM、Micro SIM、Nano SIMのサイズに切り取って使えます。古い情報サイトにはnano SIMだと追加料金を取るようなことを書いているところもありましたが、特に追加料金は必要ありませんでした。ここで、「PIN」の4桁の数字はSIMロックの解除PINコードで、ケータイ再起動のたびに入力が必要ですので書き取っておきます。また、「PUK」はSIMロック解除コードを4回以上間違えた場合の解除コードですので、これも書き取っておきます。
q5
メモを取っておくべき数字をまとめておくと

  • Tel. - 電話番号(61xxxxxxx 9桁)
  • PIN - SIMロック解除PIN(xxxx 4桁)
  • PUK(Personal Unblocking Key) - PINロック解除コード(xxxxxxxx 8桁) 通常は不要
購入したvodafoneのSIMは多分、帰りに経由するドイツでも(日本でも?)使えるように思いますが、SIMロック解除PINを記録するのを忘れてしまったために、ドイツで試すことができなかったです。写メにも取っておくとさらに良いように思います。中には別のカードも入っています。Google大先生に聞いて調べてみて、ざっくり意訳するとこんな感じ:
q4

Esta tarjeta va protegida con dos codigos que encontraras impresos en tu tarjeta: Codigo PIN, que debes marcar una vez introducida en tu dispositivo y cada vez que lo enciendas. Y un codigo de desbloqueo PUK, que deberas marcar, unicamente, en caso de bloqueo del codigo PIN. En caso de perdida, puedes consultarlos en vodafone.es/pin o llamando gratis al 1150 desde cualquier operador nacional. Para tu seguridad, te recomendamos cambiar el codigo PIN por uno nuevo que te sea mas facil de recordar.

このSIMカードはここに印刷されている2つのコードで保護されています。 PINコード、これは、一度使用したデバイスで電源を入れる度にコード入力する必要があります。 PUKロック解除コードはPINコード(の入力誤りで)ロックされた場合に入力する必要があります。 失敗した場合には、フリーダイアルで1150により いずれかの国のオペレータに問い合わせるか、 vodafone.es/pinで確認することができます。 セキュリティ向上のため、覚えやすい新しいPINに変更することをお勧めします。

iPhone SEのデータ通信で早速ハマる

今回の旅行では、SIMフリーで接続する用に次の2台を持ってきました。(iPhone SEの選定については別の機会に)

  • iPhone SE (SIMフリー)
  • Polaroid Pigu 3G (SIMフリー)
Polaroid Piguについては難なくデータ通信でき、Google Mapも使えたのですが、iPhone SEの方がどうもデータ通信ができません。また、SMSも両方送ることができません。ホテルまでの移動のタクシーでいろいろ設定を見てみましたが、途中であきらめホテルでWifi繋いでゆっくり調べることにしました。

iPhone SEのデータ通信

落ち着いてAPN設定など見てみると日本で設定確認のためにインストールしたiijmio用の「IIJmio モバイルサービス APN設定プロファイル」が悪さをしていたようで、iijmioのAPN設定が使われているようでした。手動でvodafone ESのものに変更し無事データ通信もできるようになりました。APN設定はiPhoneSEとPiguとで、ネットで探した別の設定をしていたようですが、どちらも問題なく繋げていたようです。[参考1][参考2]

iPhoneSEPigu
オペレータvodafone ESvodafone ES
APNap.vodafone.esairtelwap.es
Uservodafonewap@wap
Passvodafonewap125

どちらもSMSはできず

データ通信には成功し、とりあえずの旅行での連絡や調べ物やメールは無事できるようになったんですが、結局、iPhone SEでもPiguでもSMSができるようにはなりませんでした。SMSは通話に含まれるとかいてあったので問題無いはずなのですが、結局できるようにならなかったのは謎のままです。ご存知の方は、教えていただけるとうれしいです。送信失敗したエラーメッセージとして次のSMSが送られてきました。

El Mensaje Multimedia no se ha enviado a todos los destinatarios porque no dispone de suficiente saldo en su tarjeta. Recargue e intentelo de nuevo mas tarde

彼らはあなたのカードに充分な残高を持っていないため、マルチメディアメッセージがすべての受信者に送信されませんでした。リロードした後に再度お試しください。

現在の使用量も確認できず

現在の使用量はMi Vodafoneで確認するそうなのですが、結局アカウントがうまく作れず、使用量の確認までは辿りつけませんでした。また、iOS版のMi Vodafoneアプリは、日本に設定されたiTunesアカウントからはダウンロードできません。Android版は試し損ないました。

ドイツ(ミュンヘン)での利用も確認できず

このプリペイドSIMはドイツでもローミングで使えるはずなのですが、ミュンヘンで乗り換えの際使おうと思ったら、SIMロックのPINコードを書いた紙がスーツケースに入ってしまっており、また、コードの写メも取っておらず、SIMを使うことができませんでした。とほほ。

日本からのプリペイドSIMの利用

このSIMカードは普通にローミングでつなぐことができそうな雰囲気でアンテナも立ちます。日本でつなぐと以下のようなSMSが送られてきました。

VF info: Bienvenido a Japon. Llama a Espana y recibe llamadas por 3,03E/min + 1,69E de establecimiento. Envia SMS a 1,21E. MMS a 3,03E y recibelos por 2,42E. Precios con IVA.+info: vodafone.es

ボーダフォンより:日本へようこそ。スペインには、通話3.03ユーロ/分+接続1.69ユーロが必要です。1.21ユーロでSMSが送信できます。MMS送信は3.03ユーロ、受信は2.42ユーロかかります。費用には付加価値税が含まれます。: vodafone.es

その他のSMSメッセージ

その他、ちょいちょいSMSメッセージが(送ることはできないのに)送られてきており、旅行中は忙しいし、パソコンも持っていかなかったので、いちいち調べる気もしなかったんですが、日本に戻って落ち着いたので、参考まで意訳してみました。

VFInfo:!Bienvenido a Vodafone!Gracias por confiar en nosotros,estamos a tu disposicion en www.vodafone.es,marcando gratis *123# tecla llamada y tienda Vodafone.

ボーダフォンへようこそ!ご利用ありがとうございます、無料のダイヤル* 123#や、ボーダフォンストア www.vodafone.es でご自由にお使いいただけます???

VF Info Tarifa: Ya tienes 1,5GB y 60min llamadas a Espana o Internacionales a paises dentro de beneficio hasta 10/12/2016. +info: m.vodafone.es o *565#

すでにスペインで2016年12月10日まで対象国の国際電話に60分とデータ通信1.5ギガバイトがご利用になれます。m.vodafone.esまたは* 565#にお問い合わせください。

VF Info: Personaliza el mensaje de bienvenida de tu contestador gratis en el 2211xx. Tu clave de acceso es 8xxx, si quieres cambiarla llama gratis al 2211xx

留守番電話のウェルカムメッセージを変更したい場合、無料通話で2211xxにおかけください。あなたのパスワードは8xxxです。

61712xxxx ha hecho 1 llamada el dia 12/11/2016 a las 22:55 h. Pulsa para devolver la llamada.

電話番号61712xxxxより、2016年11月12日 22:55にお電話がありました。おかけになる場合には<呼出>ボタンを押してください。

参考にした記事

以下の記事を参考にしてSIMを購入できました。ありがとうございました。

ヨーロッパでPokemon Goに最適?なSIMフリースマホ

いろいろな訳あって、バルセロナに家族旅行したのですが、家族内での連絡用にプリペイドSIMを使ってみたいなと思いました。ついでにPokemon GOでヨーロッパでしか捕まらないというバリヤードをゲットしたいな、、、と。

家にはSIMフリーとして、

  • Nexus 7 2003 (LTE)
  • Polaroid Pigu (3G)
があったんですが、NexusはPokemon GOがインストールすらできないし、持ち運ぶにはデカイので、何か安い Android スマホを買うかなと安易に思っていました。

欧州でLTE使いたければ対応バンドに注意

欧州のキャリアのLTEのバンドは3、7、20が多く、これら3つをサポートしている予備機のSIMフリースマホ(でPokemon GOができるもの(^^;)が欲しいわけで、国内では別途メインで使っているやつがあるのでなるべく値段は抑えたいわけです。

ところが、格安SIMフリースマホはこの記事をよく読むとPokemon GOには向いてなさそうで、黙ってiPhoneを使っとけみたいな話になっています。また、格安SIMフリースマホは欧州の3、7、20の3つに対応しているものは少なく、Androidでは7万以上の高級機でないとサポートしていないようです。

そう考えると、iPhone SEはお得度が高く、SIMフリーで、欧州LTEバンドにも対応して、Pokemon GOの使用も問題がなく、コンパクトで旅行用のスマホとしては最適という気がして結局コレを買ってしまいました。2016年9月にiPhone SEは1万円ぐらい値下げされ、16GBモデル44,800円、64GBモデル49,800円ととてもお得になっています。大した価格差じゃないので64GBが良さそうですね。日本で販売されるモデルはA1723ですが、LTE対応バンドが非常に多いので海外利用で安心感あります。

欧州LTEバンドの対応状況を関係しそうなものだけざっと調べてみました。

製品モデル概算価格対応バンド数B3B7B20
iPhone SE A1723(北米日本) 64GB49,80019
Nexus 7 2013 LTE北米日本版7××
Nexus 7 2013 LTE欧州版7×
Nexus 5X5万
Nexus 6P 64GB8万
Xperia XZ7.6万20
ZenFone 2 Laser ZE601KL13××
ZenFone 2 Laser ZE500KL9××
ZenFone Max 16GB2.6万9××
ZenFone Zoom 64GB5.5万16×
FREETEL Priori 3S 16GB1.6万5×
FREETEL SAMURAI REI 32GB2.1万6

というわけで、予定よりもちょっと高くつきましたが、無事バリヤードも3匹ゲットできてiPhone SEにして非常に満足しています(^^;
image

バルセロナのプリペイドSIM購入については、近々なんか書きます。

Windowsルート証明書の更新プログラム(2014.09)と戯言など

随分昔の話になりますが、 2014年9月に現時点で最新のWindowsルート証明書プログラムのリストが公開されており、今日は久々にこれを見ていこうと思います。

数年前、Windowsルート証明書の更新プログラムで登録されているルート認証機関にどんな変更があったのか、調査をしてブログで公開していた時期がありました。その時はWindows XPの時代で、登録されているルート認証機関はすべて表示されるようになっていたので、ルート証明書を全部取り出すプログラムを書いて、前回との差分を比較していただけだったので、比較的簡単に調査ができたわけです。

ところが、Windows 7以降、Windowsのルート証明書は、最初からすべて登録されるわけではなくなってしまいました。ちゃんと調べたわけではないので、わからないのですが、確かOSインストール直後は15〜25ぐらいの主要なルート認証機関しか登録、ならびに表示されておらず、表示されていないルート認証局のサイトにアクセスした場合に、動的に登録されたルート証明書が追加されるような仕組みに変更になりました。

Windows 7以降のルート認証局リストの仕組みの問題点

Windows 7より導入されたルート認証局リストの配布方式は、個人的に「スッキリしない」というか「嫌だなぁ」と思っています。理由はこんなところです。

  • ルート認証局のリストはPDFの文書として公開されているが、維持組織、国、認証局名、鍵アルゴリズム、鍵長、ルート証明書ハッシュ値(拇印)しか公開されておらず、識別名や証明書の内容はわからないままである。中には、初期状態で表示されない RSA 1000bitのルート証明書が残っていたりする。
  • 初期状態では20程度の認証局しか表示されておらず、利用者がどの認証局を信頼していることになっているのか、これを知る方法が上のリストのみで十分でない。
  • 例えば、ある小国の認証局を全世界の人が信頼する必要があるとは思えない。不正発行などの事故を起こした場合に、信頼していないほうが良かったという事もあるだろう。そのような時に、自分が信頼している認証局がどこであるのかを把握できないのは問題だ。
  • Windows 7以降のシステムが認めたルート認証局は削除したとしても、再度アクセスする際に復活してしまう。ユーザは余計な認証局を利用停止や無効化することができない。
  • つまる所、最初からルート認証局リストが明示されず、後出しジャンケンのようにルート認証局が接続時に追加されるのは如何なものだろうか。
もちろんモバイル向けに初期配布のルート認証局は小さくしたいというのも、わかる気はしますが、どうせ400程度ですから、大したデータ量でもないので、最初から登録してあったほうが潔いと思います。

2014年9月版 Windowsルート証明書の更新

2014年9月のWindowsルート証明書の更新では、411のルート証明書が登録されています。

国別で見てみると、52ヶ国のルート証明書が登録されており、内訳は多い順に以下のようになっています。やっぱり、米国、スペインは多いですね。意外に少ないなぁと思うのが英国、オーストラリアです。
country

次にルート証明書の公開鍵アルゴリズムと鍵長についても見てみましょう。
keylen
RSA 2048bitがやはり多いですが、 RSA 4096bit、楕円曲線暗号のECC NIST P-384曲線もかなり増えています。 Comodo、 DigiCert、 Entrust、 GlobalSign、 Symantec、 Trend Microが楕円のルート証明書を持っています。そういえば、 Microsoftから発行されているリストには SHA1かSHA2かの情報って無いんですよね。残念だなぁ。やっぱり、ルート証明書そのものをダウンロードできるようにしてほしいなぁ。 Appleも、最初はルート証明書の詳しい情報を出していたんですが、最近はMicrosoftに習って、詳しい情報出すの止めちゃったんですよね〜〜。寂しい話です。

ルート証明書数の推移

Windows系、Android、Mac OS X、iOSでデフォルトのルート証明書の数がどう増えていったのかグラフにしてみました。Apple製品は公式サイトの情報から取得しています。Androidについては拙作のRoot CA Viewer Liteか過去の他作業を元に調べています。
osroot
iOSはiOS3以降、メジャーバージョン毎にルート証明書リストが公開されているのですが、Mac OS Xについては新しいMavericksとYosemiteしか情報がありませんでした。 Apple iOSについては、ルートの数が乱高下していて、なんか掲載ポリシーが定まってない感じなんですかね? 本当はMozillaやJavaについても調べてみたかったんですが、これは今後の課題ということで、、、(^^;

Windowsルート証明書のリストを調べる地道な作業 (泣)

以前は、自前のツールを使えば簡単にルート証明書を抽出できたので、今回のような情報を比較的簡単に調査することができたんですが、 Windows 7以降、そうした事もできなくなってしまいました。で、今回はというと、こんな地味な手順を踏んで調査したんです(泣)。Microsoftの中の人ならリストのエクセルファイルとか、ルート証明書そのものを持っていて簡単に調査できるんでしょうけどねぇ、、、トホホ。

  1. 公開されているPDFファイル「 Windows Root Certificate Program Members - September 2014」からCERTIFICATES IN DISTRIBUTION FROM ALL MEMBER CAsの表を各ページ、テキストでコピペする。
  2. Emacsのテキスト編集で何とか、TSV(タブ区切り)ファイルにする。
  3. Macのテキストエディタで開きUTF-16で保存する。
  4. MacのExcelでインポートする。
  5. インポートした時点で、カラム位置のズレや文字化けがあるので手作業で修正。
  6. ルート証明書リストのExcelが完成!!! (泣)
  7. ちゃんとしたエクセル表なので、フィルタ使って調べたり、簡単なスクリプト書いて集計 したりできる。

さらなる野望

家族から「リビングにファンが煩いマシンを置くな!」と非難され、泣く泣くファンレスの超小型マシンDiginnos LIVAをサーバー代わりに使っているんですが、ブラウザで変なサイトに行くこともあまりないので、ルート認証局のリストは27で、初期出荷時からあまり増えていないはずで、今回、試しに開いて、イタリアのActalis Authentication CA G1が増えてしまいました。
windialog
なんかこう、 あれです、411もあるわけですから、フルコンプしたいですよねぇ? 先生、大事なことだからもう一回言います。

フルコンプしたいですよねぇ?!!!
これをフルコンプするには、 411の全ての認証局それぞれに、そこから発行されたどれか一つのSSLサーバー証明書を使っているサイト見つけて、Internet ExplorerでHTTPSアクセスすればいいだけですが、マイナーな認証局から発行された証明書を使っているサイトを見つけるなんて、海水浴行った海岸のどこかで落とした10円玉見つけるようなもんで、ほとんど無理ですよね。 例えば、Symantecなんかは色んな認証局を買ったので、グループだけで70もの認証局が登録されているわけですが、Symantecにそれぞれの認証局から発行された証明書のすべてを見つけるなんて、もう無理です。

こういう時ですねぇ、Certificate Transparencyの公開監査ログを手元に持っているとですねぇ、740万枚ぐらいのサーバー証明書と、そのルート認証局までのチェーンがあるので、それぞれのルート証明書を取り出して、Windowsルート証明書情報のPDFに記載された証明書の拇印ハッシュ値とを比較すれば、そこから発行されたSSLサーバー証明書が一つみつかるので、そこへアクセスすれば前述の「証明書ダイアログ」に表示されるのではないかと!!!(パチパチ)

ゴールデンウィーク中に、ちょっとGo言語でこんなツールを作ろうかなぁ、、、と思ってます。

おわりに

いや〜、オレのゴールデンウィークは有意義だなぁ、、、 (遠い目 ) こんなことばかりしているとカミさんに怒られるので、今日はこのへんで。

追記(2015.05.03 13:28)

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね?と某木村大先生からご指摘いただきました。確かにそのとおりでした。(つ〜か、前にツール使ってそれができてたものが、参照情報しか取れなくなったと勘違いしてできなくなって、そのままにしてたんですが 、指摘を頂いてから見てみたらちゃんとありました。) その実行ファイルには、証明書のリストである .SST (Microsoft Serialized Certificate Files)が入っており、その中からルート証明書が取り出せそうです。前は作ったツール使ってたんですが、今は PowerShell から取り出せそう。試したらまた報告します。ルート証明書が抜けたとして、ただ開いただけで、「信頼するルート認証機関」のリストに表示されるんかいな???

関連記事

ちょっと遠い関連記事

全くスマートじゃないスマートウォッチARES EC309を買ったぜっ!

いや〜〜っ、誕生日も近かったんで、気の迷いですかねぇ。Android WearでもApple Watchでもない、SIM対応のフルAndroidのスマートウォッチARES EC309を買ってしまいました。ゲットしてから随分経ったので、まだ使い込んでない部分もあるんですが、そろそろレポしたいと思います。
ec_021full

元々は米国などで2013年12月頃からgoophone EC309という名前で出ていた中華系のスマートウォッチを ARESさんが日本で使えるように技適マークなど取得したのがARES EC309みたいです。

そもそも何故Android WearやApple iWatchじゃ自分にはダメなのか

Android Wear対応のお洒落なやつが Motorolaから出てたりApple Watchも出ようと したりしてるわけですが、自分には今ひとつピンとこないわけです。こいつらって、 ネットワークに繋がるiPhoneやAndroidと繋がって何かするものじゃないですか。 それに何でもできるわけじゃない。

  • 別に脈拍やら健康状態やらを腕時計で管理して欲しいわけじゃない。
  • こうしたガジェットをつけてランニングしたりする趣味も無い。 むしろ泳ぐ方が好きなので、こうしたガジェットは全く役に立たない。
  • 単体で動作してくれないデバイスなど、両方の電池切れの心配を しなきゃいけないから面倒臭い。
  • これで動くアプリを手軽に作って試してみたい。
  • 使えそうなアプリもそんなになさそう。
というわけで、結構悩んだ挙げ句、自分にはAndroid WearやApple Watchは必要ない事が よくわかったわけです。

で、ぽちったらやって来たわけだ

この手のAndroidスマートウォッチは他にもあるそうなんですが、この件に関しては海外サイトで購入とかそういう面倒臭いのはいやだったので、日本で買えてサポートもしてくれそうなやつというとARES EC309ぐらいしか無い事がわかり、誕生日も近かったので自分への誕プレかなと、8月末頃ぽちっとなしてしてしまいました。9月末ごろ発送だというので気長に待ってたら秋分の日あたりに到着しました。
IMG_3081 IMG_3082 IMG_3103
IMG_3083 IMG_3084 IMG_3086
私は腕が細いので少し大きめ、厚めに見えますが、まぁ、 ファッションウォッチにもこれくらいのあるだろうし我慢できるサイズで、 重さもむしろ見た目より軽いくらいでつけ心地は悪くないです。 Windows 8風のランチャーがデフォルトで入っています。

時計の文字盤パターンはたった3種類でどれもイケてなくPebbleのようにはいかないみたいです。まぁ、時計としてあんまり使わないからいいかw Windows 8風のランチャーの時計で十分な気もします。

で、無線LANに繋ごうとして辛くて涙出る

まぁ、スマートウォッチなもんで、ネットに繋がないと意味がないわけですが、そのためには、 まず、家のWiFiに繋ぐ必要があります。SSIDとWPAキーを入力する必要がありますが、 これが泣きそうに面倒臭い。一応フリック入力なんですが、こんなもん小さすぎて入れられるか〜〜〜っ!!!何度も打ち間違えをし、途中で入力キャンセルされたり、間違っていたり、入力になれていないせいもあり、かなりの時間格闘しながら、ようやく家のWiFi接続できました。特に打ち間違えた際に使うDELETEキーがあるんですが、画面の右下自体がAndroidのバックボタンとかぶっているために、文字削除しようとすると、前の画面に戻っちゃって苦労したわけです。
ec_001wifi

次にようやくアプリの追加で

AndroidではGoogleアカウントを入力しないと、Google Playでアプリの追加もできないし、メールも読めません。ウチの場合は、無線LANのアカウントよりもGoogleのアカウントの方が入力が面倒臭いものになっていたので、そこでも最初に苦労しました。イライラしすぎて、その晩はあきらめ、寝てしまい、翌日100円ショップなどでスマホ入力用のタッチペンなど買うかなぁと思ってたんですが、何日か忘れてしまい、結局気合いでGoogleアカウントを登録でき、ようやくアプリのダウンロードができるようになりました。どうです?画面かなりちっちゃいでしょ?
ec_002gplay

で、最初はアプリを追加してみるも動かず

Google Playのサイトで「Smart Watch」で検索してみると、Smart Watchのような小さな画面でも動くアプリがいっぱい紹介されており、「これらなら、画面が小さいヤツでもイケるだろ」と

  • 雨雲レーダー for SmartWatch
  • 乗換案内 for SmartWatch2
などのSmart Watch用アプリをインストールしてみたんですが、こんな感じでインストールしたものがアプリ一覧にも表示される、Google Playサイトからのアプリ起動もできなかったのです。通常はインストールしたら「開く」ボタンが出るはずなんですが、下のように「アンインストール」のボタンしか出てこないんです。
ec_003noring

で、早速アプリがどれもインストールできないとサポートに問合せ

2つ入れてみたスマートフォン用らしいアプリがどちらも動かなかったので、こりゃメモリカード関係の故障か、アプリのインストール先の設定が間違っているんじゃないかと、自分で解決できそうになかったのでARESさんのサポートにメールしてみました。1、2日後にはお返事を頂けるのでとても有り難いと思いました。

で、回答は要約すると、

画面が小さいため全てのアプリが動くわけではなく、全てのアプリの 検証をやっているわけではないです。産経アプリスタさんのサイトにレビュー 「衝撃の”腕時計型スマホ”を使ってみた!LINEもTwitter も使えるぞ」もご覧ください。
みたいな回答を頂いた。フムフム、このサイトを観てみると、LINEやTwitterは動くが、Facebookは小さすぎてだめだと。早速LINEとTwitterは入れてみようと・・・
ec_004twitter ec_005line
おお、マジかよ。ちゃんとインストールしたアプリ動いたよ。ARESさん、疑ってごめんよ。 このあといろいろインストールしてみたんだけど、「SmartWatch」と名のつくアプリは 逆にEC309では動作しないことがよくわかりましたorz このLINEには誰も友達がいなくて寂しいorz

で、次にはいよいよSIMだぁっっ!!

ARES EC309の醍醐味はSIMカードをさす事ができるフツーのAndroidであることです。外出先でも使えないと意味ないじゃないですか。NEXUS 7に挿してあったIIJmioのカードを挿してみたのですが、何とも認識してくれずエラーが出ちゃいます。こちらもまた、ARESさんのサポートに問合せさせて頂いたところ、APNが設定されていないのでは?との事で以下のサポートページをご紹介いただきました。

ガイドに従って、IIJmioのサイトにあるAPN設定をしてみたんですが、繋がらず、ARESさんの紹介頂いたサポートページをよく読んでみると「Docomo製のスマホ以外はSMS対応でないと、「アンテナピクト・セルスタンバイ」問題が発生し、使えないとの情報があります」と書いてあります。あらら、まさにそれだ。私のSIMはデータ専用でSMS対応ではなかったのです。IIJmioのサイトでSIM交換の依頼を出しました。数日後新しいSMS対応のSIMが送られてきて、古いSIMは返却しました。で、挿してみるとちゃんと繋がりました。よかったよ〜〜〜〜。

で、SIMやらWiFiやら使ってみるとよくわかるんですが、本体が結構熱くなって電池もぐんぐん減っていきます。通信が必要ない時にはマメに機内モードにしておくといいみたいです。機内モードにしておけば、充電は2、3日ぐらいは持つみたいです。
ec_006kinaimode

で、必要なアプリをいろいろ入れては試してみる(その1 AirDroid)

AirDroidは、AndroidとPCを無線等でつなげて操作できるようにするアプリで例えば以下のような事で助かったりします。

  • クリップボードの変更(これはEC309で文字入力面倒なのでとても助かる。面倒なパスワードとかもこれで送ってしまう。)
  • Androidのデスクトップのキャプチャ(このブログで使った)
  • ファイルの送受信
  • アプリの削除、インストール。特に自作アプリをGoogle Playにアップしなくても、USB接続してコマンド打ったりしなくてもインストールできるのは有り難い。
EC309側でAirDroid起動して、表示されているURL(例 http://192.168.1.2:8888)にPCからブラウザで接続すると以下のような画面が表示されて、PCのウェブブラウザからEC309をいろいろ操作できます。とりあえず入れておくといいと思います。
ec_007airdroid

で、必要なアプリをいろいろ入れては試してみる(その2、その他諸々)

その他にもとりあえずでこんなアプリを入れ重宝しています。ポイントとして↓な感じでしょうか。

  • Yahoo Japanのアプリは概ね極小画面にも対応しておりとても操作しやすいからおすすめ
  • for SmartWatchと名前がついたものは概ね動かない

ec_008taskkill Androidで不要なタスクを終了してメモリを空けたり、軽くしたりする定番アプリ「Advance Task Killer」これが無いと電池が持ちません。
ec_009googlemap Googleマップも小画面でも問題なく操作できます。外出先で結構便利。
ec_011miopon2 IIJmioのSIMカードを使っていますが、利用上限のあるLTEの利用は控えたいとか設定するときに 必須のツールです。問題なく動作します。
ec_012ynorikae これも便利。「Yahoo! 乗換案内」です。問題なく動作します。
ec_013ytenki 「Yahoo! 天気」はYahooの中ではちょっとこれは例外的にキツイかな。アメダスを観るのはちょっと難しい。天気は問題なく出ます。
ec_014googlekeep2 「Google Keep」はGoogle Driveを使ったPost It風のクラウドメモ帳です。PCとかとテキストの共有をするときに便利だと思います。問題なく動作します。
ec_015torikago 「トリカゴメモ」はローカルに保存できるメモ帳アプリです。パスワードなど打ち間違えると面倒なので、あまりセキュアな方法ではないですが、ここで入力をして値を確認してから、ペーストして使ったりします。
ec_016flickwnn EC309の製品出荷時には日本語入力は含まれていません。OpenWnn系かATOKが動作するそうです。試しに「Flick Wnn」を入れてみました。入力フィールドは潰れ気味ですが、何とか日本語の入力はできます。 キーが半透明になるプラグインがあるそうなので、それを入れると良い事があるかもしれません。

むむっ、Google音声認識・検索が使えないぞ

小さなキーボードによる入力の間違いとの格闘に辟易して、音声入力で何とかならないかなと考えています。で、いろいろ音声入力系のアプリを入れてみたんですが、動かないやつが多すぎ。音声入力をしようとするとアプリケーションが落ちるのです。気になって、設定等見てみると、
ec_017keyinput ec_018cfginput
どうやらAndroid 4.0からデフォルトで入っているはずのGoogle 音声入力が入っていないようなのです。 アプリケーションとしてインストールを幾つか試してみたんですが、結局入ってくれそうにありません。 これが原因で音声入力系のAndroidアプリの殆どが使えなくなってるみたいなんです。

Android 4.0.4でGoogle音声入力を後インストールする方法をご存知の方は是非教えてください。

Yahooの音声入力は使えたっぽい

Google音声入力は結局、入れ方もわからず、困ったままなんですが、「Yahoo音声アシスト」というのを入れるとSiriみたいにウェブ検索してくれたり、アプリ起動してくれたりします。認識率も良くて結構使えると思います。
ec_021yahoospeech1 ec_019yahoospeech2 ec_020yahoospeech3

で、ウルトラ警備隊のビデオシーバーになんのか?と

ウルトラセブンのウルトラ警備隊の人は腕時計型のテレビ電話システム「ビデオシーバー」を持っているんですが、 ARES EC309も、

  • これ単体で3G/LTEで通信ができる
  • 液晶ディスプレイがある
  • CCDカメラがある
と、必要な機能を全てそなえてるんだから、 ビデオシーバーとして使えるんじゃないかと期待しちゃいますよねぇ。 ところが、カメラの方向が顔向いてなくて、腕時計の横面についちゃってる んですよ。Skypeは何だかログインできなかったので、LINEテレビ電話で繋いでみました。 EC309からはビデオ通話の開始のボタンが押せなくて、相手から誘ってもらって応答はできました。
ec_020videotalk
ちょっと画伯っぽくって申し訳ないんですが、腕時計を横にして、目の前に持ち上げて自分は映り込み、相手の顔は横になっちゃってるけど、傾けた液晶から何とか見るという・・・ウルトラ警備隊とは程遠い。こんなんじゃ怪獣にすぐやられちゃいますorz

おわりに

まぁ、こんな感じでスマートウォッチARES EC309と格闘しており、2chでの書き込みも「ダメダメじゃん」みたいな風潮になっているようですが、自分としては「意外に愛い(うい)やつ、フフフフ」という感じになっています。ARES EC309で動いたアプリ、どういう不具合で動かなかったかは別館で今後もまとめていこうと思っています。

はやいところ、これ専用にアプリ作ってみたいなぁ・・・・今日はこんなところで、ではでは。

参考リンク

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 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 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 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 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 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はデータのコピペが面倒だとわかったのでこれは改善しないといけません。

最新記事
Categories
Archives
Twitter
記事Google検索

本ブログ内をGoogle検索
Yahoo!アクセス解析
Travel Advisor
記事検索
QRコード
QRコード
  • ライブドアブログ