キー入力の盗聴と注入を防ぐ無線キーボードとマウスの選び方

キーボードとマウスは、パスワードもワンタイムコードも社内文書も、すべてが通過する入力の入口です。無線化すると便利さと引き換えに、その入力が電波として机の外へ出ていきます。電波が暗号化されていない、あるいは暗号化の実装に穴がある製品では、離れた場所から打鍵内容を読み取られたり、逆に勝手なキー入力を送り込まれたりします。

この記事は、無線入力機器で実際に報告されてきた盗聴と注入の仕組みから始めて、2.4GHz独自プロトコルとBluetooth Low Energyの違い、Logitech UnifyingとLogi Boltの関係、MicrosoftのAES暗号化の公式記載、有線に戻すという判断、受信機のファームウェア更新、企業での持ち込み機器の統制、共有オフィスやKVM環境での注意までを、情報システム担当と実務者が判断できる形に並べます。記述はBastilleの研究発表、JVN、NVD、Logitechの公式文書、NIST SP 800-121、Bluetooth SIG、Microsoftの技術資料で確認できた範囲に限り、確認できなかった数値や製品仕様は書きません。なお本記事はアフィリエイトリンクを含みます。紹介する製品の効果や適合性を保証するものではなく、購入判断はご自身の用途に照らしてお願いします。詳細は広告およびアフィリエイトについてをご覧ください。

先に、接続方式ごとの性格を一覧にします。

無線入力機器で何が起きているか#

無線キーボードは、押されたキーを短い無線パケットにして受信機(USBドングル)へ送ります。受信機はそれをUSBのHID入力としてOSへ渡します。この経路のどこにも認証と暗号化がなければ、同じ周波数を聞いている第三者にはパケットの中身が見えますし、同じ形式のパケットを作って受信機へ送れば、OSからは正規の利用者が打鍵したように見えます。盗聴と注入はこの単純な構図から生まれます。

Bastille Networksの研究チームは2016年2月23日にMouseJackを公開しました。同社の解説は、検査した無線マウスのいずれも通信を暗号化していなかったこと、暗号化されたキーボードであっても強制ペアリングやキー入力注入の経路が残る機種があったこと、攻撃者は最大100メートル離れた場所から攻撃を開始できることを述べています。影響を受けたベンダーとしてAmazonBasics、Dell、Gigabyte、HP、Lenovo、Logitech、Microsoftが挙げられ、対処としてはLogitechとLenovo 500向けにファームウェア更新が用意された一方、他のベンダーのドングルはファームウェア更新に対応していないため、影響を受けるドングルを直ちに外して有線のキーボードとマウスを使うよう勧めています。同じ解説には、Bluetoothはまったく異なる伝送と暗号化の仕組みを使うためこの攻撃の影響を受けないという記述もあります。

BastilleのMouseJackの解説は、検査した無線マウスのいずれも無線通信を暗号化していなかったこと、攻撃者が最大100メートル離れた位置から攻撃できること、影響を受けるUSBドングルを直ちに外して有線のキーボードとマウスを使うべきこと、LogitechとLenovo 500以外のベンダーのドングルはファームウェア更新に対応していないこと、Bluetoothはこの攻撃の影響を受けないことを記載しています。

同年にBastilleが公開したKeySnifferは、盗聴に焦点を当てた別の一連の脆弱性です。同社の解説は、影響を受けたキーボードが暗号化されていない無線プロトコルを使っていたため、攻撃者が数百フィート離れた場所から100ドル未満の機材で打鍵内容をすべて読み取れたこと、対象がAnker、EagleTec、General Electric、Hewlett-Packard、Insignia、Kensington、Radio Shack、Toshibaの8社の製品であったこと、使われていたトランシーバーがファームウェア更新に対応していないため修正の手段がなく、Bluetoothか有線へ切り替えるしかないことを述べています。Bluetoothと違って独自方式には従うべき業界標準がなく、各ベンダーが独自にセキュリティ方式を実装している、という指摘もこの解説にあります。

BastilleのKeySnifferの解説は、対象製品が2.4GHz ISM帯でGFSK変調の暗号化されていないプロトコルを使っていたこと、数百フィート離れた位置から100ドル未満の機材で打鍵を傍受でき、キー入力の注入も可能であったこと、影響製品のトランシーバーがファームウェア更新に対応しないためBluetoothか有線のキーボードへ切り替える必要があることを記載しています。

