自作キーボードキットと派生品のセキュリティ・リスクについて

本記事は、元記事（https://notheme.me/2025/11/12/diy-keyboard-how-firmware/）の簡略化版です。より詳細な内容や、コードを普段触らない方向けの情報については元記事をご参照ください。

自作キーボードやAliExpress等で流通する派生品は、PCB設計者、基板製造者、マイコン供給者、ファームウェア作者、販売者、組み立てるユーザー本人と、信頼の境界が極端に分散しています。
大手メーカー製のキーボードが製造からファームウェア更新まで単一の管理下に置かれるのに対し、自作・派生品ではどこで改ざんや不正が入り込むかをユーザー側が逐一検証しなければならない状況が生まれています。

本記事では、自作・派生キーボードと大手メーカー製キーボードでなぜ根本的にリスク構造が異なるのか、誰がどこで検証しなければならないのか、そして今どこに最も注意を払うべきかをセキュリティ面から掘り下げます。

プリインストール済みファームウェアの危険性

出所不明のバイナリとBadUSB化のリスク

「VIA対応」「QMK互換」を謳う完成品でも、出荷時に書き込まれているのは公式リポジトリとは無関係な独自バイナリであるケースが多いです。RP2040など大容量フラッシュを備えたマイコンが普及したことで、正規ファームウェアに加えて、キー入力の記録・送信、トリガー付きのコマンド実行といった悪意のある処理を仕込める余地が広がりました。BadUSBは「キーボードが勝手にコマンドを打ち込む」攻撃で、特定の文字列や日時をトリガーに、PowerShellやターミナルを開かせてマルウェアを投入する動作が技術的に容易になっています。

ハードウェア・トロイの木馬

見た目では判別できない追加MCUをPCBに仕込み、メインMCUとは別経路でキー入力を吸い上げる手口も想定されます。偽造マイコンが正規品と同じ外観で流通し、内部に攻撃ロジックを抱えたまま出荷される懸念も現実的です。

抑止策: PCへ接続する前に必ずブートローダーモードに入り、公式QMKやZMKなど信頼できるソースから取得したファームウェアを自分で即時にフラッシュします。マイコン自体はMouser、Digi-Keyなどの正規代理店で調達し、半田付け済み完成品を避けるのが安全です。

ビルドプロセスとサプライチェーンの落とし穴

GitHub Actions任せの盲点

ZMKを中心に、クラウドCI（GitHub Actions）でビルドする運用が一般化していますが、これは「プリインストール版を信用しない」代わりに「GitHub上のワークフローを全面的に信じる」選択になります。XZ Utilsバックドア事件のように、信頼していたメンテナーのアカウントが乗っ取られ、公式リポジトリに悪意あるコードが混入した事例もあります。uses: ...@main のように最新版をそのまま呼び出す設定だと、侵害に気づかないまま危険なバージョンを拾ってしまいます。

ビルド時の情報漏洩

キーマップにマクロとしてパスワードやAPIキーを平文でハードコードし、そのままGitHubに公開する利用者が後を絶ちません。プライベートリポジトリでも、ビルドログや中間生成物に機密文字列が露出する恐れがあります。

抑止策: 可能な限りローカル環境を整え、依存ライブラリも含めて自分で検証しながらビルドします。やむを得ずクラウドCIを使う場合は、必ずバージョン固定（タグやコミットハッシュ）を行います。秘密情報はそもそもキーマップに書かない運用に切り替えます。

ファームウェア機能が抱える落とし穴

VIAとVialの差

VIAは仕様上、USB経由で現在のキー押下状態を認証なしで読み出せます。悪意あるプログラムがホスト側にあれば、それだけでリアルタイムなキーロガーになります。Vialはこの問題を認識し、すべての危険コマンドをロックモードで封じ、物理操作によるアンロックを必要とするゼロトラスト設計を導入しています。

VialやRemapのWeb版は、ブラウザとキーボードを直接つなぐWebHID APIを利用します。公式サイトや依存JSが侵害されれば、そのままファームウェア書き換えの足場になります。サイトが改ざんされた状態で許可してしまうと、その瞬間に防御が崩れます。

抑止策: 基本はVialを選択し、設定はできる限りローカルアプリ版で実行します。WebHIDを使う場合でも、アクセスするサイトの正当性を逐一確認し、必要時以外はキーボードをロックしたままにします。

