hgot07 Hotspot Blog

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

Windowsで使うXMLデータに署名する (xmlsec1編)

Windows用のプログラムを開発していると、XMLデータに署名が必要ということがまれによくあります。ウェブサイトからWi-Fi設定を流し込むプロビジョニングでも、設定用のXMLデータに署名が必要で、まぁなんとも面倒くさいことです。たかがWi-Fi設定にコード署名用のEV証明書(*1)が必要だとか、いったい何を考えて設計したのやら……。

さて、Wi-Fiプロビジョニング用のウェブサイトを作るにあたって、この署名が一つの難関になり、ネット上の情報が乏しいので結構苦戦しました。備忘録を残しておきます。

*1 今のところ……(意味深)
    [2023/5/19追記] Windows 11 22H2から、DV証明書でも署名できるように"改善"されました。

 

XML署名ツール

署名付きXML (SignedXML) を生成するためのツールは色々とあるようです。

  1. WindowsのConvertTo-SignedXml (Windows 8.1 SDKなどに入っている)
  2. xmlsec1などのフリーのコマンド
  3. 有償ツール
  4. 自作品 (!)

今回、オープンソース化が前提で無償でLinuxサーバ上に実装したかったので、ConvertTo-SignedXmlや有償ツールは選外となります。頑張れば自作もできますが、正しく署名できるか検証する必要があるので、まずは既存のツールを探します。

xmlsec1 という署名ツールがありました! (・∀・)

ただし、Linuxのインストール時に自動的に入るようなメジャーなツールではないので、追加のパッケージを探すことになります。開発元はこちら ↓

www.aleksey.com

このxmlsec1、ちょっとクセがあって、使うのがちょっと面倒です。今回、代わりになるものが見つけられなかったのですが、他に良いものがあれば知りたいです。

 

XMLデータに署名してみる

Windowsms-settings: URI スキームで、ウェブサイトから Wi-Fi 設定を行うためには、XMLデータに署名が必要です。この署名の手続きを示します。

元のXMLデータの中身は、こんな感じです。

<?xml version="1.0"?>
<CarrierProvisioning xmlns="http://www.microsoft.com/networking/CarrierControl/v1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Global>
    <CarrierId>{df909a2c-511f-c769-b424-11333792de13}</CarrierId>
    <SubscriberId>1234567890</SubscriberId>
  </Global>
  <WLANProfiles>
    <WLANProfile xmlns="http://www.microsoft.com/networking/CarrierControl/WLAN/v1">
      <name>Example IdP</name>
      <SSIDConfig>
        <SSID>
          <name>GreatAP</name>
        </SSID>
      </SSIDConfig>
      <MSM>
        <security>
          <authEncryption>
            <authentication>WPA2</authentication>
            <encryption>AES</encryption>
            <useOneX>true</useOneX>
          </authEncryption>
          <OneX xmlns="http://www.microsoft.com/networking/OneX/v1">
            <authMode>user</authMode>
            <EAPConfig>
              <EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
                <EapMethod>
                  <Type xmlns="http://www.microsoft.com/provisioning/EapCommon">21</Type>
                  <VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>
                  <VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType>
                  <AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">311</AuthorId>
                </EapMethod>
                <Config>
                  <EapTtls xmlns="http://www.microsoft.com/provisioning/EapTtlsConnectionPropertiesV1">
                    <ServerValidation>
                      <ServerNames>idp.example.jp</ServerNames>
                      <TrustedRootCAHash>ca bd 2a 79 a1 07 6a 31 f2 1d 25 36 35 cb 03 9d 43 29 a5 e8</TrustedRootCAHash>
                      <DisablePrompt>false</DisablePrompt>
                    </ServerValidation>
                    <Phase2Authentication>
                      <MSCHAPAuthentication/>
                    </Phase2Authentication>
                    <Phase1Identity>
                      <IdentityPrivacy>true</IdentityPrivacy>
                      <AnonymousIdentity>anonymous@example.jp</AnonymousIdentity>
                    </Phase1Identity>
                  </EapTtls>
                </Config>
              </EapHostConfig>
            </EAPConfig>
          </OneX>
          <EapHostUserCredentials xmlns="http://www.microsoft.com/provisioning/EapHostUserCredentials" xmlns:baseEap="http://www.microsoft.com/provisioning/BaseEapMethodUserCredentials" xmlns:eapCommon="http://www.microsoft.com/provisioning/EapCommon">
            <EapMethod>
              <eapCommon:Type>21</eapCommon:Type>
              <eapCommon:AuthorId>311</eapCommon:AuthorId>
            </EapMethod>
            <Credentials>
              <EapTtls xmlns="http://www.microsoft.com/provisioning/EapTtlsUserPropertiesV1">
                <Username>user001@example.jp</Username>
                <Password>piyopiyo123</Password>
              </EapTtls>
            </Credentials>
          </EapHostUserCredentials>
        </security>
      </MSM>
    </WLANProfile>
  </WLANProfiles>