国内向けには、JPCERT/CCとIPAが運営するJVNが2016年2月25日にJVNVU#99797968として注意喚起を出しています。この文書は、複数の開発者が提供する無線接続のキーボードやマウスが2.4GHz帯の独自プロトコルを使い、その暗号化に不備があるため、無線の到達範囲にいる攻撃者がキー入力を送りつけたり打鍵内容を傍受したり別の入力機器をペアリングさせたりできること、Bluetooth機器はこの問題の影響を受けないこと、無線の有効範囲は室内で使う多くの場合に数メートル程度であることを記載し、CVSS v3の基本値を6.3としています。

JVNVU#99797968(2016年2月25日公開)は、複数の無線入力機器が2.4GHz帯の独自無線プロトコルで暗号化に不備を持ち、到達範囲内の攻撃者によるキー入力の送信、打鍵内容の傍受、別機器のペアリングが可能であること、Bluetooth機器は影響を受けないこと、ロジクールが修正ファームウェアを公開していること、他のモデルの利用者は更新までの間に個々のユースケースと脅威モデルを考慮する必要があることを記載し、CVSS v3基本値を6.3と評価しています。

ここで押さえておきたいのは、盗聴と注入は別の脅威だという点です。盗聴は打鍵内容の漏えいで、パスワードや認証コードがそのまま読まれます。注入は受信機が攻撃者のパケットを正規の入力として通してしまう問題で、画面ロック中でなければ、コマンドの実行や設定の変更が利用者の手を借りずに進みます。マウスは打鍵内容を持たないので盗聴の被害は小さい一方、マウスの受信機がキーボードのパケットも受け付けてしまう実装では、注入の入口になります。マウスだけ無線という構成でも、受信機の実装によっては安全とは言えないわけです。

Logitech Unifyingの脆弱性と修正の範囲#

2.4GHz独自方式の中で最も普及したもののひとつがLogitechのUnifyingです。独自のAES暗号化を持ち、ひとつの受信機に複数の機器をペアリングできます。この方式については、2019年にセキュリティ研究者のMarcus Mengs氏(GitHub上のmame82)が一連の脆弱性を報告し、NVDにはCVE-2019-13052、13053、13054、13055の4件が2019年6月29日付で登録されています。NVDの記述と評価は次のとおりです。

NVDのCVE-2019-13052は、Logitech Unifying機器がキーボードと受信機のペアリングを傍受された場合にリアルタイムの復号を許すと記述し、CVSS 3.0の基本値を6.5(AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)としています。CVE-2019-13053は暗号化を迂回したキー入力注入を、CVE-2019-13054はR500プレゼンターのAES鍵特定を、CVE-2019-13055は一部のUnifying機器からのAES鍵とアドレスのダンプを記述し、いずれも基本値6.5です。

Logitechの公式サポート記事は、この報告に対する同社の対応を次のように整理しています。報告された3つの問題のうち2つは機器と受信機の間の通信を守る暗号鍵の抽出に関するもので、残る1つはキー入力注入の障壁を乗り越えるものであること、再現には専門知識と特殊な機材が必要で10メートル以内にいる必要があり、誰かが機器を受信機へ再ペアリングしている数秒の間に行動するか、対象の機器やコンピュータへ物理的にアクセスする必要があること、そしてCVE-2019-13053と13052については他のUnifying機器との相互運用性に悪影響が出るためファームウェア更新では対処しないこと、2019年8月以降に公開されたファームウェア更新がCVE-2019-13054/55に対処していることです。Linux向けにはLinux Vendor Firmware Service(fwupd.org)経由で更新ファームウェアを配布するとも記載されています。

Logitechの「Logitech Unifying Receiver Update」は、2019年に研究者から報告された3件の問題について、2件が暗号鍵の抽出、1件がキー入力注入の障壁の突破に関するものであること、再現には専門知識と機材と10メートル以内の距離が必要であること、CVE-2019-13053と13052は他のUnifying機器との相互運用性への影響を理由にファームウェア更新で対処しないこと、2019年8月以降のファームウェア更新がCVE-2019-13054/55に対処していること、対象はUnifyingのマウスとキーボードに加えてSpotlightとR500プレゼンターであり、Lightspeedゲーミング製品も鍵抽出の脆弱性に関係すること、再ペアリングは10メートル以内に不審な動きがないと確信できるときにだけ行うべきことを記載しています。

研究者側の公開資料も同じ整理をしています。Mengs氏がGitHubで公開した既知の脆弱性の一覧は、ペアリングの傍受による鍵取得(RFのみ、ベンダーからの修正なし)、鍵を知らずに行う暗号化されたキー入力注入(修正なし)、受信機からの鍵の抽出(物理アクセス、修正が提供される)、プレゼンター受信機からの鍵の抽出(物理アクセス、修正が提供される)、強制ペアリングという項目に分けて記述し、CVE-2016-10761(MouseJack時のKeyJack)については受信機がAES CTRカウンタの増加を強制していなかった問題で、RQR12とRQR24の受信機向けに修正があると書いています。