ワイヤレス通信で生じるリスク

ZMKはBLE 4.2以上のセキュアコネクションを強制し通信中の傍受は困難ですが、初回ペアリングでNumeric Comparisonがまだ標準化されていません。カフェや共用オフィス、空港など、不特定多数が出入りする場所でのペアリングは避けるべきで、Flipper ZeroのようなRFツールを持つ攻撃者が近くにいれば、中継役として割り込み、入力内容の閲覧や任意のコマンドの入力、ファームウェアの強制書き換えを実行してしまう可能性があります。

安価な独自ドングル型は暗号化が実装されていないか、XORレベルの簡易処理に留まる事例が多数報告されています。いくつかの市販キーボードでは「AES-128を採用」と宣伝されていても、実際は固定の鍵でXORしているだけだった、という検証結果が出ています。

抑止策: ZMKデバイスは自宅など制御された環境でのみペアリングし、業務用途では有線運用を基本にします。2.4GHz独自方式は使用せず、どうしてもワイヤレスが必要なら暗号仕様が公開され実績のある大手製品に限定します。

実践的な対策

設計・製造する人へ

• 公式アーティファクトの整備: ビルド済みバイナリにはハッシュ値と署名を付け、リポジトリではタグごとの再現手順を公開します
• クラウドCIの透明性: ワークフローファイルを公開し、どのリポジトリからどのバージョンを取得し、どのスクリプトを実行しているのかをドキュメント化します

組み立てて使う人へ

• 信頼できる調達ルートの固定: PCBとマイコンは別ルートで購入し、組み立て前にテスターで基板のショートチェックを行います
• 初期フラッシュと保全: 組み立て後は即座に自分でビルドしたファームウェアをフラッシュします
• クラウドCI利用時の警戒: ワークフローが信用できるリポジトリと固定バージョンを参照しているか確認し、生成されたファームウェアのハッシュ値を記録します
• 無線利用時の注意: ペアリングは自宅で行い、業務端末では有線運用に切り替えます

安全に楽しむための実践ガイド

• 即時フラッシュの徹底: 新品や完成品をPCに挿す前にブートローダーを起動し、信頼できるソースから取得したファームウェアを書き込みます。書き込む前後でハッシュ値を記録します
• ハードウェアの調達経路を固定: PCBは信頼できる設計者から、マイコンや部品は正規代理店から購入し、半田付け済み完成品を避けます
• ローカルビルドとバージョン固定: 自分の環境でビルドできる体制を用意し、クラウドCIを使う場合はタグ固定を厳守します
• Vialを基準にした設定運用: WebHIDは例外対応とし、ローカルアプリとロックモードを標準にします
• ワイヤレスは使いどころを限定: 業務や高い機密性が求められる場面では有線運用を基本にします

もう一つの対策としての「かつての普通」

実は、ここまで記載してきた対策方法の多くは、ほんの2年ほど前まで自作キーボードを使うのであれば「普通」に行っていたことそのものです。信頼できるキットを選び、ソースコードを確認し、手元で qmk compile して中身を把握する――。

便利さと引き換えにブラックボックス化してしまったハードとソフトを、再び自分の管理下（DIY）に戻すこと。それは敷居の高いものかもしれませんが、自作本来の原点である「かつての普通」に立ち返りさえすれば、この記事であげているリスクはかなり抑えることができ、現代における最も確実なセキュリティ対策となります。

まとめ

自作キーボードは、設計からファームウェア、運用までを自分の手でコントロールできる自由がありますが、その自由は同時に利用者自身による「検証責任」を伴います。大手メーカー製の周辺機器に求められる信頼性がサプライチェーン全体で担保されているのに対し、自作・派生品の世界では、クラウドCIのビルド結果やWebHID経由の設定ツール、無線ペアリングのタイミングに至るまで、信頼と脆弱・不審の境界が存在している状況になっています。

今回紹介したリスクはすべて現実に観測されている事象に基づくものであり、特定の販売者やプラットフォームに限定されません。即時フラッシュやバージョン固定、ハッシュ記録、Vialによるロック運用、ワイヤレスの制限といった防衛策を組み合わせることで、自分の用途とリスク許容度に応じた安全性と対策を行うことができます。自分の環境を自分で守る姿勢を軸に、透明性の高い情報を集め、自由度と安全性のバランスを取りながら、自作キーボード、派生品の利用を楽しんでいただけると幸いです。