</CarrierProvisioning>

この内容が、wifi.xml という名前のファイルに格納されていると想定します。何やらだらだらと長いですが、肝心なのは最後の二行だけなので安心しましょう。1行目のXML宣言を除いた部分が署名の対象になります。

「これを xmlsec1 に読み込ませて署名すればよいだけでは?」
ざんねん!下準備が必要です。

末尾にある </CarrierProvisioning> というタグの前に、以下のようにテンプレートを挿入します。

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue></DigestValue></Reference></SignedInfo><SignatureValue></SignatureValue><KeyInfo><X509Data><X509Certificate></X509Certificate></X509Data></KeyInfo></Signature></CarrierProvisioning>

<Signature>...</Signature> の部分が署名です。Signatureブロックの内側は、無理に一行にまとめないで、改行を入れても大丈夫です。元データの最後のタグが、改行無しに書かれていることに注意します。もしここに改行があると、元データに余計な一行が入ったデータに対して署名が生成されることになります。(今回はどちらでもよいのですが、署名の範囲を注意するという意味で)

 

署名用の鍵と証明書、必要に応じてCA証明書を束ねた、PKCS #12形式のファイルを用意します。以下の例では、パスワードを空にしています。

  $ cat cert.pem ca.pem | openssl pkcs12 -export \
     -inkey privkey.pem -password "pass:" -out signercert.pfx

いざ、署名!

  $ xmlsec1 --sign --pkcs12 signercert.pfx --pwd "" wifi.xml > signed-wifi.xml

 

出来上がった署名付きXMLデータを覗いてみると、Signatureブロックの中で、DigestValueやSignatureValueに値が入っていることが分かります。また、末尾にはPKCS #12形式ファイルに埋め込んだ証明書のデータがBase64エンコードされて埋め込まれています。パブリックCAを使うなら、Root CA証明書は不要のはずです。

 

[2023/5/19追記] xmlsec1で署名するには、RSA形式の証明書が必要です。ECDSA形式には非対応で、署名しようとコマンドを打つと、ずらずらとエラーが表示されます (しかも原因が判りにくい)。

 

おしまい

 

1X認証でPAPを使ってはいけない

???「知ってる。パスワードが平文で送られるからでしょ?」

現場猫「でもサーバ認証があれば大丈夫っしょ、へーきへーき」

 

それでは、現場をご覧ください。

RADIUSサーバが平文パスワードを受け取っている様子

\ User-Password = "piyopiyo" /

頭ではわかっていても、実際に目の当たりにすると迫力が違います。

この時の端末側の設定は、以下のとおりです。

端末側でPAPを設定している例

 

まずはサーバ認証

無線LAN802.1X認証で用いられる EAP (Extensible Authentication Protocol) のうち、EAP-TTLSやPEAPでは、端末と認証サーバ (RADIUSサーバ) の間で互いを認証してTLS接続を確立する Phase 1 と、IDとパスワードを用いたユーザ認証を実施する Phase 2 の二段階の認証があります。

IDとパスワードのやりとりはTLSトンネルで保護された通信路で行われるので、一旦TLS接続が確立すれば、第三者に盗聴される危険性は無くなります (暗号強度のレベルで)。しかし、ここで接続しようとしている基地局と、その裏にある認証サーバは、正規のものでしょうか?端末からサーバを認証するのが、よく「サーバ認証」と呼ばれている処理です。

EAP-TTLSは、サーバ認証を行うことが前提の認証方式です。ところが、端末によっては、サーバ認証を実施しない設定も可能です。手動設定の場合は特にそうですが、なんと、Wi-Fiプロファイルをネットから流し込むようなプロビジョニングでさえ、サーバ認証が有効にならないケースがあります。見つけたところには注意喚起していますが、たぶんあちこちあるでしょう。

というわけで、サーバ認証が無効な場合、偽の認証サーバによってパスワードが窃取される危険性があります。サーバ認証が確実ではないことも想定しておく方が安全です。

 

Phase 2認証の方式

Phase 2認証には、PAP (Password Authentication Protocol) や MSCHAPv2 (Microsoft Challenge-Handshake Authentication Protocol Version 2) などが指定できます。PEAPでは原則としてMSCHAPv2を使います。

それでは、なぜ、パスワードをサーバに平文で伝えるなどという、PAP なんていう代物が生き残っているのでしょうか。EAP-TTLSと言えばPAPというぐらい、どういうわけかメジャーな選択肢になっていました🤔