Marcus Mengs氏(mame82)の「Summary / Overview of known Logitech wireless peripheral vulnerabilities」は、平文のキー入力注入、暗号化された注入(修正済みのものと修正なしのもの)、ペアリング傍受による鍵の受動的取得(修正なし)、受信機とプレゼンター受信機からの鍵の能動的取得(物理アクセス、修正提供予定)、強制ペアリングの各項目を整理し、CVE-2016-10761は受信機が連続するRFフレームでAES CTRカウンタの増加を強制していなかった問題でRQR12とRQR24の受信機向けに修正が存在すると記述しています。

この一連の話から、実務では次の三点が導かれます。第一に、Unifying受信機のファームウェアが2019年8月以降のものに更新されているかどうかで、物理アクセスによる鍵抽出の可否が変わります。第二に、更新しても、ペアリングの瞬間を傍受されれば以後の通信を復号されうるという性質は残ります。Logitech自身が、再ペアリングは周囲に不審な動きがないと確信できるときだけ行うよう案内しているのはこのためです。第三に、受信機は小さく、抜き差しが容易で、共有のPCや会議室の端末に挿しっぱなしになりやすい部品です。物理アクセスが前提の脆弱性は、物理アクセスが容易な場所ではそのまま現実の脅威になります。

Bluetoothの安全性はペアリング方式で決まる#

Bluetoothなら安全、という言い方は半分だけ正しいです。Bluetooth Low Energy(LE)には仕様で定められたセキュリティモードとレベルがあり、どのレベルで接続されているかで守られ方が変わります。

NIST SP 800-121 Rev.2「Guide to Bluetooth Security」(2017年5月公開、2022年1月19日更新)は、LEのSecurity Mode 1について、Level 1はセキュリティなし、Level 2は認証なしペアリングと暗号化、Level 3は認証付きペアリングと暗号化、そしてBluetooth 4.2で追加されたLevel 4は認証付きのLE Secure Connectionsペアリングと暗号化を要求すると説明しています。そのうえで、Security Mode 1 Level 4はペアリングにAES-CMACとP-256楕円曲線を、暗号化にAES-CCMを使うため、NISTはこれを最も安全なモードとみなし、4.2のすべてのLE接続で使うことを強く推奨しています。4.0と4.1のLE接続についてはSecurity Mode 1 Level 3を強く推奨し、Level 1は決して使うべきでないとしています。

見落とされやすいのが、同じ文書の3.2.2節にある「認証」と「盗聴保護」の区別です。NISTは、4.0と4.1のLEペアリング(4.2でLE Legacy Pairingと改称)がECDHを使わず盗聴保護を持たないため、128ビットの一時鍵を使うOut of Bandを除くすべての方式でLegacy Pairingは破られたものとみなすべきであり、攻撃者がペアリングのフレームを捕捉できれば結果のLTKを求められる、と書いています。Legacy Pairingである限り、パスキーを打っても、ペアリングを傍受されれば以後の通信を復号されうるわけです。盗聴保護が要る場合はLE Secure Connectionsのペアリングを使うべき、というのがNISTの結論です。

中間者保護についても、現在の仕様はLegacy PairingのPasskey Entryを認めていません。Bluetooth Core Specification 6.2のSecurity Manager仕様(Vol 3, Part H)は、IO能力と鍵生成方式の対応表(Table 2.8)でLegacy PairingのPasskey Entryを認証なし(Unauthenticated)に分類し、2.3.1節で、Legacy Pairingで認証付きの中間者保護が得られるのは128ビットのエントロピーを持つOut of Bandだけ、LE Secure ConnectionsではPasskey EntryとNumeric Comparison(およびOut of Band)で得られると整理しています。Core 5.4から6.1までの同じ表ではLegacy PairingのPasskey Entryが認証あり(Authenticated)とされていましたが、Legacy PairingのPasskey Entryの節には5.4の時点で能動的な中間者攻撃への保護を提供しないという記述があり、6.2で表がこれに合わせて改められた形です。したがって、Legacy Pairingではパスキーを打っても、盗聴保護と中間者保護のどちらも前提にしないのが現在の仕様に沿った読み方です。

