hgot07 Hotspot Blog

主に無線LANや認証連携などの技術についてまとめるブログです。ネコは見る専。

大学ランキング上位はeduroam参加率が高い

日本は2006年8月にeduroamに加盟しましたが、それから国内の参加機関数も伸びて、2020年7月現在で279機関が参加しています。一方、文部科学統計要覧によると、2006年に1,276あった高等教育機関(専門学校, 高専を含む)が、2014年には1,190、2018年には1,170まで減っています。短大の減少が主な理由です。

その昔、欧州で開催されたeduroam関係の会議において、「日本はまだ100機関程度なので……」と発言したところ、ちょっと驚かれました。大学が数十という規模の国も少なくないので、絶対数では大きいということでした。ところが、どういうわけか国内の大学は動きが良くなくて、日本よりずっと後に参加した米国やインドに機関数であっと言う間に抜かれてしまいました。現在の国内の普及率は、分母を高等教育機関数にとると、23.8%になります。研究所も参加機関の中に含まれていることから、実際より高めの値になります。

うーん……

 

さて、ある日の夕刻、なんで国内は動きが良くないのだろうかとぼんやり考えながら風呂に入る準備をしていたところ、ふと、ランキングとの相関を取ってみたらどうかと思い当りました。大体、ブレークスルー(?)になりそうな閃きが降ってくるのは風呂場やトイレと、銀河系で相場が決まっています。

ランキング上位にいる大学なら、機関内の教育・研究環境の充実や、学会や地元との連携にも"比較的"熱心で、社会貢献を"比較的"よく理解し、リソースも"比較的"潤沢だろうと想像します。(がばがば)

ランキングにも色々ありますが、大雑把に傾向を見たいだけなので、適当に拾ってきた「Times Higher Education 世界大学ランキング日本版2020」の総合ランキングを使ってみました。

japanuniversityrankings.jp

200校ぐらい載っているのですが、全部やるのはホネなので、1-80位のみ拾ってみました。これにeduroam JPにある参加機関リスト突き合わせて、色付けしてみると、このとおり。

f:id:hgot07:20200724223533p:plain

 

上位80大学中69校が参加しており、普及率86.3%と算出されました。

 

おみごと!

 

学認の方も似たような傾向が出るのではないかと予想しています。(誰かやって)

 

表を作りながら、ちょっと我ながらゲスいなと思ったのは内緒。

 

[2020/7/31追記] 国立大学法人も気になったので、数えてみました。78/86=90.7%と出ました。うーん、これは微妙?

 

おわり

古いRADIUSサーバではeduroamに接続できないOSがある件

openSUSE Leap 15.1でもUbuntu 20.04 LTSでもeduroamにきちんと接続できるのに、なぜかCentOS 8では認証が通らない!

色々と調べてみたところ、ちょっと奥深い問題がありました。

結論を述べると、「機関はきちんと新しいRADIUSサーバに入れ替えよ!」ということです。

不具合の様子

CentOS 8でeduroamに接続しようとしたところ、どうしても認証が通らないという状況でした_(゚。3」∠)_

wpa_supplicantでの接続を試してみたところ、認証の初期の段階で、以下のようにSSL3 alertが出ています。ヒントをくれるなんて、なんて親切だこと……。

# wpa_supplicant -iwlp0s29f7u2 -c/etc/wpa_supplicant.conf
Successfully initialized wpa_supplicant
wlp0s29f7u2: Trying to associate with 6c:b2:ae:xx:xx:xx
(SSID='eduroam' freq=5500 MHz)
wlp0s29f7u2: Associated with 6c:b2:ae:xx:xx:xx
wlp0s29f7u2: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlp0s29f7u2: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp0s29f7u2: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp0s29f7u2: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlp0s29f7u2: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:protocol version
OpenSSL: openssl_handshake - SSL_connect error:1425F102:SSL
routines:ssl_choose_client_version:unsupported protocol
wlp0s29f7u2: CTRL-EVENT-EAP-FAILURE EAP authentication failed
wlp0s29f7u2: Authentication with 6c:b2:ae:xx:xx:xx timed out.

 

原因はTLS1.2に非対応のRADIUSサーバ

しばらく検索してみた結果……、あぁ、この辺ですね?

https://bugzilla.redhat.com/show_bug.cgi?id=1241930

要するに、以下の経緯のようです。

  • SSL3.0の脆弱性(Poodle)への対応のために、SSL3.0を無効にすることが一般的になっている。
  • 古いRADIUSサーバがTLS1.2に対応していない。
  • 端末側のオプションで対処できなくもないが、利用者への負担が大きすぎるうえ、ワークアラウンドにすぎない。
  • RADIUSサーバのアップデートしか対策がないと考えるべき。

自機関の認証サーバ(RADIUSサーバ)が、該当機能のない製品か、または、長くアップデートされていない可能性があるということです。

 

対策

機関はきちんとTLS1.2対応の新しいRADIUSサーバに入れ替えよ!

一部のOSでどうしてもeduroamの認証が通らないという報告が、日本各地からチラホラ聞こえていたのですが、大きな原因の一つはたぶんこれでしょう。

機関の管理者のみなさま、RADIUSサーバの仕様をご確認ください。

 

おわり  (今回は短かった……)

RADIUSサーバをRadSecでつないでみよう! (FreeRADIUS編)

RADIUSをいじっている人もそうそういないと思いますが(?)、そのせいで新しい情報があまり出回っていないので、ちょっと書いてみます。(自分のための備忘録ですよ、そうですよ)