一昔前の EAP-TTLS の実装で MSCHAP や MSCHAPv2 がまともに動かなかったことが、大きな要因の一つと考えられます。10年ほど前、MSCHAPv2の壊れた実装が市場に流通していて、大変困ったことがあります。

RADIUSサーバの裏にあるデータベースに、MSCHAPv2で使える形式 (NTLM) のパスワードが格納されておらず、平文もないという状況で、どうしても802.1X認証が使いたいという事例もあります。

冒頭のキャプチャ画像にあるとおり、PAPでは端末がRADIUSのUser-Password属性に平文パスワードを詰めてサーバに送ってしまうので、サーバからパスワードが丸見えになります。MSCHAPv2では、端末が保持しているパスワードと、サーバが保持しているパスワードがそのまま相手に送られることはなく、チャレンジ - レスポンスという形でやり取りが進みます。厳密にはMSCHAPv2にも脆弱性が知られているのですが、何もないPAPより、解読の時間稼ぎにはなるでしょう。

 

PAPの悪用例

サーバ側で平文のパスワードが容易に取得できるとなれば、パスワードを窃取する以外にも、様々な攻撃が可能になります。

例えば、端末から送られてきたUser-Passwordの値をそのまま使って、802.1Xの認証を不正に成功させる (Access-Acceptを返す) ことができます(*1)。すると、攻撃者は、自分のLANに端末を接続させて、MITM (中間者) 攻撃や、端末への直接の攻撃が可能となります。

2022年の Wireless Global Congress における FBI の話によれば、暗号化の実装が進んだお陰で難易度が高くなった「盗聴」よりも、基地局や端末などのデバイスの「脆弱性を突く」ことの方が、現実的な攻撃手段とのことです。つまり、攻撃者のLANに端末が接続させられることは高リスク😱 と言えるでしょう。

 

*1 FreeRADIUSの場合、設定ファイルに数行追記するだけで実装可能。

 

対策

とにかく、サーバ認証を確実に行うことが第一です

その上で、サーバ認証が行われない場合に備えて、PAPを使わないようにすることでしょう。

 

EAP-TLS使えよ!」
ごもっともなのですが、それは運用の手間とのバランスの話になるかと思います。(きちんとrevokeまで作り込んでいますか?)

 

おしまい

 

Wi-Fi 6対応VPNトラベルルータGL-AXT1800でPasspointを動かしてみる (成功)

今、GL-AXT1800 (Slate AX)が熱い! (物理)

Wi-Fi 6対応機なので仕方ないのでしょうが、ちょっと発熱が多いです。

2022年頭にGL.iNetから発表された、Wi-Fi 6対応のVPNトラベルルータ GL-AXT1800 (Slate AX)、半導体不足の影響もあってか、なかなか日本で買えるようになりませんでした。首を長くすること6,000ミリか月、やっとAmazonで買えるようになりました。

 

似た型番の GL-AX1800 は立派なツノが生えた据え置き型だったので、せっかく同社から Wi-Fi 6 に対応した製品が出たといっても、ちょっと手が出せませんでした。小さいは正義!さっそく新型の GL-AXT1800 を注文してみました。

(Slateの愛称を持つ GL-AR750S-Ext と比べたら、随分大きくなってしまいましたが……)

このモデル、なんと最初から OpenWrt 21.02 が入ってきます。ということは、19.07ベースだったこれまでの機種と違って、純正ファームウェアのままでPasspoint の基地局として使えそうな予感です。(速攻で買ってもし動かなくても知りませんorz)

GL-AXT1800 (Slate AX)

GL-AXT1800 (Slate AX)