Bluetooth Core Specification 6.2のVol 3, Part H(Security Manager Specification)は、Table 2.8(Mapping of IO capabilities to key generation method)でLE Legacy PairingのPasskey EntryをUnauthenticated、LE Secure ConnectionsのPasskey EntryをAuthenticatedと記載し、2.3.1節でLE Legacy Pairingの認証付き中間者保護は128ビットのOOBデータエントロピーを持つOut of Band方式でのみ得られ、LE Secure ConnectionsではPasskey EntryまたはNumeric Comparison(あるいはOut of Band)で得られると記載しています。2.3.5.3節にはLegacy PairingのPasskey Entry方式が能動的な中間者攻撃への保護を提供せず、盗聴者に対してもごく限られた保護しか提供しないと書かれています。

NIST SP 800-121 Rev.2(upd1)は、LEのSecurity Mode 1 Level 4がLE Secure Connectionsの認証付きペアリングと暗号化を要求し、ペアリングにAES-CMACとP-256楕円曲線、暗号化にAES-CCMを使うため最も安全なモードであり4.2のすべてのLE接続で使うことを強く推奨すると述べ、4.0と4.1ではLevel 3を推奨し、Level 1は決して使うべきでないとしています。3.2.2節では、LE Legacy PairingがECDHを使わず盗聴保護を提供しないため、128ビットTKのOOBを除く全方式で破られたものとみなすべきであり、ペアリングフレームを捕捉した攻撃者がLTKを求められること、盗聴保護が必要ならLE Secure Connectionsのペアリングを使うべきことを記載しています。また、4.2で追加されたSecure Connections Only Modeが4.0と4.1のLE機器と後方互換性を持たないこと、Just Worksペアリングは中間者保護を提供しないためLEでは使うべきでないことも記載しています。

ペアリング方式の違いも同じ文書に整理されています。LEのペアリングにはOut of Band、Passkey Entry、Just Worksがあり、4.2でLE Secure Connections限定のNumeric Comparisonが加わりました。Just Worksは、ペアリングする機器の少なくとも一方に表示も入力もない場合に使われる方式で、利用者が計算値を両方の機器で照合せずに接続を受け入れるため、中間者攻撃に対する保護がありません。NISTの脆弱性一覧は、Just Worksペアリングは中間者攻撃者にデータの捕捉と改変を許すため、LE機器は盗聴と中間者攻撃の危険を減らせる安全な環境でペアリングすべきであり、Just WorksはLEでは使うべきでないと明記しています。

Bluetooth SIGの解説記事も、LE Secure ConnectionsがBluetooth Core 4.2で導入された強化ペアリング機能で、鍵生成にFIPS準拠の楕円曲線Diffie-Hellmanを使うこと、対応する関連付けモデルがJust Works、Numeric Comparison、Passkey Entry、Out of Bandの4つで、Numeric ComparisonはLE Secure Connectionsだけに存在し、両機器に表示された6桁の値を利用者が照合することで中間者攻撃への保護を提供することを説明しています。

Bluetooth SIGのブログ「Bluetooth Pairing Part 4」は、LE Secure ConnectionsがBluetooth Core 4.2で導入され、FIPS準拠のECDHで鍵を生成すること、Just Works、Numeric Comparison、Passkey Entry、OOBの4つの関連付けモデルに対応すること、Numeric ComparisonはLE Secure Connections限定で6桁の確認値を両機器で比較する方式であり、盗聴と中間者攻撃への保護を高めることを説明しています。

ここから、キーボードとマウスの違いがはっきりします。キーボードには数字を入力できるキーがあるため、LE Secure ConnectionsであればPasskey Entryで認証付きのペアリングができます。OSがキーボードのペアリング時に6桁の数字を表示して打たせるのはこの手続きです。一方、マウスには数字を入力する手段も表示もないため、OSへ直接つなぐ場合はJust Worksになりやすく、そのペアリングは認証されません。Logi Boltのホワイトペーパーもこの構図を認めており、Boltのマウスをレシーバー経由でつなぐ場合はSecurity Mode 1 Level 4、Bluetoothで直接ホストにつなぐ場合はSecurity Mode 1 Level 2(ホストが対応する場合)で、マウス向けのパスキーペアリングの業界標準がないためJust Worksが使われると書いています。Boltのキーボードは直接接続でLevel 3、レシーバー経由でLevel 4です。

ここで前節の区別が効いてきます。Level 3は「認証付きペアリングと暗号化」であって、LE Secure Connectionsを要求するのはLevel 4だけです。守られ方は二つに分けて考えます。ひとつは電波を受動的に傍受する盗聴への保護で、NISTがその根拠としているECDHの鍵交換はLE Secure ConnectionsならJust Worksでも行われます(ただし認証されないためLevel 2)。もうひとつはペアリング時の中間者攻撃への保護で、こちらはPasskey EntryやNumeric Comparisonによる認証付きのLE Secure Connectionsが必要です。パスキーを打ったからといって、ホストと機器の組み合わせがLegacy Pairingで動いていれば、前節のとおり盗聴保護はなく、現在の仕様では中間者保護も認められていません。両方を求めるなら、ホストと機器の双方がLE Secure Connectionsに対応し、実際に認証付きで接続されていること(Level 4)が条件になります。レシーバー経由のLogi Boltがこれを強制する一方、OS直結ではホストのBluetoothスタックと機器の実装に依存し、どの方式で接続されたかを利用者が確かめる手段はOSごとに異なります。