RADIUSプロトコルでは、通常1812/udp (認証), 1813/udp (アカウンティング)が使われるのですが、RadSecというトランスポートもあります。FreeRADIUSでRadSecを使ってみようという話です。

ポイント

  • 素のRADIUSではUDPを使うため、証明書を使うEAP-TLSなどでパケットが大きくなると、Fragmentationで不安定になることがある。
  • 普通のRADIUSでは送信元・送信先ともIPアドレスの変更に対応しにくい。
  • RadSecはRADIUSの通信を安全・安定にしようとするトランスポートで、RADIUS over TLS (RFC 6614) の実装。
  • RadSecでは標準で2083/tcpが使われ、証明書で接続相手を認証するのが一般的。IPアドレスの変更にも柔軟に対応できる。
  • Dynamic Peer Discovery (RFC 7585)と組み合わせると、IDプロバイダ(IdP)のサーバと直接接続して認証連携もできる。(FreeRADIUS 3.0.21では未対応。当記事では書かない)

 

RadSecに対応したRADIUSサーバ

RadSecに対応したRADIUSサーバには、FreeRADIUSやRadiatorなどがあり、プロキシのみの機能ならばradsecproxyがあります。

執筆時点(2020/6/29)のFreeRADIUSのバージョンは3.0.21ですが、今回はこれを使って二拠点間でRadSec接続を実現してみます。

 

FreeRADIUSのデモ用証明書を作り直す

世の中のSIerには、どういうわけかLinuxディストリビューションに付属のパッケージを使いたがるところが少なくないようです。しかし、パッケージだからといって安定しているとは限りません。特にFreeRADIUSの場合、古いバージョンでは幾つか致命的なダメ仕様やバグを抱えているものがあるので、最低でも3.0.19以降を使うべきです

さて、なーんも考えないでFreeRADIUSをソースからビルド、インストールすると、デモ用の証明書群が自動的に作成されます。標準的には /etc/raddb/certs の中に置かれるのですが、インストール先が別の所にある場合は、適宜読み替えてください。

この証明書群、RADIUS proxyの場合はこのままでもよいのですが、IdPになるサーバの場合は、まともなサーバ証明書を入れるべきです。デモ用はCA証明書でさえ60日間しか有効ではないので、とりあえず、全部作り直しましょう

certsディレクトリの中にあるREADMEは、本当に有用なことが書かれているので、ぜひ読みましょう。まずcertsの中にcdして、設定ファイル *.cnf の中身を自サイトに合わせて書き換えましょう。続いて、READMEのとおり以下のコマンドを打ち込み、期限切れになっている証明書をすべて削除の上で、新しく作り直しましょう。

# rm -f *.pem *.der *.csr *.crt *.key *.p12 serial* index.txt*
# make

おっと、まだ説明していませんでした。

無線LANサービスプロバイダ(SP)側で、基地局を収容しているRADIUS proxyとして動作するホストをHost1とします。

SPから認証要求を受け取って認証処理を行う、IdP側のホストをHost0とします。Host0は、中間proxyの場合もあるでしょう。

今回、Host0が証明書発行の主体となり、Host1に対してRadSec用のクライアント証明書を発行することにします。両ホストで、正しく本番用の証明書が作られている必要があります。

 

RadSec接続用のクライアント証明書を作成する

RadSecの接続に必要なクライアント証明書を作成する手順は以下のとおりです。

Host1 (SP側)でクライアント証明書のCSRを作る

Host1のFreeRADIUSの証明書ディレクトリ (標準では/etc/raddb/certsにある) の中で、次のようにしてクライアント証明書を発行依頼するためのCertificate Signing Request (CSR)を作成します。出来上がったCSRファイル (client1.csr) をHost0に持っていきます (Host0の管理者に渡します)。

# cp client.cnf client1.cnf
(client1.cnfを適宜編集)
# openssl req -new -out client1.csr -keyout client1.key -config ./client1.cnf

Host0 (IdP側)でクライアント証明書を発行する

Host0の管理者は、FreeRADIUSの証明書ディレクトリ (標準では/etc/raddb/certsにある) の中で、受け取ったCSRを元に、次のようにしてクライアント証明書を作成します。Host1用の client-for1.cnf ファイルを先に作成しておきます。出来上がった証明書ファイル (client1.crt) と、自己のCA証明書 (ca.pem) を、Host1に送ります。-keyに書くパスワードは、もちろんHost0のCA証明書のものです (Host1の方を知っているはずないので)。また、Host1のCA証明書と紛れないように、別名のファイル (ca0.pem) にコピーしてから渡すとよいでしょう。

# cp client.cnf client-for1.cnf
(client-for1.cnfを適宜編集)
# openssl ca -batch -keyfile ca.key -cert ca.pem -in client1.csr \
-key whatever -out client1.crt -extensions xpclient_ext \
-extfile xpextensions -config ./client-for1.cnf
# cp ca.pem ca0.pem

Host1 (SP側)でクライアント証明書を変換する

FreeRADIUSでは .crt のままでも使えますが、ついでなのでPEM形式も作っておきましょう。

Host1で、受け取ったクライアント証明書 (client1.crt) を元に、次のようにしてPEM形式のクライアント証明書を作成します。パスワードは二つとも自分の client1.cnf の中に書いたものです。

# openssl pkcs12 -export -in client1.crt -inkey client1.key \
-out client1.p12 -passin pass:whatever1 -passout pass:whatever1
# openssl pkcs12 -in client1.p12 -out client1.pem \
-passin pass:whatever1 -passout pass:whatever1

 

FreeRADIUSの設定

Host1側の設定