では、早速…… ヾ(⌒(ノ'ω')ノ

 

ギャラリー

Berylと同様に、ゴロンとでかいACアダプタが付いてきます。携帯できなくもないですが、ポケットルータにはちょっと厳しい感じ。本体は意外とずっしり重いです。
※ 以前のBerylの紹介時には、やや不安定な感じがありましたが、現在は大丈夫なはず。

てっきり、Berylと同じ型かと思ったら、一回りちょっと大きかったです。

端子の位置も違う。

裏面がBerylよりもスカスカで、中にファンらしきものが見えます。無線LANを使っていない状態では、まだ回っていません。

GL.iNet純正の管理画面。きびきび動いて好印象です。

ただ、純正の方はあまり細かい設定ができないので、OpenWrtのLuCIを使ってみます。特にパッケージを追加する必要はなく、すぐに使える状態でした。

おぉ、ちゃんと OpenWrt 21.02 ベースです! (超重要)

wpad-basicが入っていたら、フル機能版のwpad-opensslに入れ替えます。入れ替えたつもりだったのですが、パッケージマネージャの動きが少し怪しくて、古い方がAvailableに表示されません。うーん?

とりあえず、sshでログインして、
  # strings /usr/sbin/wpad | grep hs20
で何やらぞくぞく ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ•̫͡•ʕ•̫͡•ʔ•̫͡•ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ 出てきたので、Passpointも大丈夫でしょう。

 

WireGuardを試してみる

そっちが先かよ!?

仕様書は製品紹介ページで。

www.gl-inet.com

や、WireGuardに550Mbpsって書かれているけど、盛り過ぎじゃないですか?

というわけで、早速試してみます。設定は以前の記事と同様ですが、今回は純正ファームウェアのままで行きます。

hgot07.hatenablog.com

あれ、WireGuardのパッケージが二種類ある!? kmod-wireguard-backportの方が標準で入っていたのですが、もしかしたら、21.02でWireGuardの速度が19.07の半分になっていた問題の対策かも。このまま -backport を使ってみます。

 

まずは、GL.iNet版の設定画面を(怖いもの見たさで)見てみます。

 

あぁ、やっぱり_('、3」∠)_

どうやらお仕着せのVPNサービスを使う前提で作られているようです。手作業で高度な仕込みもできるのかと思いきや、何を入力したらよいか分からない画面が出てきます。ひどい……

WireGuardの設定が済んで、リンクアップも正常、ピア間のpingも返る。よーし、次、Speedtest!と思いきや、トラフィックがWireGuard側ではなくLANから出て行ってしまいます🤔  (知ってた)

何やら、特殊なルーティング設定が入っているみたいです。まずは、以前Mangoに仕込んで正常だったもの ↓

純正ファームウェアではこのとおり ↓

コマンドラインから 2001: from all fwmark 0x100/0x3f00 lookup 1 のルールを削除したところ、defaultがWireGuardのトンネルを向くようになりました。

このルールがどこで設定されているのか探ってみましたが、よく分からなかったので宿題。ただ、このままではリブートするたびに手動で直す羽目になって、マネージドWi-Fiとしては失格なので、なんとかします。しました。

mwan3がこのルールを設定していたので、どうせ使わないので、このパッケージを削除(笑)。これで、リブートしてもすべての通信がWireGuard側を通るようになりました。

 

気になる速度はというと、ぎゃぼ!

ほぼカタログスペックの値が出ています。素晴らしい!(・∀・)

研究室内のGbEで、相手は向いの部屋にあるLinux箱(Core i5-4590 @ 3.3GHz)です。CPUが古いせいか、load averageは0.3~0.4ぐらい。GatewayRyzenにしたい……

 

Passpointを動かしてみる

それでは、本題のPasspointの検証を。

設定は以前の記事の通りです。設定内容をブログに残していた自分、えらいぞ。

hgot07.hatenablog.com

ほいきた!

ヽ(・∀・)ノ

Passpoint (Hotspot 2.0) が正常に動いています。接続はどうでしょうか?

接続も無事に成功!

というわけで、Passpointが吹けて、WireGuardでリモート管理と回線保護ができる、安価な Wi-Fi 6 対応基地局が手に入りました。Wi-Fi 6の性能や、多数端末接続時の性能、バンドステアリング、安定性など、無線LAN部分の評価も必要ですが、今回はこの辺で。

 

おしまい

 

 

twitterでマウスホバーによるポップアップが出なくなって困った件 (解決済み)

ウェブ版のtwitterには、利用者のアイコンの上にポインターを持っていくと、その利用者のプロフィールがポップアップする機能があります。ある日、突然これが効かなくなりました

この機能が搭載された頃は、邪魔だと散々の不評だったようです。誰だろうと思った時にわざわざその人のページに行かなくても済む (嫌なものだったらできるだけ見ないで済む) ので、自分は便利に使っていました。ところが、システムに特に何か変更を加えたわけでもないのに、自宅のノートPCだけ、ポップアップが出なくなってしまいました。Firefox Syncで同期している他のPCはどれも正常です。プラグインFirefoxの不具合も疑ってみたのですが、どれもハズレ。Firefoxを一旦アンインストールしてみてもだめ。

似たような症状で困っている人がいないかと検索しようにも、検索語が「ポップアップ」では別の機能の話ばかり出てきます。さぁ、困った……_('、3」∠)_

 

散々探し回って、もう英語しかないと、手当たり次第に検索してみます。あぁ、この機能は hover と呼ばれているのですね。知らないと正解(?)に辿り着けないやつでした。

それで、さらに色々と単語の組み合わせを変えて検索していたところ、タッチスクリーンが付いている機種ではtwitterのマウスホバーが停止されるという情報に行きつきました。ぇ、ウェブサイトでそういうところまで余計なことをしないといけないの……

いや、まて。このノートPCにはタッチパネルなんて付いていないぞ?

 

さらにぐるぐる検索を続けていたら、こんな記事を発見。

www.reddit.com

んー、タイトルはビンゴっぽい。何々?about:configに入って、ui.primaryPointerCapabilities を作って6を入れろと?

またまたー、どうせ他に原因があって簡単には治らないんでしょう?🤔

 

ありゃ、直ったわ (゚∀゚)

 

なんか、ぐっしょり汗をかいたように疲れた。その割に、ワークアラウンドだけで、根本的な解決策は不明。複雑なウェブサイトきらい。

 

おしまい

無線LANの認証もパスワードレスになる

タイトルの通りです

あと、認証はします。(重要)
認証のない無線LANなんて、利用者にとっても、事業者にとっても、危なすぎるので。

 

従来の無線LAN

公衆無線LANでも、学校などのキャンパス無線LANでも、利用者認証のあるシステムではIDとパスワードを使う方式が広く使われてきました。フリーWi-Fiでも、数日立つとメールアドレスの入力を促されるなど、はげしくちょっと面倒くさいです。

学術系の無線LANローミング基盤 eduroam のように、WPA2 Enterprise (IEEE 802.1Xベース、通称1X認証) で自動接続ができるシステムでも、最初のWi-Fi接続設定の段階でIDとパスワード (とその他もろもろ) を打ち込まないといけないことが多いです。

毎年、新学期になると、「eduroamにつなげない」という声がちらほら出てきます。IDやパスワードの打ち間違いもよく観測されていて、「ずっとlと1を間違えていたわ」みたいなことがあります。

1X認証のうち、EAP-TTLSやPEAPといった方式では、サーバ認証の設定が本来必要です。この辺の七面倒くさい設定を楽にしてくれる設定ツールとして、eduroam CAT や geteduroam がありますが、これらも学校から発行されたIDとパスワードを打ち込まなくてはなりません。

いや、これ、面倒でしょう!  (間違えやすいし)

みなさん、機関から発行されたIDとパスワードでログインする方式に、慣らされすぎていません?

 

パスワードレスな無線LAN

ID/パスワードを打ち込まなくても利用者認証される無線LAN、実は身の回りにも少しあります。

最近のキャリアWi-Fiは、SIMカードを使うEAP-AKA認証などが用いられていて、スマホSIMカードを挿すだけで利用できたりします。キャリアごとのプロファイルのインストールが必要な場合もありますが、パスワードとかどこにも出てきません。

「最近の」ということは、昔はどうだったのかというと、ID/パスワードの設定が必要な時期がありました。現在でも、スマホではなくPCを接続しようとすると、ID/パスワードの入力が必要になったりします。

大学によっては、EAP-TLS認証を採用していて、クライアント証明書を端末にダウンロードしてWi-Fi設定を行うこともあります。電子証明書を手入力なんて、無理ですからね。

これから普及が期待されるPasspointやOpenRoamingでは、端末の設定項目が多いために、ID/パスワードの手入力は無理です。そこで、既に接続されている回線を利用して、Passpointプロファイルをダウンロードして、Wi-Fi設定を行うことになります。どんな感じかというと、例えば以下のOnline Sign-Up (OSU)システムで体験できます。

osu.odyssys.net

ボタンをいくつかクリックするだけでWi-Fi設定が完了します。ただし、上記のサービスは利用者の紐付けがないので、匿名利用ということになっています。

これで利用者認証と言えるの?
はい、実はダウンロードしたプロファイルにはEAP-TTLSの設定が含まれていて、ID/パスワードが埋め込まれています。興味のある人は、プロファイルをデコードしてみてください。

カフェなどにあるQRコードでも、ID/パスワード入力なしでつながるのでは?🤔
あー、あれはセキュリティ上、最悪の方から二番目ぐらいです。
WPA2 Enterpriseではなくて、共通鍵を利用するWPA2 Personalが使われています。つまり、利用者認証がない上に、偽基地局問題があります。

 

パスワードレスの無線LANの時代へ

無線LANの利用者認証でも、ID/パスワードの入力を無くせないでしょうか?

ウェブ方面では、最近、パスワードレスが盛んに叫ばれるようになってきました。FIDO2とか、普及にはまだ時間がかかりそうですが。

学校のユースケースを見てみましょうか。まず、利用者は自分の無線LAN用ID/パスワードを知るために、学校の情報システムにログインします……って、あれ?もうログインしていますね。それなら、なんでID/パスワードをコピペしないといけないのでしょうか。

既にログイン済みのシステムがあるなら、電子的手段でWi-Fiプロファイルを端末に仕込めばよいではないですか。

同じことが、SNSのように他の認証システムでログインしてから利用者登録するタイプの公衆無線LANにも言えます。

あっさり解決できそうですね。

ということは、ID/パスワード方式のメリットはないのでは?🤔

現在、利用者が何らかのネット接続手段を持っているというのが一般的になっているので、無線LANに最初に接続するとき (onboardingと呼ばれる) にネットが使えない場面はだいぶ少なくなっているでしょう。しかしながら、外国に行ったら携帯電話網がすぐ使えるとは限らないので、現地で紙ベースでID/パスワードを発行してもらうことがあるでしょう。観光地や会議場の無線LANも同様です。

しかし、セキュリティ強化の観点からWPA2 EnterpriseやPasspointが導入されてきているので、ID/パスワードの手入力の運用は、やはり限界があります。他にネットのない状況で、オープンな無線LANシステムを利用して Online Sign-Up (OSU) を実現する方式が、Wi-Fi AllianceやWireless Broadband Allianceなどをはじめ、業界で検討されています。

個人的には、現地で電子的手段で安全に提示できるアイデンティティがないなら、オンラインでの利用者登録というアプローチには懐疑的です。ただし、人手により利用者の紐付けを行った上で認証コード付きのヴァウチャーを発行する仕組みならば、よい落としどころになりそうな気がします。

 

長ったらしいID/パスワードを利用者に入力させるのは止めましょう!

無線LANもパスワードレスを目指しましょう!

 

スマホは認証デバイスになるし、ウェブサイトのシングルサインオンも利用できそうです。つまり、どこかで認証が既に通っているなら、無線LANのアカウント発行から端末の設定まで、自動化すればよさそうですね。

というわけで、Wi-Fiプロファイルを端末に流し込む仕組みを、自分でも試してみました。ちょっと、というか現状ではかなり(?)面倒くさいのですが、前述のGlobalReachもやっているし、がんばれば可能です😂

Passpointプロファイルのプロビジョニングの例

Passpointプロファイルのプロビジョニングの例

 

余談

そうは言っても、やっぱりID/パスワードが見たいんじゃー!という人もいると思います。自分もそうです。サポート端末以外でも利用できるように、特に大学では、ID/パスワードと設定情報を提供すべきだと考えます。EAP-TLSの場合は、証明書のダウンロード機能も。

 

おしまい

 

FreeRADIUSでLet's Encryptの証明書を使う

WPA2/WPA3 Enterpriseの無線LANで、ID/パスワード認証を使うときは、サーバ認証を行うことが必須または強く推奨されています。

具体的には、EAP-TTLSを使う場合はサーバ認証が必須で、PEAPでもMSCHAPv2のセキュリティが弱いのでサーバ認証が強く推奨されています。詳しくは以前の記事をご覧ください。

hgot07.hatenablog.com

※ タイトルにある組み合わせ、それなりに長いこと運用していますが、もし動かなくなったらごめんなさい。

 

サーバ認証で使うべき証明書

EAP-TTLSやPEAPでは、基地局に端末を接続しようとする際に、まずサーバ認証を行って、これから接続しようとする基地局が正規のものかを確認します。基地局そのものの真贋を確認するのは無理なので、実際は、基地局が正しい認証サーバ (AAAサーバ)につながっているかどうかを確認します。ここで、公開鍵基盤 (PKI, 必ずしも一般公開とは限らない) の電子証明書が使われます。利用者認証が行われるのは、サーバ認証に成功した後です。

利用者認証、というか正確には端末認証を実施するEAP-TLSでは、ID/パスワードの代わりにクライアント証明書が使われます。これは、サーバ認証とは異なるものです。

「サーバ認証用の証明書を取得してRADIUSサーバに導入しろと言われても、どうすればいいの?」
「証明書は買わないといけないの?」

FreeRADIUSの場合、インストールすると自動的に /etc/raddb/certs の下にデモ用の証明書が作成されます。サーバ認証関係の設定は /etc/raddb/mods-available/eap というファイルに書かれています。初期状態ではデモ証明書が使われます。RADIUS proxyとして動作させるだけならこのままでもよいのですが、認証を行う RADIUS IdP として使うなら、デモ証明書を使い続けてはいけません (そもそも60日で期限切れになる)。

certs ディレクトリの中にある設定ファイル ca.cnf と server.cnf を自分のサーバに合うように修正して、証明書を作り直せば、プライベートなPKIとして運用することが可能です。

Enterpriseな無線LANで、できるだけセキュリティを高めたいなら、プライベートCAで発行した証明書を使うのがよいでしょう。ただし、個々の端末にCA証明書をインストールする手間があります。企業などで MDM (Mobile Device Management) を使うならよいのですが、利用者個人が無線LANの接続設定を行う企業やキャンパスの無線LANでは、採用しにくいかもしれません。端末にCA証明書を導入する操作は、セキュリティリスクもあるので、個人に任せるのは少し不安です。

グローバルなパブリックCAを使うのはどうでしょう?

端末には著名なCA証明書がプリインストールされているので、CA証明書を追加でインストールする手間 (とリスク) がなくなります。ただし、同じCAを使う第三者RADIUSサーバを正規のものと認識しては危険なので、ドメイン名を確実に確認する必要があります。つまり、サーバ証明書の発行の際に、ドメイン名と所有者が紐づけられているところに、信頼が生じるという仕組みです。

 

Let's Encryptの証明書でも大丈夫か

Let's Encryptでもドメイン名のチェックはできているので、Let's Encryptで取得したサーバ証明書RADIUSで使っても、大丈夫でしょう。Android無線LANの設定をするときに、CA証明書で「システム証明書を使用」を選び、ドメインを入力するだけという、お手軽設定になります。

サーバ認証の設定

サーバ認証の設定

FreeRADIUSの設定方法

Let's Encryptサーバ証明書の取得は、ウェブサーバ向けの設定ガイドが多数存在するので、そちらをご覧ください。certbotが少しずつ変化しているので、できるだけ新しい記事を探すとよいです。

FreeRADIUSですが、現在の最新版 3.2.0 と、一つ前の 3.0.25 で確認しています。3.0.x 系には、TLS接続が不安定になる致命的な不具合があります。3.2.0 以上を使うべきです。

サーバ証明書の設定は mods-enabled/eap の、tls-config tls-common セクションにあります。

private_key_password = は、たぶん空でよいはず (Let's Encrypt次第)。

private_key_file = には、privkey.pem を指定します。

certificate_file = には、cert.pem を指定します。

ca_file = には、chain.pem を指定……、アレ?

We've got a problem!

Thu Jul  7 13:55:35 2022 : Auth: (31) Login incorrect (eap_peap: (TLS) Alert read:fatal:certificate expired): ...

ど、どうして……

当エントリを起こそうと思い立った理由がこれです。

chain.pem には、CA証明書と中間CA証明書のチェーンが含まれているのが普通です。執筆時点で、chain.pem には2つの証明書が含まれていて、先頭から、中間CA証明書 (CN= R3)、ルートCA証明書らしきもの (CN= ISRG Root X1) です。後者が曲者で、2021年9月に破棄された古い証明書 (CN= DST Root CA X3) で署名されていました

Apache HTTP Serverに仕込んで、ブラウザで証明書の情報を見ると、ISRG Root X1 が新しく自己署名証明書になっているのが分かります。

というわけで、chain.pem の先頭にある R3 の証明書だけ残して、後半を新しい方に差し替え、これを ca_file に設定します

今度は無事に動きました (゚∀゚)

 

めでたし めでたし

 

余談

EAP-TLSでは、サーバ認証とクライアント認証で、異なるPKIを使うことができます。というか、クライアント認証にパブリックCAを用いるのは、セキュリティ的に問題があります。mods-enabled/eap 内に(ちょっと不親切な)コメントがあります。

従って、選択肢は二つ。

  • サーバ認証とクライアント認証、両方にプライベートCAを用いる。
  • サーバ認証にパブリックCA、クライアント認証にプライベートCAを用いる。

運用コスト次第ですが、後者も妥協点として悪くないようです (とある識者の技術指導 より)。

 

certbot 1.6以上には --preferred-chain "ISRG Root X1" なるオプションがあるそうで、これでもいけるかな?

5G-USBドングル APAL Tributo 5G を試す

[2023/3/22追記] 続編も書いたのでどうぞ。

 

ひょんなことからNICT Beyond 5Gの委託研究に関わることになりました。自分はWi-Fiローミング専門なのですが、セルラーWi-Fiの連携を図るという課題で、セルラー側を担当している共同研究者に感化されて(笑)、5Gでも遊んでみようかなという気になってきました。

可搬型Cityroam基地局を作るのに、上流回線がLTEでは物足りないので、5Gを試してみたいという気持ちもありました。

検証機として借りたのがこちら。

\ ババーン! /

APAL Tributo 5G USB dongle

APAL Tributo 5G USB dongle

ちゃんと技適取得済みですが、一般向けの販売チャネルはまだまだのようです。技適があるからといって、技適マークのないものを入手して国内で使うのは違法ですよ!ちゃんと技適対応の業者から入手しましょう。

手元に5G対応のSIMがなかったので、今回、ONEモバイルONEに5Gオプションを申し込んで、これで試してみました。サマリはだいたいこんな感じです。

  • WindowsでMBIMモードで動く。
  • SIMロックフリー (今回OCNモバイルONE (5G)とIIJモバイルサービス/タイプI (LTE)のドコモ回線のみで確認)
  • LTEドングルの倍ぐらいの容積がある (仕方ない)。ファン付き。
  • 定格5V 3AなのでUSB Type-C接続推奨。
  • 5Gは、ドングルの特性というより、環境の影響を受けやすいので評価できていない。

 

どんな製品か

執筆時点で、5G対応かつ技適対応のドングルはまだこれ一択といった感じです。

詳しい製品紹介は本家でどうぞ。台湾の製品です。

www.apaltec.com

サイズ感、動作音、電源など

LTE-USBドングルの倍ぐらいの大きさで、USBコネクタで支えるのが無理なサイズ。短いUSB Type-Cのケーブルが付属しています。中身は Qualcomm Snapdragon X55。

Tributo 5G

Tributo 5G

付属ケーブルによる接続

付属ケーブルによる接続

冷却ファンが入っています。LTEで動作中は回らないようですが、5Gを掴んでしばらくすると軽くミーと鳴き始めます。軽量ノートPCの冷却ファンはシャーと結構大きな音がするものが多いですが、それと比べればずっとかわいいもので、会議場で顰蹙を買うことはなさそうです。

一旦ファンが動き始めると、低負荷になっても止まることはないみたいです。

電源の定格が5V 3Aと、大喰らいですが、ちんちんに熱くなるといったことはなさそう (要追加調査)。電源容量には気を付けてと、メーカーより注意あり。

 

ドングルの動作モード

WindowsではMBIMモードで動きます。ハードウェア自体はRNDISにも対応しているらしいのですが、一般利用者が切り替える手段は提供されていません。macOSでの動作は今回確認していません。

MBIMモードで動作するということで、なんと嬉しいことに、無線LANのSIM認証が使えます!(・∀・)  もちろんSIM認証に対応したキャリアとWPA2 Enterpriseのローミング対応基地局でないと使えませんが。

もしRNDIS対応ならMikroTik hAP acでも使えるのですが、残念ながらhAP acにTributo 5Gを挿しても反応無しでした_('、3」∠)_

 

5Gで使ってみる

ドコモのサービスエリアマップを眺めてみたら、自宅はエリアの縁にあり、微妙でした。室内では、ごくたまに5G表示になるものの、すぐにLTEに落ちてしまうので、ぎりぎりアウト_('、3」∠)_

おや、青葉山駅の周辺にポツンと5Gエリアが!(゚∀゚)

5Gエリア 青葉山駅

5Gエリア 青葉山駅

残念ながら入居している建物はエリア外で、ピクリとも動きませんでした。駐車場に出たら、おや、5G表示が…… (初体験)

Pixel 6で5G

Pixel 6で5G

Pixel 6でSpeedtest

Pixel 6でSpeedtest

深夜ですが、Pixel 6では190Mbps出ていました。

Tributo 5Gは少し感度が低いのか、アンテナピクトが1, 2本しか立たない状態でした。

Windows 10で5G接続

Windows 10で5G接続

とりあえず、いま5Gで大人気のSpeedtestで測ってみましょう。

まぁ、LTEより速いのですが、80~120Mbps台と安定しません。エリア外なので仕方ないです

Speedtest (エリア外)

Speedtest (エリア外)

気を取り直して、エリアど真ん中に移動してみます。あれかな? (基地局ソムリエさん、よろしく)

5G基地局?

5G基地局

5G基地局らしきもの

5G基地局らしきもの

この場所ではアンテナピクトが3本立ちましたが、速度はまだ120Mbps台。お前の本気はこんなものではないはずだ。

どうやら広場方向を向いているようなので、そちらに移動してみます。

5Gテストエリア()

5Gテストエリア()

青葉山駅前

青葉山駅

ぉ……(・∀・)

 

アンテナピクト

アンテナピクト

Speedtest結果

Speedtest結果

物足りない感じの結果を目の当たりにした顔をしながら、一旦テストは終了です。

これ、おそらくドングルではなくて、無線環境か回線の方が頭打ちになっている気がします (要追加調査)。

LTEよりは確実に速いので、5Gエリアのど真ん中に住んでいる(?)人で、Windowsに5Gを追加したい人には、良い製品でしょう。半導体不足によりLTE-USBドングルが手に入りにくくなっているので、その代わりにもなりそうです。

自分の委託研究では、Local 5Gの基地局も建てる予定です。そちらの環境なら、ずっと詳しいデータが取得できると思います。

 

おしまい

 

[2023/3/3追記] Compalの中の方から、Amazonで扱い始めたという情報を得ました。販売元が Palcom International Corporation (Compalの製品販売子会社) なことを確認してください。技適シールも貼られていると聞いています (私自身は未確認)

[2023/3/20追記] 試しにAmazonで買ってみたら、ちゃんと技適シールが貼られたものが届きました (ただし自己責任でどうぞ)。なお、日本向けは専用ラインで製造しているとかで、台湾で買っても日本の技適シールはないそうです。

Amazonで購入したTributo 5G

Amazonで購入したTributo 5G