つまり、同じBluetoothでも、レシーバーを介して認証付きLE Secure Connectionsを強制する方式と、OSに直接つないでJust WorksやLegacy Pairingで済ませる方式では守られ方が違います。Bluetooth直結を選ぶなら、キーボードはLE Secure Connectionsに対応したホストと機器の組でパスキーによる認証付きペアリングを行い、マウスは認証されない接続だという前提で、ペアリングの場所と時間を選ぶことになります。暗号の仕組みそのものの復習はこちらの記事にまとめています。

あわせて読みたい

暗号化の基礎。共通鍵・公開鍵・ハッシュ・TLSはどう情報を守るのか

Logi Boltが公式文書で約束していること#

LogitechがUnifyingの後継として法人向けに展開しているのがLogi Boltです。公式の技術紹介ページは、Logi BoltがBluetooth Low EnergyのSecurity Mode 1 Security Level 4(Secure Connections Onlyモード)と、Logi Bolt USBレシーバーへ機器をペアリングした際の脆弱性を減らす追加のセキュリティ機能を組み合わせたものであること、FIPS 140-2に準拠すること、ひとつのLogi Boltレシーバーに最大6台のLogi Boltのマウスとキーボードをペアリングできること(ホワイトペーパーは同時にアクティブな接続を3台までとしています)、無線到達距離が最大10メートルであること、直接Bluetooth接続ではBluetooth Low Energy 4.0以上のホストと通信できること、そしてLogi Bolt製品は他のLogitech USBレシーバーとペアリングできず、その逆もできないことを記載しています。

Logitechの「Logi Bolt Wireless Technology」は、Logi BoltがBluetooth Low EnergyのSecurity Mode 1 Security Level 4(Secure Connections Onlyモード)をLogi Boltレシーバーとのペアリング時に強制すること、FIPS 140-2準拠であること、1台のレシーバーに最大6台をペアリングできること、到達距離が最大10メートルであること、直接Bluetooth接続ではBluetooth Low Energy 4.0以上のホストに対応すること、Logi Bolt製品は他のLogitech USBレシーバーと相互にペアリングできないことを記載しています。

ホワイトペーパー「LOGI BOLT Secure, robust wireless connections」はもう少し踏み込んでいます。Level 4が認証付きLE Secure Connections(LESC)の暗号化ペアリング、具体的にはECDH P-256とAES-128-CCM暗号化を使うこと、マウスとキーボードとUSBレシーバーの間の通信が常に暗号化されること、Logi Bolt製品は工場出荷時に同梱のレシーバーとペアリング済みで暗号鍵も工場で書き込まれること(別のLogi BoltレシーバーへつなぐときはLogi Options+でペアリングする)、レシーバーがSecure Connections Onlyモードを強制すること、ペアリング時の認証にLESCパスキーを使い、それがマウスにも拡張されていること(技術仕様の表ではマウスが10クリックのパスキーで2の10乗のエントロピー、キーボードが6桁のパスキーで2の20乗のエントロピー)、そしてファームウェア更新のうちセキュリティに関わる更新は巻き戻しできない(anti-rollback DFU)ことが書かれています。ペアリングが試みられると利用者に新しい機器の通知が出るという記述もあります。

Logitechのホワイトペーパー「LOGI BOLT Secure, robust wireless connections」は、Logi BoltがBluetooth Security Mode 1 Level 4(Secure Connection Onlyモード)で設計され、Level 4が認証付きLE Secure Connectionsの暗号化ペアリング(ECDH P-256とAES-128-CCM)を使うこと、機器とレシーバー間の通信が常に暗号化され工場出荷時に同梱レシーバーとのペアリングと鍵の書き込みが済んでいること、別のLogi BoltレシーバーへのペアリングにはLogi Options+を使うこと、レシーバーがSecure Connections Onlyモードを強制すること、認証にLESCパスキーを使いマウスは10クリック(2の10乗)、キーボードは6桁(2の20乗)であること、Bluetooth直接接続ではマウスがLevel 2でJust Works、キーボードがLevel 3であること、ペアリングの試行時に新しい機器の通知が出ること、セキュリティ更新は巻き戻せないanti-rollback DFUを備えることを記載しています。