現在、FreeRADIUSのRadSecサポートは未熟な感じで、設定ファイルも十分に整理されていない印象です。認証要求を送り出す側であるHost1でRadSecに関係するファイルは、proxy.confとsites-available/tlsの二つです。とりあえずバックアップを作成しておくのが良いでしょう。

sites-enabledの中から、sites-available/tlsシンボリックリンクを張ることで、このファイルの内容が有効になります。

# (cd sites-available; cp -p tls tls.orig)
# cd sites-enabled
# ln -s ../sites-available/tls

ファイルtlsを編集します。

home_server tls {...} というセクションを見つけて、その部分を丸っとコピーします。例えば、サーバ名をHost0に変更しておきます。冒頭はこんな感じです。

home_server Host0 {
ipaddr = <Host0のIPアドレス>
port = 2083
type = auth
secret = radsec # 通常は"radsec"のまま使う
proto = tcp
status_check = none

続いてtls {...}というセクションがあるので、この中にある証明書関係の変数を以下のように変更します。

private_key_password = whatever1  # 自分のclient1.cnfに書いたもの。
private_key_file = ${certdir}/client1.key # Host1で作成したもの。

certificate_file = ${certdir}/client1.pem
# Host0から受け取って変換したもの。.crtのままでもよい。

ca_file = ${cadir}/ca0.pem # Host0から受け取ったもの。

home_server_poolを定義します。

home_server_pool Host0-pool {
type = fail-over
home_server = Host0 # home_serverを多重化した場合は複数行並べる。
}

あとは、proxy.conf を編集して、必要なものをHost0-poolに飛ばすように設定します。要するに、普通はproxy.confの中にあるhome_serverの設定が、RadSecではtlsファイルの中にあるということです。設定を有効にするために、radiusdをリスタートしておきます。

 

Host0側の設定

認証要求を受信するHost0でRadSecに関係するファイルは、sites-available/tlsだけです。とりあえずバックアップを作成しておくのが良いでしょう。

# (cd sites-available; cp -p tls tls.orig)
# cd sites-enabled
# ln -s ../sites-available/tls

ファイルtlsを編集します。listen {...}セクションの中にtls {...}セクションがありますが、Host0ではすべて自前の証明書をそのまま利用するので、変更不要です。(server.cnfをいじっている場合はprivate_key_passwordの変更を忘れずに)

clients radsec {...} セクションの中に、127.0.0.1の設定があります。この下に、Host1からの接続を受け入れる設定を追加します。

client Host1 {
ipaddr = <Host1のIPアドレス または *>
proto = tls
secret = radsec # Host1の設定に合わせるが、通常は"radsec"のままでよい。
}

Host1から2083/tcpが届くように、Firewallの設定を忘れずに。設定を有効にするために、radiusdをリスタートしておきます。

 

おわりに

あとは、Host1からradtestなどで認証が通ることを確認すれば終わりです。実は、FreeRADIUSのRadSec関係のエラー表示が不親切で、というかopensslライブラリのせいなんでしょうが、トラブルシューティングが面倒という問題があります。Good luck!

通常の用途でRadSecの有難味を感じることはほとんどないと思いますが、それなら、試しにHost0で ipaddr = * に設定の上、Host1のIPアドレスを変化させてみたらどうでしょう。これで、基地局側のシステムは、どこからでもRADIUSクライアントになれるんですよ(・∀・)ノ

(まぁ、汎用のVPNでもできるんですけどね……)

 

おわり

 

 

無線LANのMACアドレスランダム化で行動分析ビジネスはどう変わるか

2019年11月にロンドンで開催されたとあるWi-Fi関係のイベントで、行動分析のソリューションを扱っている幾つかのブースに行き、ちょっと意地悪な質問をしてみました。「MACアドレスランダム化が一般的になってきましたが、これが有効でも利用者追跡できますか?」と。間髪を入れずに「できますよ」と言う怪しいセールスパーソン、ちょっと間があってから「アプリを入れれば……」と言う信頼できそうな担当者、「ぁー⤵」とトーンが下がってしまう正直な人……。

最近の主要なオペレーティングシステム(OS)では、無線LAN機能に「MACアドレスランダム化」の機能が搭載され、標準で有効になってきました。本稿では、MACアドレスランダム化が利用者のプライバシー保護や無線LANサービスにどのように影響するのかを概説します

ポイント

  • OSベンダがプライバシー保護を重視するようになり、MACアドレスランダム化に代表される端末固有情報秘匿化が一般的になってきた。ランダム化にもレベルがあり、強化されつつある。
  • 無線LANの通信を傍聴して行動分析するソリューションが存在するが、MACアドレスランダム化により、オープンWi-Fiでは機能しなくなってくる。
    (シーケンス番号やRSSI、送信間隔などを分析する手法もあるが、本稿では扱わない)
  • 利用者認証と事業者の同意、及び、利用者による明示的な同意があれば、正攻法で行動分析することは可能。

無線LAN端末のMACアドレス

イーサネットによる有線接続と同様に、無線LANでもMACアドレス (Media Access Control Address)が利用されています。元々はネットワーク機器のハードウェアに一意に割り当てられる物理アドレスで、端末などを識別するためのIDとして利用されていました (実際は重複もあります)。同じ端末ならば、ずっと同じMACアドレスが使われるというのが、旧来の仕組みでした。

無線LANで、端末と基地局を使う形式はインフラストラクチャモードと呼ばれています。公衆無線LANの場合は、当然このモードです。端末が基地局に接続する場合、

  1. 基地局が定期的に出すビーコンを頼りに端末が接続相手を決める方法
  2. 端末が自発的にプローブリクエスト (Probe Request)を出して、それに応答した基地局に接続する方法

があります。端末のMACアドレスも、基地局MACアドレス(しばしばBSSIDとして利用される)も、暗号化されずにパケットに埋め込まれて、電波として飛び交います。第三者でも、電波を傍受してMACアドレスを覗き見ることができます。

もし端末がプローブリクエストを出さないのならば、基地局MACアドレスが覗かれるだけなので、公衆無線LANの利用者の視点では特に問題ないでしょう。

端末がプローブリクエストを送信した場合、あるいは、実際に基地局に接続した場合は、端末の利用者が特定できないまでも、他人が同一端末の動きを調べることができます。ここでいう他人とは、公衆無線LANシステムを運用している通信事業者かもしれないし、それとはまったく関係ない人で、ストーカーかもしれません。いずれにしても、他人に勝手に行動分析されるのはプライバシー問題になりかねないということで、端末の追跡が困難になるように、MACアドレスをころころと変える手法が考案され、「MACアドレスランダム化」として端末に導入されることになりました

 

プライバシー保護に舵を切った端末ベンダ

端末が同一のMACアドレスを使い続けることによる問題は、プローブリクエストの時だけに限りません。端末が基地局に接続されていれば、通信のために必要なMACアドレスはずっと電波に乗ってやり取りされることになり、第三者が盗み見ることが可能です。例えば、どこかのカフェに盗聴用の機器を転がしておいて、特定の端末を持った人が現れてカフェのフリーWi-Fiを使い始めたら自分に通知が来るようにするといったことも技術的に可能でしょう。ストーキングが楽になりますね、これでは。

ショッピングモールで大規模なフリーWi-Fiを運用している事業者なら、接続してきた端末のMACアドレスから、個々の端末の動きを分析することもできるでしょう。客の実名などが分からなくても、ある客がこの店に入った後に、別のどこそこの店に立ち寄ったというように、行動分析が可能です。

皆さんがお使いのフリーWi-Fi利用規約に、もしかして、「サービス提供者が行動分析することに同意する」などと書かれていませんでしたか?

「あれ?もしかしたら、フリーWi-Fiの事業者ではない誰かも同じことができるのでは?」―― せーかい!端末の無線LAN機能をオンにしている限り、周囲の誰でもコッソリと行動分析ができてしまいます。

端末ベンダは、データビジネスに強い関心がありながらも、やはりこの状況を放置していたのではプライバシー上の問題があると判断したのでしょう。最近は、Googleでさえ、MACアドレスに限らず端末固有のIDを隠蔽するような仕組みを取り入れており、端末ベンダはプライバシー保護を重視する方向に舵を切ったように見えます。

 

MACアドレスランダム化の実装状況

一口に「MACアドレスランダム化」と言っても、様々なレベルがあります。

プローブリクエストだけの対策を行う、初期のランダム化が、iOS 8で取り入れられました。Windows 10やAndroidでもランダム化が導入されましたが、実際にどの程度のランダム化が行われているかはバージョンによって変わり、必ずしも明確ではありません。

Android 8.0で、プローブリクエスト時のMACアドレスランダム化が導入されました。

Android 9では、接続するSSIDごとにMACアドレスが変化する仕組みが導入されましたが、標準ではオフになっており、管理者オプションでオンにする必要がありました。

Android 10では、これが標準でオンになりました。手元のPixel 3で、WPA2-Enterpriseの環境で調べてみたところ、以下のような動作をするようです。

  • 基地局に接続された後にMACアドレスが変化することはない。
  • 同じSSIDならば、一旦プロファイルを削除して再設定しても、ユーザ名が違っても、同一アドレスになる。
  • ユーザ名が同じでも、違うSSIDならば異なるMACアドレスになる。
  • 端末が再起動されても、プロファイルに紐づけられたアドレスは変化しない。
  • MACアドレスのベンダID部分も変化する。

Android 11では、さらに強力なランダム化が実装されると噂されていましたが、先頃公開された11 betaでは開発者オプションに "Wi-Fi-enhanced MAC randomization" の項が追加されており、SSIDが同じでも、接続するたびに異なるアドレスが用いられるとあります。12では標準でオンになるかもしれません。

When this mode is enabled, this device's MAC address may change each time it connects to a network that has MAC randomization enabled.

(iOS 13.3.1では、まだ、SSIDや接続ごとのランダム化は行われていないようです)

[2020/6/23追記] iOS 14が発表になりましたが、Wi-Fi設定に "Use Private Address" というスイッチが登場したようです。ヘルパーの説明文は "Private Wi-Fi address prevents network operators from tracking your iPhone"。同一SSIDなら同じMACアドレスが使われ、前の接続から24時間以上経つと変化するという情報がありました。(未確認で進行形)

 

変化する行動分析ビジネス

端末ベンダがプライバシー保護に舵を切った以上、利用者の同意を得ずに端末を追跡したり、行動分析したりするといったことは、徐々に難しくなるでしょう。利用者登録のないフリーWi-Fiではなおさらです。プライバシー問題とは関係なさそうなことも、一部できなくなるかもしれません。

従来可能だったことの何々が影響を受けるのかは、どれだけ強力なランダム化が用いられるかに依存します。

プローブリクエストのみのMACアドレスランダム化の場合、例えば以下のことができなくなるでしょう。

  • 同意を得ずに任意の端末を追跡する行動分析 (無線LAN利用を伴わないもの)
  • 特定の端末の待ち伏せ (無線LAN利用を伴わないもの)

SSIDごとにアドレスが変化する場合は、次のようなことも難しくなりそうです。

  • SSIDが異なる基地局の間での、同意を得ない任意端末の追跡
  • 利用者にMACアドレスを事前申告してもらった上での、MACアドレスによるアクセス制限 (注: MACアドレスは利用者が変更できるので、これはセキュリティ対策でもなんでもありません)

ここまでは、まだ、無線LANシステムの正規の管理者にとっても優しいものなのですが、接続ごとにアドレスが変化するようになると、管理者泣かせの問題も生じてきます。

  • 利用者認証のないサービスにおける行動分析
  • ローミング環境において、アカウント発行と認証処理を行う側の事業者(IdP)の協力を得ずに、基地局提供者(事業者)側のみで行動分析
  • ユニーク端末数(利用者数の概算になるのでよく使われる指標)を用いた利用統計

公衆無線LANのソリューションを売り込む通信事業者は、基地局を設置する場所のオーナー (ロケーションオーナーやvenue ownerと呼ばれる) が利用者数を知りたいと言っても、アイデンティティプロバイダ (IdP) の協力無しには難しくなりそうです。

これら以外にも不可能になることが色々と出てくるかもしれませんが、ざっくり言ってしまうと、「利用者の同意と、アカウント発行者の協力を得ないで、行動分析はダメよ」ということでしょう

ところで、利用者の行動分析には、消費行動に基づいたサービスの最適化に加えて、都市計画や災害分析・防災計画などの、重要な応用もあります。これらに対応するには、今後、公衆無線LANシステムをどのように作ればよいのでしょうか。

一つのやり方は、現在でも行われているように、利用者に同意の下で(←ここ重要)端末にアプリなどを導入してもらい、追跡機能を有効にしてもらうことでしょう。しかし、自分が利用者なら、旅行先でいちいち現地のアプリを入れたいと思いますか。この辺に何らかの工夫が必要でしょう。

もう一つは、真正面からのアプローチですが、利用者認証のある公衆無線LANシステムを構築して、IdPとなる事業者から正式に情報提供を受けることでしょう。Passpointを利用する次世代ホットスポット(NGH)や、それを応用したローミング基盤であるOpenRoamingでは、これに利用できる仕組みが準備されています。多数のIdPとデータ提供の交渉が必要になる点が、面倒かもしれません。

ローミング環境におけるプライバシーについては、以前に別記事でも少し触れました。ローミングの仕組みを見れば、サービスプロバイダ(SP)側が自由に取れる情報が、かなり制限されていることが分かると思います。

hgot07.hatenablog.com

 

あとがき

「できることとやっていいことは違う」とよく言われます。無線LANの仕組みに明るい技術者や研究者なら、「こんなデータは簡単に取れるな」などと思い付くでしょうが、リスクの説明も無く、新システムとして提案しておきながら、予想できたはずの問題が起きた時に「使った方が悪い」などと言えるのでしょうか。事業家は、大勢が見落としそうなことを長ったらしい利用規約に書いて、同意を得ているから大丈夫と言えるのでしょうか。プライバシーフリークに気付かれないうちは大丈夫……こうですか?

このエリアでは行動解析をしているから、イヤならWi-Fiをオフにしてね……?常につながる利便性の高い公衆無線LANを目指している業界として、このような運用は本末転倒に見えます。

サービスの開発、立ち上げ、そして運用には、様々な責任が伴います。行動分析は、人権保護・プライバシー保護の観点で、現在盛んに議論されているものです。サービスの設計に十分な慎重さが求められていると言えるでしょう。

 

おわり

プログラミングにはUSB DACで良い音のBGMを♪ - TEAC UD-301とUD-505 -

本稿のポイント

  • TEAC UD-301は、プログラミング等の作業用のBGM環境で音質を改善したい人にお奨めの、デスクトップUSB DAC + 良質のヘッドホンアンプ。
  • UD-301の音は、適度にまとまっていて、コンパクトな外観にしては低域もしっかりしているぶん、BGM的に聞き流すにはむしろ好都合。
  • TEAC UD-505は、さすがに上位機種だけあって格段に解像度が高く、リアルさが出る。スピーカーよりもヘッドホンをよく使う人には絶好のUSB DAC + ヘッドホンアンプ。
  • UD-505の音は、繊細さを重視してチューニングされているせいか、UD-301よりも大きくガッチリしたボディの印象とは反対に、少し音が細く感じられる。じっくり聞きこみたい人向け。BGM用途には、組み合わせる機器を選ぶのが吉。

NO MUSIC, NO WORK.

プログラミング中に、あるいは仕事中に、音楽が手放せない人は少なくないと思います。うちの研究室でも、学生さんの多くは、ヘッドホンやイヤホンをかけて作業していることが多いです。周囲の音が気になるとか、あまり話しかけられたくないということも、あるのかもしれません。

自分の場合、作文中は、ボーカル入りの音楽は思考の邪魔になるので無理ですが、プログラミング中は不思議と気にならないどころか、むしろノリノリで作業できたりします。脳ミソの使う部分が直交しているんですかね、これ?

BGMとは言え、やはり良い音で聞きたいので、CD-ROMドライブのヘッドホン端子 (昔は付いていたんです!) では不満で、仕事場にミニコンポを持ち込んだりしていました。そのうち、手頃な価格帯のCDプレーヤーが軒並み1bit DACになってしまい、その細い音に慣れずに、マルチビットDACにこだわるという沼へ……。

CDプレーヤーを探しながら、ヘッドホン用のアンプも色々と検討し、10年ほど前にはESOTERIC X-25にAccuphase C-2110、そしてULTRASONE Edition 8という組み合わせに落ち着いていました。えぇ、デカいです!重いです!

C-2110にしたのは、よいプリアンプも押さえておきたかったこと、VR位置による音質変化がないというAAVAが気になったこと、そしてここが重要、音質重視のヘッドホンアンプが搭載されていたことでした。プリアンプ内蔵のヘッドホン端子は、大抵はOPアンプによるおまけのようなものが相場です。前段はOPアンプが使われているのに、電力増幅段がディスクリートなだけで、随分と印象が違います。

あー、すみません、前置きが長かったですね。

 

TEAC UD-301

いつまでもCDの音源ばかりではないのと、虎の子のX-25の軸受けがヘタってきたので、次をどうしようかというところで、思い切ってUSB DACにしてみました。あまり吟味しないで、入門用に買ってみたのが、TEAC UD-301でした。CDDA (つまり44.1kHz 16bit 2ch) のrawのままCDからPCに取り込んで、UD-301に流し込んでみたら、これが予想外に結構いける。中高域が少し引っ込みがちなEdition 8でも、カチカチした音がしっかり聞こえる。高域の伸びに若干不足を感じるものの、無理やり伸ばしたみたいなノイジーな音がしないので、むしろ安心して聞いていられます

TEACの音作りなのか、中域のキラキラはあまり期待できませんが、ここがヘタに頑張ると耳障りになることもあるので、むしろBGM向きで良い感じです。小さいながらも、低音も結構踏ん張ります。ヘッドホンアンプ部は残念ながらOPアンプですが、このサイズと価格帯なら仕方ないでしょう。ちなみに、CDDAなら、付帯音が少なく滑らかな4x Fsアップコンバートが推奨です。

なお、女性Jポップ、アニソン、サントラ、洋楽だとPET SHOP BOYSを中心に聞いています。クラシックも聞きますが、いくら楽器で評価が高くても、ボーカルが不自然になるような機材は苦手です。

というわけで、それほど高くもないし、作業BGM用で、PCの音声出力やポータブルオーディオでは不満という人には、お奨めのモデルです。残念ながら、生産完了になってしまいましたが。

 

TEAC UD-505

予想外に良かったのでしばらく気に入って使っていたUD-301ですが、上位機種がある以上、どうしても気になってしまいます。UD-301では、音が少し詰まり気味なのではないかと感じることがあり、上位機種ならもしかして、という気持ちがありました。かといって、UD-503は高いし……うーん_('、3」∠)_

あと、正直言うと、やはりX-25の方がまだキラキラした音が出ていたのですよね。

UD-501の中古品も時々見かけたのですが、こちらはアナログライン入力がなく、ヘッドホンアンプとして使いたかった自分は安くてもスルー。

UD-503も少しずつ値下げされてきて、そろそろかなと思っていたところで、UD-505が登場しました。これでUD-503も買いやすくなるかな?

ここで、人生を変える決定的な違いに気づくのです()。UD-505には、新しいデータ転送方式「Bulk Pet」が搭載されていました。説明にある「パソコンの負荷状態が変わることで音質も変化する……」にはちょっと疑問符ですが、「音途切れなどの問題が発生する可能性がありましたが……」の方は、私、気になります!

というのも、UD-301を使っていて、ほとんど問題は無かったとはいえ、ごくたまに、本当に忘れた頃になのですが、音が一瞬途切れることがありました。これはなかなか興醒めなことです。もし新方式でこのあたりが改善されるなら……という期待が生まれてしまったので、どうせ高い買い物ならUD-505にしようと、80%ほど決心したのです。

折しも、新型コロナウイルス感染症対策の外出自粛下で、色々と欲求が不満しているなかで、めずらしく中古品が出ているのを見つけてしまい、めでたくお迎えすることになりました。

UD-301から切り替えて、最初に音出しをした時の感想は……「???」

UD-301よりも大きく、重く、しっかりしたボディなので、ずっと力強い音が出るのではないかと、誤った方向に期待が膨らみすぎていたようです。

さて、2か月ほど鳴らしてみて、時々UD-301に戻してみての感想は、UD-505の音はちょっと線が細いかなといったところです。繊細さを重視してチューニングされているせいでしょうか。上級機らしく、解像度はずっと高くて、音が団子にならずに綺麗に分離されるところはさすがです。それで、遠慮せずに高域を伸ばしたということでしょうか。

情報量が増えたせいか、聞きこもうとすると、細かい音までよく聞こえることが分かります。反対に、BGM用にズボラに聞こうとすると、音が不必要に遠ざかったり近づいたりするような、ちょっと鬱陶しい感覚がありました。バランスがもう少し低域寄りのヘッドホンがうまくマッチングするかもしれません。好みのレベルですが。

というわけで、冒頭のポイントに書いたとおり、がんばらないでそこそこ良い音をBGM的に流したいのであれば、UD-301はちょうどよいでしょう。もし解像度に不満があるなら、しぬきでUD-505に投資し、用途に合うヘッドホンを探すのが良いと思います。

(音途切れについて、Bulk Petの効果はまだ分かっていません。Isochronous転送より音質は滑らかになるようです)

 

ティアック デュアルモノーラルUSB-DAC Reference UD-301-SP (シルバー) UD-301-SP/S
 

 

 

デスクトップより音楽愛をこめて

WBA OpenRoamingとは何か

Ciscoから始まったOpenRoamingは、少し遠回りをして、Wireless Broadband Alliance (WBA)に譲渡され、このほどWBAよりサービス開始に関するアナウンスがありました。これまでの経緯は「OpenRoamingとは何か ~前夜編~」に書きました。

wballiance.com

wballiance.com

OpenRoamingは、様々な無線LANビジネスに対応できるように、壮大な目標を掲げているものですが、まだ開発中の部分も多いため、掴みどころがはっきりしない点もあります。本稿では、OpenRoamingの基本から、サービスの概要、そして、通信事業者の参加方法を説明します。

OpenRoamingは市民が利用できるセキュアな無線LANローミング基盤

OpenRoamingは、世界中の市民が利用できる、セキュアな公衆無線LANのためのローミング基盤です。大学で教育研究機関向けのeduroamを利用したことのある人には、その全市民版だと思ってもらえば、イメージが掴みやすいでしょう。利用者は、携帯電話会社や無線LANサービスプロバイダとの契約を通じて、公衆無線LANに乗るためのアカウント(またはプロファイル)を取得します。一つのアカウントを取得しておけば、ローミング基盤に参加している世界中の通信事業者の公衆無線LANに、安全かつ自動的に接続できるようになります

複数の通信事業者で、利用者認証の情報をやり取りすることで、公衆無線LANの相互利用が実現できます。このような仕組みを提供するのがローミング機能です。また、参加している通信事業者のグループは、ローミングフェデレーションやローミングコンソーシアムと呼ばれます。OpenRoamingは、次世代ホットスポット(NGH)を基本とするローミングの世界標準規格であると同時に、フェデレーションやサービスと見ることもできます。

ところで、さらりと書きましたが、「セキュア」とは何でしょう?現在の一般的な公衆無線LANサービスは、利用者認証がなかったり、もしあってもセキュリティ的に十分ではないものが用いられています。そのため、偽基地局に誘導されて悪さされる危険性があります。さらに、無線LANが暗号化されていない、あるいは、複数の端末で共通の鍵が用いられているなど、盗聴の対策も不十分です。一方NGHでは、Passpoint (Hotspot 2.0)という規格が用いられており、これはまた、IEEE 802.1Xによる安全な利用者認証がベースになっています。このような仕組みを使うことで、利用者認証の安全性を高めているのに加えて、無線LANの端末ごとの暗号化が実現されます

この辺の話は、以前の記事「Hotspot 2.0 aka Passpoint, それとNGH(次世代ホットスポット)」もご覧ください。

エンドユーザがOpenRoamingを使う方法

先にも書いたように、利用者は通信事業者からアカウントまたはプロファイルを取得する必要があります。

OpenRoamingに参加している携帯電話会社と契約している利用者は、SIMカードに記録された認証情報を利用するEAP-AKA認証などで、公衆無線LANに乗ることができます。PasspointによるSSID自動選択と自動接続の機能により、携帯電話と同様のユーザビリティを確保できるというのがウリです。SSIDが異なる別のホテルや市街地に行っても、手作業でSSIDを設定しなおす必要はありません

無線LANサービスプロバイダの場合は、Passpointの利用に必要となるPasspointプロファイルを事業者のウェブサイトなどから取得し、端末に登録しておく必要があります。一度設定すれば、携帯電話と同様に、SSIDが異なっていても自動接続が可能です。NGHを推進しているBoingoなどの会社が、既にPasspointプロファイルを提供しています。ただし、OpenRoamingはまだ開発中なので、利用できる場所は限られています。

この他にも、インターネットサービスプロバイダなどが対応しさえすれば、OpenRoamingを利用できるアカウント(プロファイル)を入手できるようになります。

教育研究機関向けのローミング基盤であるeduroamについても、OpenRoamingに接続される予定になっており、世界中の市街地の公衆無線LANに乗ることができる日が来るかもしれません。

 

技術仕様

OpenRoamingの技術仕様は、WBA WRIXが基本になっています。WRIXはこれまでに何度か改訂されていますが、現在はWRIX-i, -n, -L, -d, -fの五つのグループで構成されています。これらのうち、ローミングを実現するのに最低限必要なのは始めの三つで、interconnect, network, locationに該当するものです。OpenRoamingでは、無償サービス(settlement free)と、ローミング費用のやり取りが発生するサービス(settled)が規定されますが、後者ではdata & financial clearingに相当する -d, -f も必要になります。

商用かeduroamかを問わず、従来の無線LANローミングにおける認証連携ネットワークでは、RADIUSIPsecが用いられていました。OpenRoamingでは、これに代わって、RadSecとDynamic Peer Discovery (DPD)の組み合わせを使うのが標準となっています。DPDでは、DNSのNAPTRレコードを利用して、事業者間でP2P的にRADIUS連携が可能になります。(RadSecはeduroamでも基幹ネットワークの一部に導入されています)

参加メンバー

OpenRoamingの参加メンバーは、通信事業者またはそれに準じる組織です。OpenRoaming以外のローミングフェデレーションや、都市のフリーWi-Fi事業も、メンバーになれます。

無線LANローミング基盤では、単に相互の利用者認証を実現する技術ばかりではなく、事業者間の信頼関係の構築が必要です。もし、ある事業者が不正を働いたりすれば、他のメンバーや利用者が損害を被ることになるからです。このため、openと名前に含まれていても完全にオープンなわけではなく、個人が自前のIdPを立てて、自宅に基地局を置いてローミングを受け入れるというのは、不可能となっています。認証情報や通信内容の保護のためには、必要な制約です。

自治体や公共施設、ショッピングモールから小さなカフェまで、フリーWi-FiをOpenRoaming対応にすることで、来訪者に安全で利便性の高い無線LANサービスを提供することができます。利用者は行く先々で公衆無線LANにサインアップする必要がなくなります。この場合、組織や店舗がOpenRoamingに直接参加するのではなく、どこかのローミングフェデレーションに所属して間接的にOpenRoamingに参加したり、通信事業者が提供する公衆無線LANソリューションの中でサービスを提供するといった構成が可能です。日本では執筆時点(2020/5/28)でCityroamが唯一のフェデレーションで、このような利用形態をサポートしています。

OpenRoamingに参加するには

OpenRoamingに参加するには、WBAIDを取得する必要があります。WBAIDは、通信事業者やフェデレーションなどを識別するためのIDです。

WBA会員の企業は、無償でWBAIDを取得できます。

その他のフェデレーションや、大都市など、WBA非会員でもOpenRoamingに参加する方法がありますが、これについてはWBAに問い合わせてください。

国内のセキュア公衆無線LANローミング基盤であるCityroamが、OpenRoamingの初期サポータの一つとして参加しました。国内の通信事業者は、Cityroamフェデレーションに参加することでも、OpenRoamingとの連携が可能です。(お問い合わせください)

 

おわり

Windows 10でPasspointが使える無線LANアダプタを探す旅

Windows 10で使える、Passpointに対応した無線LANアダプタを探す話です。Windows 8.1以前はPasspointに対応していないので、諦めてください。

Passpoint (Hotspot 2.0)ってなんぞ?という方は、先にこちら↓をどうぞ。

hgot07.hatenablog.com

手持ちのアダプタがPasspoint対応かどうか調べる方法

ノートPCに内蔵の無線LAN機能や手持ちの無線LANアダプタがPasspointに対応しているかどうかを調べるには、コマンドプロンプトから以下のコマンドを打ち込みます。管理者権限でなくても大丈夫です。

> netsh wlan show wirelesscapabilities

表示された情報の中に「ANQPサービス情報探索」という項目があるはずですが、ここが「サポートあり」の場合は、Passpointに対応しているアダプタです。

え、英語表示がいいですか?それなら

> chcp 437

戻すには

> chcp 932

です (余談すぎる)。

Passpoint対応無線LANアダプタの探し方

ノートPC内蔵の無線LAN機能がPasspoint非対応の場合や、デスクトップPCで無線LANアダプタが付いていない場合は、適切な無線LANアダプタを探す必要があります。

Wi-Fi AllianceのサイトにあるProduct Finderの中で、Advanced Filtersを選択し、"Access"の項目を選ぶと、Passpoint対応製品の一覧が見られます。しかし、新しい製品が登録されていないとか、ここに掲載されているのに実際は使えない製品が混じっているとか、あまり使い物にならないようです。

今のところ、製品カタログの仕様欄には、Passpointや802.11u, Hotspot 2.0の表記はまず見つかりません。困ったものです。

仕方がないので、手元にあるものを手当たり次第試してみるか、実際に使えている人からの情報をかき集めるしかありません

Passpoint対応状況

とりあえず、執筆時点でのお奨めはこちら。TP-Link AC600 Archer T2U Nanoです。少し古いため、2020年中に入手が難しくなってくるかもしれません。

この製品は2.4GHz/5GHz両対応の上、とにかく小さくて使いやすいです。小さいは正義!

ノートPCに挿すと意外に出っ張りますが、他のアダプタと違って、このまま鞄に入れても大丈夫なレベルです。半透明ケースを通してちらつくLEDがまぶしくて、これさえなければいいのに……。

TP-Link Archer T2U Nano

(また、Archer T2U Nanoは、openSUSE Leap 15.1でも2.4GHz/5GHz両方で利用可能なことを確認しています (Passpointの動作は未確認)。ただし、別途ドライバを手作業で入れる必要があります。iw dev wlan0 linkの表示がおかしいです)

(TP-Linkは、無線LANルータの製品群がPasspoint非対応ばかりなので、個人的に好きではないのですが、子機の方は希望に合うものが多い印象です)

手持ちの無線LANアダプタで調査した結果を、以下に示します (随時更新)。

model chip ANQP support
(NEC LaVie Hybrid ZERO HZ750) Realtek 8822BE

yes

(Panasonic CF-SZ6) Intel AC 8265

yes

TP-Link AC600 Archer T2U Nano Realtek 8811AU

yes

TP-Link AC1300 Archer T4U v3 Realtek 8812BU

yes

NEC Aterm WL900U Realtek 8812AU

yes

Buffalo WI-U2-433DM Realtek 8812AU

yes

(Panasonic CF-MX3) Intel AC 7260

no

Linksys WUSB6100M Atheros QCA9377

no

NETGEAR A6210 MediaTek MT7612U

no

Buffalo WI-U2-300D Ralink RT5572

no

ちなみに、表を見てなんとなく分かるように、Passpointのサポート状況は、製品モデルよりも使われているチップに依存します。ドライバの対応状況がそのまま製品仕様になる感じです。チップの情報は以下のサイトで調べることができます。

Passpointってどこで試せるの?

実はWindows 10のPasspoint機能はまだ青々としていて、バージョン2004では少し大規模な変更が入りました。そのため、うまく機能しなくなったPasspointプロファイルもあるようです。

GlobalReach Technologyは最速で新仕様に対応することで定評があるので、同社が提供するデモ用プロファイルを導入してみるのがよいでしょう。

このOdyssysプロファイルで認証が通る基地局が必要ですが、Cityroamが提供するPasspoint (Hotspot 2.0)対応の基地局の幾つかがGlobalReachの国際ローミングに対応しているので、試してみるとよいでしょう。(非対応の場所もあります)

うまくいったら、アダプタの情報とともに、twitterでつぶやいてみてください。

 

 

おわり