2015-10-15

SHARPのAndroid端末で802.1X認証のWi-Fi接続を行う際の挙動を世代別にまとめてみた

SHARP製のAndroid端末で802.1X認証のWi-Fi接続を行う際に、RADIUSサーバのサーバ証明書の検証を強制されるため、これを発行した認証局（CA）のルート証明書（以下、CA証明書）の端末へのインストールが必要となる場合がある。
サーバ証明書の検証は本来、「しなければならない」(MUST)ではないはずだが、SHARPはかねてから端末に独自仕様を実装しているため、このような動き（CA証明書をインストールして、サーバ証明書の検証を行うことが必須）となっている。*1

このため、例えば認証に802.1X（多くはEAP-PEAP）を使用している国際無線LAN ローミング基盤 eduroam (http://www.eduroam.jp/) を整備している大学等では、SHARPのAndroid機の接続について、個別に注意喚起を行っている。
eduroam.jpの案内
 神戸大学の案内
 北海道大学の案内

しかし最近、SHARP製のAndroid機においても、CA証明書の端末へのインストール無しに、802.1x(EAP-PEAP)認証の無線LANへ接続できるクライアントが存在している。
このため、できるだけ多くのSHARP製Android機種を集め、挙動をまとめてみることにした。

※　個人の理解を深めることを目的としたまとめです。誤りや、用語の使い方がおかしい点などありましたらご指摘いただければ幸いです。　

10/17追記　@hgot07 先生にありがたいつっこみをいただいた。
@hgot07 ありがとうございます！何でそうなのか勉強してから修正します。他にもお気付きのことがあればつっこんでいただければ幸せです
— Hiroyuki H (@pirosap) 2015, 10月 15

ので、今更だけど勉強しなおしてみた。
EAP-PEAP と書いていたが、PEAP　は Protected Extensible Authentication Protocol　
つまり　Protected EAP なので、頭にEAP-とつけてるのは「馬から落馬」みたいな表現になるのかな？
「正しいEAP-PEAPのID、パスワードを入力しても〜」というのは、直すとすると「正しい　PEAP-MSCHAP v2のID、パスワードを入力しても〜」かな？
しばらく恥を忍んで、修正しないでおきます。
用語の使い方って大事だと思う。

■EAP-TLS　（RADIUSサーバとクライアントの相互で証明書による認証を行う）
○EAP-TLS　　　　
TLSって何 = Transport Layer Security
　　　　　　　　　　⇒　慶應義塾大学のワイヤレスネットワーク　「keiomobile2」
　　　　　　　　　　　　http://www.mita.itc.keio.ac.jp/ja/net_connect_keiomobile2.html
　　　　　　　　　　　　慶應ID（共通認証システム）を基盤として発行された証明書　をEAP-TLS認証に利用している。（2011年頃〜）

■TTLS （クライアント側は証明書を発行せず、その代わりにユーザ名とパスワードを用いて認証を行う）
TTLSって何 = Tunneled TLS
EAP-TLSの拡張版がTTLS。
サーバ側にのみ電子証明書を準備してサーバ認証済みのTLS通信路を構築し、その暗号化通信路を通してクライアントを認証する。
暗号化通信路を通るので認証プロトコル(Inner Authentication)は平文でもいい。
RFC5281 では Inner Authentication プロトコルとして PAP, CHAP, MSCHAP, MSCHAPv2 あるいは EAP が列挙されている。
TTLSのInner AuthenticationにEAPを使ったのがPEAPってこと？？
○TTLS (PAP)
PAPって何 = Password Authentication Protocol （パスワード認証）
　　　　　　　　　　⇒　OCN モバイル ONEの期間限定トライアルで提供されているWi-Fiスポット
　　　　　　　　　　　　「0001_Secured_Wifi」
　　　　　　　　　　　　https://support.ntt.com/mobile-one/faq/detail/pid23000005jw
○TTLS (MS-CHAPv2)
MS-CHAPv2って何 = Microsoft CHAP version 2
CHAPって何 = Challenge-Handshake Authentication Protocol (チャレンジ/レスポンス認証）
　　　　　　　　　　⇒　eduroam 代理認証システム　から発行されたアカウントは　この方式でも認証できた。
　　　　　　　　　　　　eduroam の技術情報　FreeRADIUS3の導入　（　http://www.eduroam.jp/docs/conf-freeradius3.html　）
　　　　　　　　　　　
■PEAP （PEAP で使用する EAP の種類（認証の種類）は、EAP-MS-CHAP v2 と EAP-TLS が選択できる）
サーバ側にのみ電子証明書を準備してサーバ認証済みのTLS通信路を構築し、その暗号化通信路を通してさらにEAP通信を行い、クライアントを認証する。
⇒　TTLSと何が違うの
　　PEAP と TTLS の違いは、暗号トンネル上のプロトコルとして TTLS が RADIUS/Diameter の枠組みを使っているのに対し、PEAP は EAP を使っている
○PEAP-MSCHAP v2
EAP-MS-CHAP v2 を使用する PEAP。
PEAP-MSCHAP v2　では、認証に証明書とユーザー名／パスワードを使用。
RADIUSサーバーがクライアントを認証する時はユーザー名／パスワードを使用。
ユーザー名／パスワードの情報は、EAP-MSCHAP v2で暗号化。
クライアントがRADIUSサーバーを認証するときは証明書を使用。
　　　　　　　　　　⇒　本検証で構築した方式。RADIUSサーバにはプライベートCAから発行した証明書を用いた。
　　　　　　　　　　⇒　世界のeduroamでは、PEAPによるID/パスワード認証方式が広く用いられている。
　　　　　　　　　　⇒　EAP-TLSの例として挙げた　慶應義塾大学のワイヤレスネットワーク　「keiomobile2」
　　　　　　　　　　　　http://www.mita.itc.keio.ac.jp/ja/net_connect_keiomobile2_peap.html
　　　　　　　　　　　　慶應ID（共通認証システム）を利用できない人、または証明書方式が利用できない機器向けに
　　　　　　　　　　　　PEAP-MSCHAP v2 でも認証できるようにしたようだ（2014/3〜）
　　　　　　　　　　　　http://www.mita.itc.keio.ac.jp/ja/feature_2013_2.html
　　　　　　　　　　⇒　NTT Docomoの公衆無線LANサービス（0001docomo）は、最近の機種ではEAP-SIM（SIMカードによる認証）に
　　　　　　　　　　　　対応しているが、PEAPも利用可能である。
　　　　　　　　　　　　https://www.nttdocomo.co.jp/binary/pdf/service/data/docomo_wifi/usage/other/windows7_auto_login.pdf
○PEAP-TLS
EAP-TLS を使用する PEAP。
https://www.fmworld.net/biz/fmv/product/hard/network/manual/security/manual/chap100009.html
PEAP-TLS　では、EAP-TLSと同様に、RADIUSサーバーとクライアントの相互で証明書による認証を行う。
PEAP-TLS　では暗号化情報がカプセル化されるため、EAP-TLSよりセキュリティレベルが高くなる。
https://technet.microsoft.com/ja-jp/library/cc754179.aspx
Active Directory 証明書サービス (AD CS) で公開キー基盤 (PKI) を展開する場合は、EAP-TLS を使用する PEAP (PEAP-TLS) を使用できます。
　　　　　　　　　　⇒　社内の無線LANとか？身の回りに環境がない。

本検証環境について

本検証では、FreeRADIUS 3.0.9に自己署名のプライベート認証局より発行したサーバ証明書を設定した上で、EAP-PEAP認証で構築した無線LAN環境で行っている（いずれもSHA-1）。
あらかじめプライベートCA証明書を、一度Windowsに読み込み（証明書ストアは「信頼されたルート証明機関」を選択）、certmgr.mscから「信頼されたルート証明機関」に配置された当該証明書を、「Base 64 encoded X.509 (.CER)」としてエクスポートし、拡張子を .crt に変更したものを用意した。
このプライベートCA証明書へのリンクを検証機からアクセス可能なWEBサーバ上に設置し、検証機からキャリア回線または802.1Xではない無線LANを使用した。
（※CA証明書を事前にPC等でカードリーダを使用してMicroSDに保存しておき、端末で読み込むことも可能であり、実際の運用では証明書の安全な配布という点からはそのような方法が推奨される。あくまで本検証はSHARPのAndroid機の挙動の調査が目的であるため、このような方法を取った。）

■そもそも、AndroidでユーザがWi-Fi用にインストールしたCA証明書はどこに保存されるのか？

インストールするCA証明書が、パブリックCAであるか、プライベートCAであるかで挙動が異なるようだ。
(Android 4.1.2、4.4.2、5.0で確認）

パブリックCA

SECOM TrustのSecurity Communication RootCA1の例
1. SECOM TrustのSecurity Communication RootCA1は、最初から「設定→ロックとセキュリティ→安全な認証情報の使用（信頼できるCA証明書を表示する）→システム」には存在する。
2. SCRoot1caをインストールしないと、警告（"正しいサーバに接続されているか検証されません〜"）が出るものの接続可。
3. SCRoot1caをインストールしていないと、802.1Xの接続設定で証明書を選択できない。
4. SCRoot1caを"SCRoot1ca"として保存しても、「安全な認証情報の使用→ユーザ」　にはインストールした証明書が表示されない。
5. 802.1Xの接続設定のCA証明書の選択プルダウンには、ユーザがつけた名前で表示される。
　（SCRoot1caを"puyo"として保存すると、プルダウンには"puyo"として表示される。）
6. インストールしたパブリックCA証明書を確認できる画面がなく、個別に削除する方法がない。
「認証ストレージの消去」で認証ストレージごと消すと802.1Xの接続設定でCA証明書を選択できなくなる。
7. 「安全な認証情報の使用→システム」に最初からインストールされているSecurity Communication RootCA1は、個別に無効にすることができるが、無効にしても802.1Xの設定からは引き続き参照できる。

Android 5.0を搭載したDocomo SC-01Fでも同様の動きをした。
念のため、SCRoot1caのインストール方法をブラウザからではなく、MicroSDにPCで保存したものを読み込む方法に変えてみたが、挙動に変化は無かった。
Nexusのヘルプには、上記のような挙動については書かれていないが、SHARP機特有の挙動、という訳ではないようだ。
Add & remove certificates - Nexus Help

System displays certificate authority (CA) certificates that are permanently installed in the ROM of your phone.
User displays any CA certificates that you have installed yourself, for example in the process of installing a client certificate.

プライベートCA

プライベートCA局（hogeCA）の例
1. 当然「安全な認証情報の使用→システム」には存在しない。
2. hogeCAをインストールしないと、警告（"正しいサーバに接続されているか検証されません〜"）が出るものの接続可。
3. hogeCAをインストールしていないと、802.1Xの接続設定で証明書を選択できない。
4. hogeCAを"hogeCA"として保存すると、「安全な認証情報の使用→ユーザ」　にインストールした証明書が表示される。
5. 802.1Xの接続設定のCA証明書の選択プルダウンには、ユーザがつけた名前で表示される。
　（hogeCAを"puyo"として保存すると、プルダウンには"puyo"として表示される。）
6. インストールした自己署名CA証明書は、「安全な認証情報の使用→ユーザ」から選択して個別に削除できるが、削除しても802.1Xの設定からは引き続きhogaCAが選択できる。
「認証ストレージの消去」認証ストレージごと消すと802.1Xの接続設定でCA証明書を選択できなくなる。

本検証の最大の疑問。どっかにWi-Fi用の認証情報ストレージ的なものが独立してある？　詳しい方がいたら教えてほしい。

検証まとめ

大まかに分けて、2.x系、4.0系〜4.2系、4.4系で挙動が異なる。SHARPのAndroid端末においては、4.4系で大きく挙動が変わったようだ。（Android的には4.3から？）
5.x系（Docomo SH-03Gなど）、6.x系（今後SH-01H等にアップデート配信予定）は未検証。

Androidバージョン	検証機の型名	検証機の発売開始日	CA証明書インストール	制限事項
2.2.2	Docomo SH-03C (Build 02.01.04)	2010/12/3	必須　(インストールにMicroSDは必須ではない）	いったん接続完了後に端末を再起動すると、自動で再接続されない。 SSIDを選択して接続を手動で行う際に「認証情報ストレージ」のパスワード入力が求められる。
2.3.5	AU IS14SH (Build 01.00.06)	2011/12/23
4.0.4	SoftBank 102SH (Build S1040)	2011/12/16 (2012/9/6 4.0.4アップデート開始)		いったん接続完了後に端末を再起動すると、自動で再接続されない。画面ロック解除後に接続状態を確認すると「認証に問題」となっている。 SSIDを選択して手動で接続を行うと再接続される。「画面のロック」が「パターン」「ロックNo.」「パスワード」のいずれかのみに制限される。「なし」「スライド」(SH-02Eは「スライドまたはタッチ」）「顔認証」は使用不可となる。
4.1.2	Docomo SH-02E*2 (Build. 02.00.06)	2012/11/29
4.2.2	Docomo SH-06E*3 (Build 01.00.10)	2013/5/24
4.4.2	Docomo SH-04F*4 (Build 01.01.08)	2014/5/23	必須ではない　 (インストールしないと初回接続時に警告表示）	CA証明書をインストールしない場合、インストールした場合のいずれにおいても接続中の状態で端末を再起動すると、画面ロック中の状態であっても自動で再接続される。 CA証明書をインストールしない場合、一旦接続が確立した状態から「切断」を実行すると、再度手動で接続を行った際にCA証明書が指定されていない旨の警告が改めて表示される。プライベートCAのCA証明書をインストールすると、通知領域に信頼できる認証情報が端末にインストールされている旨の警告が表示される。
4.4.2	AU SHL25 (Build )	2014/6/13	必須ではない　 (インストールしないと初回接続時に警告表示）

世代別の接続方法

■CA証明書の入手
CA証明書のインストールが必要な場合、そのCA証明書は所属機関が案内しているものを使用する。

例えばeduroamの場合、各機関が独自にRADIUSサーバを構築してeduroamに接続している場合は、後述のSCRoot1caおよびSCRoot2caではないCA証明書が必要な場合があるので、各々の機関の案内に従って適切なCA証明書を入手する。

※　この場合、RADIUSサーバのサーバ証明書が大学のプライベート認証局から発行されているケースと、パブリック認証局から発行されているケースがある。
例えばUPKI電子証明書発行サービス*5では、既存パブリック認証局の下位認証局 *6をNIIが構築しており、サービス利用機関は機関の登録担当者を通じてそこからサーバ証明書を発行してもらうことができる。）
今回のテーマとは違ってくるので深く触れないが、下記を一読することをお勧めする。
高木浩光＠自宅の日記 - PKIよくある勘違い(2)「安全に配布すればルート証明書を入れさせてよい」, PKIよくある勘違い(3)「プライベート認証局が妥当なら..

大学のプライベートCA
損害も社内で閉じる場合には、プライベート認証局で運用することが全く妥当となる場合がある。では、大学ではどうだろうか。

所属機関がeduroam代理認証システムを使用している場合、サーバ証明書のCN (Common Name)は tanelon3.rd.cc.tohoku.ac.jp である。
このCAは　2015/10/12時点では下記の通り　Security Communication RootCA1　である。
http://www.eduroam.jp/docs/supplicant/android/
リポジトリは下記であり、CA証明書は下記で公開されている。
https://repository.secomtrust.net/SC-Root1/

一方、所属機関が学認に参加しており、eduroam仮名アカウント発行システムを利用している場合、サーバ証明書のCN (Common Name)は upkirad1.kuins.kyoto-u.ac.jp　である。
このCAは2015/10/12時点では下記の通り　Security Communication RootCA2 である。
http://www.iimc.kyoto-u.ac.jp/ja/whatsnew/information/detail/150619053028.html
リポジトリは下記であり、CA証明書は下記で公開されている。
https://repository.secomtrust.net/SC-Root2/

Security Communication RootCA1およびSecurity Communication RootCA2のCA証明書は、多くのAndroid端末にプレインストールされているが、(SHARP製のAndroid機に限らず）システム領域にインストールされているCA証明書は、今回検証に利用した端末ではいずれも802.1X認証の無線LAN接続設定からは参照できなかった。
802.1X認証の無線LAN接続設定が参照できるのは、ユーザがWi-Fi用に謎の領域にインストールした~~ユーザ領域（認証情報ストレージ）にインストールされた~~CA証明書のみではないかと思われる。
　（SH-02Eの「システム」領域にプレインストールされているCA証明書の例）

参考：

@ahash ちょっと補足します．端末内にもとからあるWebとか用のCA証明書をEAP用に使えなくて別途インストールしないといけないのが Android の謎仕様．CA証明書設定しなくても接続できるはずのところを必須にするのがシャープによる魔改造です．
— 八槇博史　Hirofumi Yamaki (@yamaki3634) 2015, 1月 21

参考２　(2015/10/19追記）：
http://forum.xda-developers.com/aquos-crystal/help/wi-fi-issues-t2909127/page3

I figured out the network I connect to uses VeriSign Root Certificate Authority (CA) on its RADIUS server. It specifically uses the "VeriSign Class 3 Public Primary Certification Authority - G5" root CA. Android already has this as a trusted credential, but it's not working on the Sharp AQUOS Crystal for whatever reason.

いずれの場合も、リポジトリからダウンロードしたCA証明書はそのままではAndroidにインストールできないことがあるため、事前に変換が必要な場合があることに留意する。
（CA証明書を、一度Windowsに読み込み（証明書ストアは「信頼されたルート証明機関」を選択）、certmgr.mscから「信頼されたルート証明機関」に配置された当該証明書を、「Base 64 encoded X.509 (.CER)」としてエクスポートし、拡張子を .crt に変更するのが確実で簡単。）

参考：

証明書の追加と削除 - Nexus ヘルプ
 Android では、DER エンコードの X.509 証明書のうち、拡張子 .crt または .cer の付いたファイルに保存されたものをサポートしています。証明書ファイルの拡張子が .der などの場合は、.crt または .cer に変更しないとインストールできません。

同様に、各種公衆無線LANサービスにおいてもSHARPのAndroid機ではCA証明書のインストールが必要なケースがあるし、CA証明書入れてもどうもならないケースもある。
以下は、NTT Communicationsが試験提供しているWi-Fiスポットサービス　0001_Secured_Wi-Fi　の事例である。

https://sh-dev.sharp.co.jp/android/modules/d3forum/index.php?topic_id=313
ご質問頂きました件に関して弊社にて調査致しました結果、御連絡頂いた接続先のサーバー証明書に中間証明書が含まれていない為に、弊社端末SH-06Eでは証明書チェーンが辿れず接続できない状況となっている事が判りました。
本件の解決には、証明書サーバー側でサーバ証明書に<<中間CA証明書>>を含めて頂く必要がございます。
尚、証明書サーバー側でサーバ証明書に中間CA証明書を含めるには、証明書サーバーの管理者に設定等の変更をしていただく必要がございます。
従いまして、証明書サーバーの管理者、またはWi-Fi接続サービスのサービス事業者にお問い合わせ頂きますようにお願い致します。

お、おぅ。。。
（実際にSH-02E (4.1.2)で上記確認してみた。確かにCA証明書入れてもつながらない。）

10/17追記
んじゃ、中間CA証明書をCA証明書として指定しちゃえば繋がるんじゃないか？と思ってごにょごにょやってみたが、そうはいかないようだ。

以下、機種別の検証結果。

Android 2.2.2 を搭載するDocomo SH-03C

■事前準備（推奨）
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「位置情報とセキュリティ」→「認証情報ストレージ」から「パスワードの設定」をクリックしてパスワードを設定しておく。画面ロックは設定しなくてもよい。あらかじめ有効にしておかない場合、設定中にパスワードの設定が促される。

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「切断されました」等と表示され、接続が完了しない。

■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
（この際、リンクを長押ししてしまうとダウンロードとなり、MicroSDカードがマウントされていないとのメッセージが表示されるので注意）
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、適当に名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。

事前準備の通り「認証情報ストレージ」のパスワードが設定されていないと、この時点でパスワードを設定するようダイアログが表示される。

2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。

3. EAP-PEAPのID、パスワードを入力し、接続。

■制限事項
端末を再起動すると、自動で再接続されない。SSIDを選択して接続する際に、「認証情報ストレージ」のパスワード入力を求められる。

Android 2.3.5 を搭載するAU IS14SH

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「切断されました」等と表示され、接続が完了しない。

■制限事項
端末を再起動すると、自動で再接続されない。SSIDを選択して接続する際に、「認証情報ストレージ」のパスワード入力を求められる。

Android 4.0.4 を搭載するSoftBank 102SH

■事前準備
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「その他の設定」→「ロックとセキュリティ」→「画面のロック」を「パターン」「ロックNo.」「パスワード」のいずれかにする。「なし」「スライド」「顔認証」は使用不可。あらかじめ有効にしておかない場合、設定中にロック方式を変更し、認証情報ストレージを有効にするよう促される。

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「認証に問題」と表示され、接続が完了しない。

■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、適当に名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。

事前準備の通り「認証情報ストレージ」が有効になっていないと、この時点で画面ロック方式を変更し、認証情報ストレージを有効にするよう求められる。

2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。

3. EAP-PEAPのID、パスワードを入力し、接続。

■制限事項
いったん接続完了後に端末を再起動すると、自動で再接続されない。
画面ロック解除後に接続状態を確認すると「認証に問題」となっている。
SSIDを選択して手動で接続を行うと再接続される。

Android 4.1.2 を搭載するDocomo SH-02E

■事前準備
CA証明書が格納される認証情報ストレージを有効にするために、「設定」→「その他の設定」→「ロックとセキュリティ」→「画面のロック」を「パターン」「ロックNo.」「パスワード」のいずれかにする。「なし」「スライドまたはタッチ」「顔認証」は使用不可。あらかじめ有効にしておかない場合、設定中にロック方式を変更し、認証情報ストレージを有効にするよう促される。

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「認証に問題」と表示され、接続が完了しない。

Android 4.2.2 を搭載するDocomo SH-06E

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力しても、「認証に問題」と表示され、接続が完了しない。

■設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、英字と数字のみの名前を入力して「OK」をクリックし、インストールされたダイアログが表示されることを確認する。

事前準備の通り「認証情報ストレージ」が有効になっていないと、この時点で画面ロック方式を変更し、認証情報ストレージを有効にするよう求められる。

2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。

3. EAP-PEAPのID、パスワードを入力し、接続。

ここから挙動が大きく変わった世代

Android 4.4.2 を搭載するDocomo SH-04F/AU SHL25（画面はSH-04F）

■CA証明書をインストールしない場合
正しいEAP-PEAPのID、パスワードを入力して接続を試みると、下記ダイアログが表示される。

？確認
CA証明書が指定されていません。
CA証明書が指定されていない場合、正しいサーバに接続されているか検証されません。現在の設定で接続しますか？
　「いいえ」「はい」

「はい」をクリックすると、CA証明書のインストールなしに接続が完了する。

■CA証明書をインストールする場合の設定方法
1. 端末でブラウザを起動し、CA証明書が置かれたURLを開いてCA証明書へのリンクをクリックする。
下記ダイアログが開くので、パッケージの内容が「CA証明書」となっていることを確認の上、英字と数字のみの名前を入力する。
「認証情報の使用」を初期値の「VPNとアプリ」から「WiFi」に変更する。
「OK」をクリックし、インストールされたダイアログが表示されることを確認する。

事前準備の通り「認証情報ストレージ」が有効になっていないと、この時点で画面ロック方式を変更し、認証情報ストレージを有効にするよう求められる。

2. 無線LANの接続設定にて、SSIDを選択し、CA証明書をクリックすると、上記でインストールしたCA証明書がプルダウンに表示されるので選択する。

3. EAP-PEAPのID、パスワードを入力し、接続。

■制限事項
CA証明書をインストールしない場合、インストールした場合のいずれにおいても、接続中の状態で端末を再起動すると、画面ロック中の状態であっても自動で再接続される。
CA証明書をインストールしない場合、一旦接続が確立した状態から「切断」を実行すると、再度手動で接続を行った際にCA証明書が指定されていない旨の警告が改めて表示される。
プライベートCA局のCA証明書をインストールした場合、通知領域に下記の警告が表示される。
（SCRoot1ca等のパブリックCAについては警告が表示されなかった）

！　ネットワーク監視
第三者があなたのネットワークアクティビティ（メール、アプリ、保護されたウェブサイトなど）を監視できます。
これは、信頼できる認証情報が端末にインストールされているためです。
「信頼できる認証情報を確認」

■どないせいっちゅうねん？

プライベートCA局のCA証明書を本検証で用いた方法でインストールする限り、この~~うざい~~警告については消す方法が無い（証明書をアンインストールする以外には）。
パブリックCA局のCA証明書でも同様の表示がされる、とのフォーラムの投稿が散見されるが、今回の検証ではSCRoot1ca, SCRoot2caについてはそのような挙動は発生しなかった。

ログイン - Google アカウント

Installing a private CA certificate for use with vpn or private web site encryption and or authentication results in the alert "network may be monitored" under the settings pull down. The following message is also displayed on boot "network may be monitored by an unknown third party". Although this doesn't appear to be limiting the phones functionality that I have seen so far the alert is bogus.

#3
Same problem when adding a CA for EAP-TLS authentication. This is a problem as it will incite users to remove the CA, thus lowering the corporate wifi security.

ログイン - Google アカウント

#16
For Wifi networks, even if you use a public CA, you still have to install the CA certificate, because Android doesn't reference those certificates for Wifi. So, even in that case, you would still get the annoying warning, which goes back to my point that I think the intent here is good, but the implementation is bad.

"even in that case, you would still get the annoying warning" が当方の検証と一致しないが。。。

異国のeduroamの中の人のコメント。
Android 4.3以上であれば、EnterpriseWifi APIを使用してCA証明書をWi-Fiストアにインストールすれば警告表示を回避できるとの書き込み。
実際に海外のeduroam加入機関の一部では　https://cat.eduroam.org　を運用しているようだ。

The situation is even a bit more absurd than the thread here suggests.
There is an API in Android 18+ (i.e. 4.3 and above), the EnterpriseWifi API. It has its own mechanisms to install CAs into the Wi-Fi store, and using that API will *not* trigger the warning and works completely UI-less.
Any manual installation of the CA by the user does though.
That's the extra hilarious thing: if the user consciously decides he wants to install something and clicks his way through very explicit UI, then that's bad and he will forever be warned. If an app sneaks the CA into his device without asking, it can do so without triggering any UI and Android will remain silent about it.
At least for our legitimate purposes, we the eduroam roaming consortium have developed such an app, the eduroam CAT app (Configuration Assistant Tool). You can install the app from Play Store, grab a config file matching your university from https://cat.eduroam.org and get a secure config, with CA and even server name matching. All this with no UI warnings about unknown certificates.
This doesn't invalidate this bug report though. If a user *decided* he *wants* a CA in his trust store, it is totally inadequate to warn them. Especially if the chosen trust store is the Wi-Fi store, which cannot be used to eavesdrop on the connection. The warning text is totally wrong in that case.
Anyway, not sure why I'm writing this. This bug report (and many others regarding Enterprise Wi-Fi features) continue to get ignored it seems. Way to go.

#46
I'm currently training my users to ignore certificate warnings so the can use our WPA-EAP secured network. This is plain wrong. Fix this.

ごもっともな気が。

クロアチアのeduroam installer。http://installer.eduroam.hr/

The eduroam installer enables simple and reliable configuration of end-user devices (computers, laptops, smart phones) for eduroam access.
Besides configuration for wireless access, installer can also be used for wired network access (if wired network access is compliant with eduroam standard, e.g. StuDOM network access).
To start configuring your device click on the button "Get configurations". If you have additional questions about installer service or problems with using this service please click on "Frequently asked question" button.

警告が出るのがプライベートCAだけなのか、パブリックCAでも同様に警告がでる場合があるのか、プライベートCAにパブリックオプションがついているとどうなるのか、パブリックCAだけど新しくて端末に最初から搭載されていない場合どうなるのか、いろいろとはっきりしない。

http://wiki.cacert.org/FAQ/ImportRootCert#Android_Phones_.26_Tablets

Starting from Android 4.0 (Android ICS/'Ice Cream Sandwich', Android 4.3 'Jelly Bean' & Android 4.4 'KitKat'), system trusted certificates are on the (read-only) system partition in the folder '/system/etc/security/' as individual files. However, users can now easily add their own 'user' certificates which will be stored in '/data/misc/keychain/certs-added'.
System-installed certificates can be managed on the Android device in the Settings -> Security -> Certificates -> 'System'-section, whereas the user trusted certificates are manged in the 'User'-section there. When using user trusted certificates, Android will force the user of the Android device to implement additional safety measures: the use of a PIN-code, a pattern-lock or a password to unlock the device are mandatory when user-supplied certificates are used.
Installing CAcert certificates as 'user trusted'-certificates is very easy. Installing new certificates as 'system trusted'-certificates requires more work (and requires root access), but it has the advantage of avoiding the Android lockscreen requirement.

いろいろと疑問は残っているのだが、一度ここらへんで公開してみる。
随時加筆します。

*1:https://sh-dev.sharp.co.jp/android/modules/d3forum/index.php?topic_id=108

*2:SH-02E (4.1.2)｜NTTドコモ端末・ブラウザスペック

*3:SH-06E (4.2.2)｜NTTドコモ端末・ブラウザスペック

*4:SH-04F (4.4.2)｜NTTドコモ端末・ブラウザスペック

*5:https://certs.nii.ac.jp/

*6:https://repo1.secomtrust.net/sppca/nii/odca3/

2015-09-22

MADOSMAで使っているアプリをまとめてみた

MADOSMAを使い出して3か月経った。
インストールしてみて気に入ったストアアプリを書き連ねてみる。
各アプリへのリンクは、MADOSMAでダウンロード履歴から「共有」でOneNoteにリンク書き出して、PC上でhatenaにペーストしているので、Windows Phoneでクリックするとストアに飛ぶ（たぶん）。

■ソーシャル系

Aristea

公式サイト　http://aristea.cc/

ありすてあ。Twitterクライアント。使ってすぐに気に入ったので他のクライアントは試していない。
特徴はいろいろあるけれど、Windows Phone 8.1によくマッチしている操作性だと思う。
某クーポンの使い道に困っているならまず購入して損はないと思う。

Pushalot

IFTTTと組み合わせると、いろんな通知をWindows Phoneで受信できる。
巡回しているサイトが更新されたら通知を受け取る、とか。

■ユーティリティ

My IP

端末が持っているIPアドレスを表示させるのに便利。
キャリア接続のIPv4/IPv6, Wi-Fi接続のIPv4/IPv6がまとめて表示できる。

■カメラ

OI Wireless

Olympus製のミラーレス一眼などに搭載されているWi-Fiに接続して、カメラに保存されている写真をプレビューしながらWindows Phoneのカメラロールに写真をダウンロードできる（JPEGのみ、RAWは未対応）。
アプリの説明にはE-M1, PEN E-P5, Stylus-1のみ記載されているが、当方ではE-M10との接続・写真転送を確認できた。

FlashAir Photos

無線LAN機能付きSDカード「FlashAir」にWi-Fiで接続して、カードに保存されている写真をプレビューしながらWindows Phoneのカメラロールに写真をダウンロードできる。
E-PL6など、Wi-Fiが内蔵されていないカメラを使うのに便利。

■MS謹製

Hyperlapse Mobile

ハイパーラプス（≠タイムラプス）動画が作成できるアプリ。
動画撮影してスライダーで速度調整するだけでハイパーラプス動画が作成できる。
窓の杜のレビューがわかりやすい。　
【レビュー】Windows Phone端末のカメラで簡単に“タイムラプス”動画を作成「Hyperlapse Mobile」 - 窓の杜

Remote Desktop

リモートデスクトップクライアント。IPv6でもさくっとWindows PCに接続できる。
画面はMADOSMAだとちっちゃいけど、自宅に接続できるようにしておくと意外となんでもできる。

OneDrive

自宅のOfficeで作成したExcelシートをOneDriveにほりこんでおいて、外出先でWindows PhoneからOneDriveを開いてExcelシートを見る、という高機能なメモ帳の置き場として役だつ。

あと、Excelとか。
マウスコンピュータさん＆マイクロソフトさんから、2000円分のストアで使えるクーポンを頂いたが、Aristeaは購入したあとだったので他に使い道が見つからない。
おすすめの有料アプリがあったら教えてください。

2015-07-24

OS X YosemiteのDYLD_PRINT_TO_FILEの権限昇格を抑える「SUIDGuard」の正しい（？）仕込み方

2015/8/13追記　本脆弱性(CVE-2015-3760)は、OS X 10.10.5で修正されています。 https://support.apple.com/ja-jp/HT205031

2015/7/26追記　SektionEinsのStefan Esserさんから、SUIDGuardを起動時に自動読み込みできるようpkg化したSUIDGuardNGが公開されました。
https://github.com/sektioneins/SUIDGuard/releases/download/1.0.0d1/SUIDGuardNG.pkg

https://twitter.com/i0n1c/status/624501679237517312:twitter:detail:left

当該pkgを管理者権限を利用可能なユーザでインストールし再起動すると、下記の通りOS X起動時にSUIDGuardNGがロードされます。
（脆弱性が存在するSUIDGuardによる対策を行っていなかった10.10.4にて検証）
利用は自己責任で。



bash-3.2# kextstat | grep SUID

   58    0 0xffffff7f80a3e000 0x3000     0x3000     com.sektioneins.driver.SUIDGuardNG (1) <7 4 3 2 1>

bash-3.2# dmesg | grep SUID

Security policy loaded: SUID Guard Kernel Extension (suidguard)

SUIDGuardNG.pkgでインストールされるのはこんな感じ。

$ pkgutil --pkgs=.*SUIDGuardNG.*
com.sektioneins.driver.SUIDGuardNG

$ pkgutil --files com.sektioneins.driver.SUIDGuardNG
Library
Library/Extensions
Library/Extensions/SUIDGuardNG.kext
Library/Extensions/SUIDGuardNG.kext/Contents
Library/Extensions/SUIDGuardNG.kext/Contents/Info.plist
Library/Extensions/SUIDGuardNG.kext/Contents/MacOS
Library/Extensions/SUIDGuardNG.kext/Contents/MacOS/SUIDGuardNG
Library/Extensions/SUIDGuardNG.kext/Contents/_CodeSignature
Library/Extensions/SUIDGuardNG.kext/Contents/_CodeSignature/CodeResources

注意▪️twitter等でワンライナーで広まっているDYLD_PRINT_TO_FILE脆弱性を試してrootを取得した場合、/etc/sudoersが書き換えられます。
/etc/sudoersを元に戻すのはSUIDGuard/SUIDGuardNGの役目ではありませんので、必ず/etc/sudoersの内容が元に戻っているかどうか確認してください。

https://twitter.com/i0n1c/status/624644608526577664:twitter:detail:left
https://twitter.com/i0n1c/status/624653431526019072:twitter:detail:left

※追記ここまで-------------------------------

騒がれているOS X Yosemiteにて一般ユーザがroot権限を奪取できる脆弱性について、ちょっと気になったのでメモ。

当該脆弱性は、7/7にドイツのSektionEins GmbHが、下記で公開したものである。
「OS X 10.10 DYLD_PRINT_TO_FILE Local Privilege Escalation Vulnerability」
https://www.sektioneins.de/en/blog/15-07-07-dyld_print_to_file_lpe.html

日本では、下記あたりから認識が広まったようだ。
https://twitter.com/applechinfo/status/623996009824190464:twitter:detail:left

合わせて、当該脆弱性に対処するためのSUIDGuard がSektionEins GmbHより先日公開された。
https://github.com/sektioneins/SUIDGuard

これを受けて、@applechinfo さんが
https://twitter.com/applechinfo/status/624071261950357504:twitter:detail:left
で実際にSUIDGuardを試されている。

が、
「　"SUIDGurd.kext"は約300行もないCコードでSektionEinsの署名付き、使い方は"/System/Library/Extensions"へコピーするだけで、管理者権限での認証が必要ですが、認識されればSUID/SGID rootバイナリが環境変数” DYLD_*”から保護されるようになっています。」
と書かれているが、若干説明が不足しているように思う。

まず、10.10以降はkextへの署名が必須になった。このため、署名のないkextをロードすることが標準ではできないので、SektionEinsが署名したうえで公開してくれているのはとても意味がある。
kextへの署名は、通常のアプリへの署名とは異なり、Appleに個別に権限リクエストが必要であり、Appleが許可をして初めてCertificationCenterからkext用署名のリクエストができるようになる、というめんどくさい流れになっている。
（参考：http://qiita.com/gamako/items/9980a08a24916f9f98b2）

このため、SektionEinsがgithubで公開してくれているソースコードを、自らXcodeでBuildしても、Yosemiteではロードに失敗する。
よって、下記にあるSektionEinsが署名済のSUIDGuard.kextを使用する必要がある。
https://github.com/sektioneins/SUIDGuard/releases

そして、上記applechinfoさんの検証記事に記載されているスクリーンショットでは、確かにSUIDGuardは確認済の開発元として署名されていることは確認できるものの、SUIDGuardは「読み込み済：いいえ」「読み込み可能：いいえ」となってしまっている。

大学など、不特定多数の人間が一般ユーザで利用する環境において、当該脆弱性を回避するならば、SUIDGuardを起動時にロードさせる必要があるので、手順を簡単に書くと下記の通りとなる。

※root権限を使用できるユーザで作業する
※SUIDGuard.kext.tar.bz2 をダウンロードしておく

$ sudo -s
Password:
#
# chown root:wheel SUIDGuard.kext.tar.bz2
# tar -xvzf SUIDGuard.kext.tar.bz2
x SUIDGuard.kext/
x SUIDGuard.kext/Contents/
x SUIDGuard.kext/Contents/_CodeSignature/
x SUIDGuard.kext/Contents/Info.plist
x SUIDGuard.kext/Contents/MacOS/
x SUIDGuard.kext/Contents/MacOS/SUIDGuard
x SUIDGuard.kext/Contents/_CodeSignature/CodeResources
# mv SUIDGuard.kext /System/Library/Extensions
# kextutil -b com.sektioneins.SUIDGuard
# cd /Library/LaunchDaemons
# vi jp.ac.example.SUIDGuard.plist

jp.ac.example.SUIDGuard.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>KeepAlive</key>
        <false/>
        <key>Label</key>
        <string>jp.ac.example.SUIDGuard</string>
        <key>ProgramArguments</key>
        <array>
                <string>/sbin/kextload</string>
                <string>/System/Library/Extensions/SUIDGuard.kext</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
        <key>StandardErrorPath</key>
        <string>/dev/null</string>
        <key>StandardOutPath</key>
        <string>/dev/null</string>
        <key>UserName</key>
        <string>root</string>
</dict>
</plist>

続き　

# plutil -lint jp.ac.example.SUIDGuard.plist
jp.ac.example.SUIDGuard.plist: OK

# launchctl load -w jp.ac.example.SUIDGuard.plist            

# launchctl list | grep SUID   
-       0       jp.ac.example.SUIDGuard
     
# kextstat | grep SUID
  131    0 0xffffff7f82a38000 0x2000     0x2000     com.sektioneins.SUIDGuard (1) <7 4 2 1>

# dmesg | grep SUID
Security policy loaded: SUID Guard Kernel Extension (suidguard)

再起動し、起動時に正常にSUIDGuardが読み込まれているか確認する。

参考：http://www.heise.de/forum/heise-Security/News-Kommentare/Einzeiler-beschert-Adminrechte-unter-Mac-OS-X-10-10/Re-Mein-Workarround/posting-21028401/show/

2015-06-26

MADOSMAの技適の詳細を見たら、AU(KDDI系MVNO含む)のSIM挿したらダメだった＆公式FAQでAU使えませんキタ

MADOSMA買ってから改めて技適の各種規約を調べだしたような人間ですが、そもそもMADOSMAにAUのSIM挿して頑張っていいんだっけ？という疑問がわいてきた。
例えば、ZenFone2 は技適マークがあって、かつKDDI系のSIM挿して通信できるらしいけどアウトですよね。

6/26現在、総務省のサイトではまだMADOSMAの工事設計認証（認証番号　008-150248)の詳細が公示されていない。

マウスコンピューターの担当者様に確認したところ、MADOSMAの工事設計認証の詳細は下記の通りであるとのご回答をいただいた。
（画像で頂いた内容を転記）

■証明規則第2条第1項第11号の19の無線設備 SC-FDMA(LTE-FDD)方式携帯無線通信用陸上移動局

特定無線設備の型式又は名称	M54TJP
特定無線設備の製造者名	株式会社マウスコンピューター
工事設計認証番号	008-150148

電波の形式、周波数及び空中線電力

5M0	D1A,D1B,D1C,D1D,D1E,D1F,D1X,D7W,G1A,G1B,G1C,G1D,G1E,G1F,G1X,G7W	832.5MHz〜842.5MHz (100kHz間隔101波), 1747.4MHz〜1782.4MHz (100kHz間隔351波), 1927.2MHz〜1977.5MHz (100kHz間隔504波) 0.20W
10M0	D1A,D1B,D1C,D1D,D1E,D1F,D1X,D7W,G1A,G1B,G1C,G1D,G1E,G1F,G1X,G7W	835.0MHz〜840MHz (100kHz間隔51波), 1749.9MHz〜1779.9MHz (100kHz間隔301波), 1934.7MHz〜1975.0MHz (100kHz間隔404波) 0.20W
15M0	D1A,D1B,D1C,D1D,D1E,D1F,D1X,D7W,G1A,G1B,G1C,G1D,G1E,G1F,G1X,G7W	837.5MHz, 1752.4MHz〜1777.4MHz (100kHz間隔251波), 1942.2MHz〜1972.5MHz (100kHz間隔304波) 0.20W
20M0	D1A,D1B,D1C,D1D,D1E,D1F,D1X,D7W,G1A,G1B,G1C,G1D,G1E,G1F,G1X,G7W	1754.9MHz〜1774.9MHz (100kHz間隔201波), 1949.7MHz〜1970.0MHz (100kHz間隔204波) 0.20W

・・・これ、AU（KDDI系MVNO含む）のSIM挿したらダメな奴じゃない？
いや、現状そもそも通信できなさそうですけど。

おいらの理解だと、KDDIのBand1で堂々と電波を発射するためには、上記に加えて下記の認証がいるんじゃないかと思った。

5M0	1922.5MHz〜1927.1MHz (100kHz間隔47波）
10M0	1925.0MHz〜1934.6MHz (100kHz間隔97波）
15M0	1927.5MHz〜1942.1MHz（100kHz間隔147波）,1932.5MHz（1927.19MHz〜1937.81MHzの内、連続した最大5.4MHz幅を送信する場合に限る）
20M0	1930.0MHz〜1949.6MHz（100kHz間隔197波）,1930MHz（1925.32MHz〜1934.68MHzの内、連続した最大4.32MHz幅を送信する場合に限る）

マウスコンピューターさんのサイトでは、6/26付で下記FAQが公開されたようだ。

FAQアーカイブページ
文書番号： 19827
更新日： 2015/06/26 18:47
対象OS ： Windows Phone 8.1
FAQアーカイブページ
[ MADOSMA ] au 回線で使えますか？

対象機種　MADOSMA Q501-BK　MADOSMA Q501-WH

・ご使用いただけません。

以上です。

もうちょっとこのFAQ早く公開してほしかったなー

2015-06-22

MADOSMAの通信関係（キャリア接続、Wi-Fi、VPN、Bluetooth）で気づいたことをまとめてみる (10/20追記 SPモード接続を確認）

マウスコンピューターが発売したWindows Phone 8.1搭載のMADOSMAを3日ほど使ってみて、主に通信周りで気づいたことをまとめてみる。

環境は出荷時の状態で、既に Windows Phone 8.1 Update 2 (GDR2）にあたる8.10.15153.165とWindows Phone更新プログラム（MCJ）が配信されているが適用していない。

このため、適用後は下記挙動が変わる可能性はある。

■キャリア接続

docomo

MADOSMAのAPN一覧には「NTT Docomo spmode」が存在するが、docomo側の制限によりSPモードはMADOSMAを含むSIMフリー端末ではキャリア接続には利用できない。
SIMフリー端末でdocomo回線を使用するためには、オプションとして「mopera U」の契約が必要となる（月額540円）。

2015/10/20追記
MADOSMAでもSPモードが使えるようになっています。
設定はプレインストールされているものを選択するだけ。

以下のDocomoの方針変更に伴うものではないかと思われます。

NTTドコモがspモードをSIMフリースマホに開放！APNのIMEI制限撤廃して同社以外のSIMフリースマホなどでも利用可能にーーNexus以外でも多くの機種で確認 https://t.co/xkU8oepyd9 #smaxjp pic.twitter.com/pcQl5C9QXz
— S-MAX編集部 (@smaxjp) 2015, 10月 20

以下のmoperaに関する記述は必須ではなくなりました。

mopera Uを契約したdocomo SIMであれば、ネットワーク接続プロファイルとして「NTT Docomo - opera」（ウィルス等の不正アクセスがフィルタリングされる mopera.net）
または「NTT Docomo - mopera ff」(フィルタリングフリーの　open.mopera.net) を選択することでLTE接続が可能となる。
なお、mopera Uで払い出されるIPv4アドレスはグローバルIPアドレスである。（SPモードはプライベートIPアドレス）

但し、標準で設定されているネットワーク接続プロファイルは、IPv4のみの接続となっているため、mopera UのIPv6接続も利用するためには下記の手順が必要となる。

1) いずれかのmoperaのAPNに接続した状態で、ブラウザで　http://www.mopera.net/customize/ を表示させる。(Wi-Fi接続は切断しておく方が混乱がない）
2) ページ最下部の「IPv6アドレス設定」より「IPv6アドレスを利用する」に設定する

以上の設定変更を行った上で、MADOSMA側にて下記の通りAPN設定を行う。
設定→「携帯ネットワーク＋SIM」→「SIM設定」→「手動インターネットAPN」をON→「インターネットAPNを編集」
APNに　open.mopera.net を入力　（フィルタリングフリーAPNを利用する場合）
IPの種類に　IPv4v6 を選択
保存
　

以上により、mopera Uを契約したdocomo SIM回線でIPv4, IPv6が共に利用できることを確認できた。

なお、アドレスの確認にはTAUCHI Kazuaki氏のhttp://www.windowsphone.com/ja-jp/store/app/my-ip/78e40974-02d7-4cc8-95e9-ce4ffe23fabc を利用させていただいた。

AU

MADOSMAは、CDMA2000に対応していないため、AUの従来の(VoLTEではない）3G通話はハードウェア的に行えない。
以下はデータ通信のみを目的とした検証である。

検証に使用したSIMは、SOL26で利用していたVoLTEではない音声契約のSIMで、LTE NETの契約を付与している。
しかし、おそらく上記SIMではAU回線を利用したデータ接続はできない。
AUの公式ページには、以下のように記載がある。　http://csqa.kddi.com/posts/view/qid/k138920137

他社が販売する携帯電話機などを、auICカードでご利用の場合には、下記の注意事項を必ずご確認ください。
（略）
インターネット接続サービス：「LTE NET for DATA」

このため、auサポートサイトより「LTE NET for DATA」を追加で申込みしたが、通常翌日から変更が適用されるはずが48時間経っても手続き中のままとなっており、現在保留中である。（追記予定）

なお、「LTE NET for DATA」を契約したSIMであれば、下記の通りAPNを設定することでデータ通信が可能となるかもしれない。
但し、MADOSMAはAUのBand1にしか対応していないため、エリアには注意する必要がある。

■アクセスポイント設定内容
APN名　 ：au.au-net.ne.jp
ユーザー名：user@au.au-net.ne.jp
パスワード：au
認証タイプ：CHAP

Softbank他

未検証

docomo系のMVNO

IIJmioが公式にMADOSMAで利用可能な旨アナウンスしている。

- - - - -

Windows Phone 8.1 を搭載したマウスコンピューターのスマートフォン「MADOSMA Q501」の検証を行いましたので動作確認済み端末を更新しました。IPv6の利用に一手間かかりますが、問題なくご利用いただけます。URL

2015-06-19 16:43:05 via Twitter Web Client

■無線LAN

WPA/WPA2 Enterprise 認証

企業・大学等でよく使われている。問題なく接続可能。
利用できるEAPは次の通り、EAP-TTLSとEAP-PEAP MACHAP v2である。
また、サーバ証明書の検証は「なし」「常に確認する」「証明機関」が選択可能である。
（余談であるが、SHARP製Android端末はこの選択ができず、独自実装により、EAP-PEAP、EAP-TTLS認証方式での接続にもCA証明書が必須で控えめに言って非常に触りたくない　*1　)

EAP-SIM/EAP-AKA認証

WPA2 EnterpriseのEAPとして、SIMカードを使った認証を行うもの。docomoのWi-Fiスポットである「0001docomo」に使われている。接続可能。

「au Wi-Fi SPOT」もEAP-AKA、「ソフトバンク Wi-Fiスポット」はEAP-SIMなので同様に利用可能と思われるが、未検証である。

■VPN

GDR2に上げてから検証した方がよいかもしれない。
一応、IPSec接続のL2TP は利用可能なようであるが、当方のVPNサーバが若干特殊な環境にあることもあり接続に成功していない。

■Bluetooth

Windows Phone 8では HFP1.5を、Windows Phone 8.1ではHFP1.6をサポートしている*2 が、Panasonicのカーナビ（Strada CN-HX910D）とはBluetooth Audioとしての接続は行えるものの、ハンズフリー機器としての接続が現状行えない。
そこらへんに転がっていた貰い物のハンズフリースピーカは正常に利用可能であった。

GDR2では更にHIDなどのプロファイルが追加され、Bluetooth キーボードの接続などが可能となるようだ。

- - - - -

MADOSMAのOTAでUpdate 2適用後、Bluetoothキーボードも使えるようになりました。 URL

2015-06-17 12:15:16 via Twitter for iPhone

■PCとのUSB接続

Windows 8.1のPCとUSBで接続すると、MADOSMA本体、SDカードがそれぞれストレージとしてエクスプローラに表示された。

*1:https://sh-dev.sharp.co.jp/android/modules/d3forum/index.php?topic_id=108

*2: https://www.windowsphone.com/ja-jp/how-to/wp8/connectivity/bluetooth-faq

2015-06-16

MADOSMAで"Hello World"

MADOSMA実機到着までに環境を整えてHello World作っておくメモ

必要なもの
Visual Studio Express 2013 for Windows (Update 2 以降) 最新はUpdate4
https://www.visualstudio.com/ja-jp/downloads#d-express-windows-8?CR_CC=200395106

開発者登録
https://dev.windows.com/ja-jp/programs/join

個人開発者は2,000円弱 (Dev Centerベネフィットプログラムの参加特典で無償だったのは終わっちゃったっぽい？）
法人は10,000円弱　年度更新（BizSpark期間中はトークンがもらえるので無料で開始できる）

開発用のWindows Phoneデバイスの登録（MADOSMA到着してから）
Visual Studioをインストールした母艦で　phonereg　を検索すると出てくる「Windows Phone Developer Registration(8.1)を使う」
https://msdn.microsoft.com/ja-jp/library/windows/apps/dn614128.aspx

Visual Studio触ったこと無くても優しいおじさんが教えてくれる
英語だけど画面表示見れるので簡単
Windows Phone 8.1 Development for Absolute Beginners
http://www.microsoftvirtualacademy.com/training-courses/windows-phone-8-1-development-for-absolute-beginners?prid=ch9videolink

MSの方の日本語HowTo
http://blogs.msdn.com/b/shintak/archive/2015/02/23/10595031.aspx

2015-06-07

MADOSMAでL2TP/IPSecを利用してSoftEther VPNを利用できるのか

2015/6/18（木）、マウスコンピュータがWindows Phone 8.1 Updateを搭載したSIMフリーのスマートフォン、MADOSMAを発売する。
　
技適を取得した一般販売されるWindows Phone 8.1端末は初である。

一部に誤解が見られるが、Windows Phone 8.1とPC向けのWindows 8.1は完全に別物である。
詳しくは　@kurosawa0626 さんのブログ　で、結局Windows Phone（MADOSMA）って何が出来て何が出来ないの？ – ぅゎょぅι゛ょっょぃ　に非常に良くまとまっている。

MADOSMAはホワイトとブラックのモデルが存在し、ブラックは法人向けとなっているが、カラー以外の基本的な仕様に違いは無いようだ。
しかし、これまで各メディアの取材記事やレビューなどでは、MADOSMAをVPNで外出先から社内に接続することが可能なのか、といったことには殆ど触れられていない。

Windows Phone 8.1が利用できるVPNについて

Windows Phone 8は下記の通り改修を重ねている。

公開からWindows Phone 8.1 までのバージョンで利用できたVPN接続のプロトコルは、　IKEv2 のみであった。（SSL-VPNを除く）
これが、Windows Phone 8.1 Update になって、VPN接続のプロトコルにL2TP/IPsecが利用可能となった。

VPN. VPN now supports L2TP, which lets you connect to more VPN services. Whether you connect to a VPN for work or personal use, you can do it on your Windows Phone.

L2TP/IPSecを利用したVPNは、筑波大学の研究プロジェクトとしてオープンソースで公開されている　SoftEther VPN *1 を使用して個人でも特別な機器無しに簡単に構築可能である。
しかし、下記フォーラムを見ると、接続が上手くいかなくて難儀していた人がたくさんいるようだ。
Tutorials : windows phone 8.1 Support L2tp/ipsec VPN now ! - Windows Central Forums

そして、Windows Phone 8.1 Update 2（Internally it is known as GDR2 or general distribution release 2. *2 ）になって、L2TP/IPsecの接続において証明書の使用と常時接続が可能となった。

VPN. Now you can use certificates to sign in for L2TP VPN connections. Always-on VPN profiles are now supported too, so you're automatically and always connected.

残念ながら、SoftEther VPNが公開しているVPN Azure *3 で利用されているSSTPには未だ対応していない。

MADOSMAは公式発表によれば、Windows Phone 8.1 Updateにて出荷される。
しかし幾つかのメディアの取材記事によれば、既にWindows Phone 8.1 Update 2が準備されていることが示唆されている。