Unifyingで問題になった点にどう対処したかは、Logitechのサポート記事「Did Logitech fix Logitech Unifying wireless security issues in Logi Bolt?」が答えています。Secure Connections Onlyモード(Security Mode 1、Security Level 4)の使用によって通信が暗号化と認証の両方で守られること、リンク暗号鍵のような機微なデータはLogi Bolt USBレシーバーに保存される際に保護されること、レシーバーは新しい機器を受け入れるためにペアリングモードに入る必要があり、攻撃者が利用者をだましてペアリングモードにさせたとしても、ホスト画面上に変更があったことを警告するソフトウェア機能を含めたことが記載されています。

Logitechのサポート記事は、Logi BoltがSecure Connections Onlyモード(Security Mode 1、Security Level 4)により通信を暗号化と認証で保護すること、リンク暗号鍵などの機微データがLogi Bolt USBレシーバー上で保護されて保存されること、レシーバーは新機器の受け入れにペアリングモードを要すること、攻撃者が利用者をだましてペアリングモードに入れさせた場合でもホストのモニタ上に変更を警告するソフトウェア機能を含めたことを記載しています。

この三つの文書を合わせると、Logi Boltが対処したのは、Unifyingで残った「ペアリング傍受による鍵取得」に対しては認証付きのECDH鍵交換で、「受信機からの鍵抽出」に対しては保存時の保護で、「強制ペアリング」に対してはペアリングモードの要求と画面通知で、という対応関係になります。一方で、公式文書はいずれも第三者による検証結果ではなくメーカーの説明です。FIPS 140-2準拠という表現も、どのモジュールがどの認証番号で検証されたかまでは公式ページに書かれていないため、規制業種で証跡が要る場合はLogitechの法人窓口に確認するのが確実です。

企業標準の第一候補として、Boltレシーバーが同梱されるキーボードから見ていきます。

Bluetooth直接接続で使っているLogi Bolt対応機器をレシーバー経由の運用へ寄せたい場合や、レシーバーを紛失した場合に備える単体品もあります。対応するのはLogi Bolt対応機器だけで、一般のBluetooth機器をこのレシーバーにつなぐことはできません。

主要メーカーの2.4GHz暗号化の記載を確かめる#

2.4GHz独自方式を選ぶ場合の判断基準は単純で、公式資料に暗号化方式が書かれているかどうかです。書かれていなければ、暗号化されていないか、少なくともメーカーが保証していないものとして扱います。

MicrosoftはAES暗号化を前面に出した2.4GHz製品を展開してきました。Microsoft Download Centerで公開されている「Microsoft Wireless Desktop 850 with AES」の技術データシートは、暗号化機能として128ビットAES暗号化を挙げ、AESが米国NISTによって策定されFIPS-197として米国連邦政府に採用された暗号化仕様であることを注記しています。同じ資料には、無線周波数が2.4GHz帯であること、無線到達距離が典型的に15フィート(5メートル)であること、トランシーバーがMicrosoft 2.4GHz Transceiver v8.0であることも記載されています。執筆時点ではIncase社の製品ページに「Designed by Microsoft」のWireless Desktop 850が掲載されており、そこではAES 128ビット暗号化と2.4GHz無線USB技術がキーボードの特徴として挙げられています。Microsoftの技術データシートでもキーボードの名称は「Wireless Keyboard 850 with AES」、マウスは「Wireless Mouse 1000」で、暗号化の記載はキーボードの項目に並んでいます。マウス側の暗号化仕様は両資料からは確認できないため、暗号化の対象はキーボードとして読むのが安全側です。

Microsoftの技術データシート「Microsoft Wireless Desktop 850 with AES」は、暗号化機能として128ビットAES暗号化を記載し、AESがNISTの策定した暗号化仕様でFIPS-197として米国連邦政府に採用されたものであると注記しています。無線周波数は2.4GHz帯、無線到達距離は典型的に15フィート(5メートル)、トランシーバーはMicrosoft 2.4GHz Transceiver v8.0と記載されています。製品名はキーボードが「Microsoft Wireless Keyboard 850 with AES」、マウスが「Microsoft Wireless Mouse 1000」です。

ここで注意したいのは、AESと書いてあれば安心という話ではないことです。UnifyingもAESを使っています。問題になったのは暗号アルゴリズムではなく、鍵の交換と保存の仕方、カウンタの扱い、受信機が受け付けるパケットの種類といった実装の周辺でした。したがって独自方式を見るときは、暗号化の有無に加えて、ペアリングがどう保護されているか(工場でペアリング済みで再ペアリングできない設計か、再ペアリングの手順があるか)、受信機のファームウェアを更新する手段があるか、脆弱性報告への窓口と過去の対応実績があるか、を合わせて確認します。無名ブランドの製品で「2.4GHz」としか書かれていないものは、KeySnifferで名指しされた製品群と同じ扱いにするのが安全側です。

キーボードとマウスをまとめて法人標準に寄せるなら、電池駆動でレシーバー同梱の入門機も候補になります。

有線に戻すという選択#

無線の方式を吟味するほど、電波を出さないという選択の単純さが際立ちます。有線のキーボードは電波経由の盗聴と注入がそもそも成立せず、受信機のファームウェアを管理する必要も、ペアリングの場所を選ぶ必要もありません。BastilleがMouseJackの対処として真っ先に挙げたのも、影響を受けるドングルを外して有線に戻すことでした。

有線が向く場面ははっきりしています。管理者権限で操作するサーバ室や運用端末、パスワードマネージャのマスターパスワードを打つ端末、金融取引や人事情報を扱う席、そして机の配置が固定で無線の利点が薄い据え置きのデスクです。逆に、会議室で複数の機器を持ち替える人や、ノートPCを持ち歩いて席を変える人には無線の価値が大きく、そこは方式を選んで無線を使うのが現実的です。

有線にも別の論点があります。USBケーブルの途中に挟むハードウェアキーロガーは、有線ケーブルがあるからこそ成立する話です。一方、USB経由でキーボードを名乗る攻撃機器(いわゆるBadUSB)は、ホストの空きポートに挿せれば成立するので、正規のキーボードが有線か無線かには関係ありません。無線の受信機がUSB HIDとして入力をOSへ渡す構造も同じで、ホストは挿された機器がキーボードだと名乗れば受け入れます。いずれも電波の話とは独立した物理セキュリティの問題で、別の記事の主題になります。ここでは、有線化は電波経由の脅威を消す手段であって、机の上の物理的な統制を不要にするものではない、とだけ押さえておきます。空いているUSBポートを塞ぐ道具の選び方はこちらで整理しています。

あわせて読みたい

USBポートブロッカーの選び方。空きポートを物理的に塞いで無許可の接続を防ぐ

有線の定番として、接続をUSBに絞った静電容量無接点方式のモデルを挙げます。

受信機のファームウェア更新と棚卸し#

無線入力機器のセキュリティは、買ったときの仕様ではなく、受信機のファームウェアの版で決まる部分があります。Unifyingの例では、2019年8月以降の更新を当てているかどうかで、物理アクセスによる鍵抽出の可否が分かれます。

更新の手段はメーカーごとに違います。Logitechの案内では、PCとMacの利用者向けに更新ツールが提供され、Linux利用者向けにはLinux Vendor Firmware Service(fwupd.org)経由で配布され、法人向けには集中展開できるツールが用意されているとされています。一方で、Logitechのサポートページには、従来のFirmware Update ToolやUnifying Softwareがサポート終了となりLogi Options+への移行を勧める告知が掲載されています。執筆時点でどのツールがどの受信機に更新を配信するかは、手元の受信機の型番で最新の案内を確認する必要があります。

Logi Boltのホワイトペーパーは、セキュリティに関わる更新は適用後に巻き戻せず、セキュリティ以外の更新は利用者またはIT管理者が巻き戻せると説明しています。更新の配信経路と巻き戻しの可否が文書化されているかどうかは、法人で採用する際の確認項目に入れておくと、後の運用が楽になります。

棚卸しの実務は、受信機に着目すると進めやすくなります。Unifyingの受信機は六つの頂点を持つ図形のオレンジのロゴで識別でき、Logi Boltの受信機にはLogi Boltのロゴがあります。組織内のUSBポートに何が挿さっているかを、資産管理ツールのUSBデバイス一覧やOSのデバイス情報から集め、受信機の種別ごとに更新状況と利用者を紐づけます。会議室や共有端末に挿しっぱなしの受信機は、持ち主が不明なまま残りやすいので、最初に集めるべき対象です。

企業での持ち込み機器の統制#

社員が自分で買った無線キーボードやマウスを会社のPCに挿す、という行為は珍しくありません。この一つひとつが、暗号化の有無も更新の有無もわからない受信機を社内に持ち込む行為になります。統制は禁止一辺倒ではなく、標準品の提示と例外の扱いをセットにすると定着します。

進め方は次のとおりです。まず、購入標準を決めます。Logi Boltのように公式文書でセキュリティ方式が説明されている方式を第一候補に置き、Bluetooth直結を許すならキーボードはLE Secure Connectionsに対応したホストと機器でのパスキー付きペアリング、マウスは認証されない接続である前提を明文化します。次に、既存の2.4GHz独自方式の受信機について、更新できるものは更新し、更新できないものは有線か標準品への置き換えを期限つきで進めます。最後に、持ち込みの例外申請を受け付ける窓口を作り、承認条件を決めます。公式資料で暗号化方式が確認できることは必要条件のひとつにすぎず、ペアリングがどう保護されるか(認証の有無)、受信機のファームウェアを更新する手段があるか、既知の脆弱性に未修正のものが残っていないか、までを条件に含めます。Unifyingのように暗号化はあっても修正されない脆弱性が公式に残っている方式は、この条件で例外扱いになります。

技術的な裏付けとしては、端末管理の仕組みでUSB HID機器の接続を記録し、想定外のベンダーIDと製品IDの受信機が現れたら気づけるようにしておきます。ここでの目的は接続を即座に止めることより、棚卸しの網から漏れる機器を減らすことです。管理ツールの選び方はこちらの記事で整理しています。

あわせて読みたい

会社支給とBYODで変わるモバイルデバイス管理(MDM)ツールの選び方

もうひとつ、入力注入への備えは機器の選定だけでは完結しません。注入は受信機を通してOSに正規の入力として届くため、席を離れる際の画面ロックと自動ロックの短い設定、管理者権限で常時ログインしない運用、そして注入された入力で実行されがちなスクリプトの起動を制限する端末側の設定が、入口を通り抜けた後の被害を抑えます。ノートPC側の防御機能はこちらで整理しています。

あわせて読みたい

セキュリティを重視して選ぶノートパソコンの見どころ

KVMや共有オフィスでの注意#

受信機がどこに挿さっているかは、家庭のデスクと共有オフィスでは意味が変わります。Logitechが再ペアリングは10メートル以内に不審な動きがないと確信できるときだけ行うよう案内しているとおり、ペアリングの瞬間は暗号鍵が交換される時間であり、Unifyingではその傍受が以後の復号につながります。コワーキングスペースやオープンな会議室で新しい機器をペアリングする運用は避け、ペアリングは自席や自宅など人の出入りを把握できる場所で済ませておきます。

KVMスイッチを使って複数のPCを1組のキーボードとマウスで操作する構成では、受信機はKVMのUSBポートに挿さり、切り替え先のすべてのPCへ入力を届けます。この場合、受信機ひとつが複数台の入力の入口になるので、そこへの注入は切り替え中のどのPCにも届きます。KVMの配下に管理端末や本番サーバのコンソールがあるなら、その入口は有線にするか、少なくとも認証付きLE Secure Connectionsを強制する方式に限定します。遠隔からコンソールを扱うIP-KVMの選び方はこちらで扱っています。

あわせて読みたい

遠隔保守用IP-KVMスイッチとリモート電源の選び方

共有端末に受信機を挿しっぱなしにする運用にも注意が要ります。誰の受信機かわからないまま残った受信機は、更新も棚卸しもされないうえ、物理アクセスが前提の鍵抽出に対して無防備です。会議室のPCには有線のキーボードを固定し、持ち込みの受信機は持ち帰る、というルールが単純で守りやすくなります。

無線の到達距離も設計に入れます。Logitechの各文書は到達距離を10メートルとし、JVNは室内で多くの場合に数メートル程度と書いていますが、Bastilleは攻撃者側の機材によっては100メートル離れた位置から攻撃できたと述べています。壁一枚隔てた隣のテナントや、窓の外の駐車場からでも電波は届くという前提で、盗聴されて困る入力は無線に乗せない判断が要ります。

用途別の判断基準#

ここまでの内容を、用途ごとに落とし込みます。

判断に迷ったときは、その機器で打つ内容が第三者に読まれたら何が起きるか、勝手にキー入力を送り込まれたら何が起きるか、の二つを想像します。前者の答えが「認証情報が漏れる」で、後者の答えが「管理者権限でコマンドが実行される」なら、その席は有線かLogi Boltに寄せる対象です。どちらの答えも軽いなら、Bluetooth直結の利便性を取って構いません。

まとめ#

無線入力機器の選定は、製品のランキングではなく、電波に何を乗せるかの判断です。打鍵内容の機密度で有線か無線かを決め、無線なら認証付きLE Secure Connectionsを強制する方式を選び、既存の受信機は更新と棚卸しで管理する、という順序で進めれば、机の上の見落としがちな入口を閉じられます。公衆の場での無線利用全般の注意はこちらの記事も参考にしてください。

あわせて読みたい

公衆Wi-Fiの危険性と安全に使うための具体策