Starlinkユーザーターミナルの分解

 (darknavy.org)
1 ポイント 投稿者 GN⁺ 2025-05-11 | 1件のコメント | WhatsAppで共有
  • SpaceXのStarlinkユーザーターミナルは、低軌道衛星インターネット接続の中核ハードウェアである
  • ユーザー端末を分解すると、無線周波数（RF）フロントエンドと独自設計SoCが主要部品である
  • ファームウェア分析の結果、主要なコアソフトウェアの多くには、カーネルバイパスのユーザー空間ネットワーク処理および一部の暗号化機能が含まれる
  • STSAFE-A110セキュリティチップが追加の認証ルートとして機能し、データ暗号化と固有識別を提供する
  • このターミナルには多数のSSH公開鍵設定と不審なパケット記録ツールが含まれているが、ユーザープライバシー侵害の手がかりは見当たらない

概要

  • StarlinkはSpaceXが提供する低軌道衛星インターネットサービスである
  • ユーザーはターミナルを通じて近隣の衛星に接続し、これは地上ゲートウェイ経由でインターネットに接続される
  • 新世代の衛星はレーザーリンクを活用して衛星間通信が可能になっており、この機能はグローバルカバレッジと効率向上に寄与する
  • 現地ゲートウェイがなくても、たとえばウクライナのように、隣接国のゲートウェイを利用してStarlink端末がインターネットに接続できる
  • 本記事では、DARKNAVYによるStarlinkユーザーターミナルの詳細調査内容を簡潔に扱う

ハードウェア分析

  • 1つのStarlinkユーザーターミナルはルーターと**アンテナ（UTA）**の2部分で構成される
  • DARKNAVYはシンガポールでStandard Actuated（Rev3, GenV2）ターミナルを購入し、アンテナを分解した
  • 分解の結果、**RFフロントエンドチップ（主にSTMicroelectronics製）**が基板の大部分を占めていた
  • 中核制御領域には**SpaceX専用のカスタムST SoC（クアッドコア Cortex-A53）**が搭載されているが、データシート情報は非公開である
  • Black Hat USA 2022でKU Leuven所属のLennert Wouters博士は、第1世代ターミナル（GenV1）のハッキング成功事例を発表し、SpaceXはその後のファームウェア更新でUARTデバッグインターフェースを無効化した
  • しかし、追加の方法により再びセキュリティ回避に成功した経緯がある

ファームウェア抽出と分析

  • DARKNAVYはeMMCチップから直接ファームウェアをダンプした
  • Rev3基板には専用のeMMCデバッグピンがないため、eMMCを取り外してプログラマーでデータを抽出する方式を用いた
  • ファームウェアの大部分は暗号化されておらず、ブートチェーン（BootROMを除く）、カーネル、ファイルシステムの一部が明らかになった
  • カーネル起動後は、ランタイム環境を**/sx/local/runtime**に展開して利用する
  • binにはStarlinkソフトウェアの実行ファイル群、datには設定ファイル、revision_infoにはバージョン情報が入っている
  • 中核通信プログラムuser_terminal_frontendはGoで開発されており、それ以外の大半はシンボルなしの静的C++バイナリである
  • ネットワークスタックアーキテクチャはDPDKに似ており、カーネルをバイパスしてユーザー空間プログラムがパケット処理を担当する
  • Linuxカーネルは主にハードウェアドライバとプロセス管理に使われる
  • 一部のソフトウェアには、もともと衛星またはゲートウェイ用途向けに設計された機能が含まれている
  • デバイス起動時にハードウェア周辺機器からタイプを識別し、該当ロジックだけをロードして使用する

エミュレーション

  • 継続的な分析のため、QEMUベースのRev3ファームウェアエミュレーション環境を構築した
  • この環境でhttpd、WebSocket、gRPCなどの外部向けサービスの一部を実行し、デバッグすることに成功した
  • 主要実行ファイルおよびサービスの動作原理を追跡できるようになった

セキュリティチップ

  • メインSoCのほかにSTSAFE-A110セキュリティチップが存在し、**CC EAL5+**認証をうたっている
  • このチップはNDAのもとで購入可能で、ファームウェア内のstsafe_cliプログラムがこのチップと相互作用する
  • 分析の結果、STSAFEチップが提供する機能には、デバイス固有UUIDの付与、公開鍵証明書（stsafe_leaf.pem）の管理、対称鍵導出などがある
  • このチップはSoCのセキュアブートとは別の追加の信頼のルートであり、現代の組み込みセキュリティ設計基準に合致する

イースターエッグ: Elonはあなたを見ているのか？

  • 分析中にEthernet Data Recorderプログラムが確認され、バックドアの可能性について疑問を抱かせた
  • このプログラムはパケット記録機能を持つように見え、内部的にはpcap_filter類似メカニズムで特定パケットをキャプチャする
  • ルールを見ると、キャプチャ対象は主に衛星テレメトリー関連のUDPパケットであることがわかる
  • 取得したトラフィックはSoCハードウェアキーで暗号化されて保存される
  • 現時点ではユーザープライバシーデータを収集している証拠は確認されていない
  • 初期化過程でデバイスがユーザー端末と認識されると、/root/.ssh/authorized_keysに41個のSSH公開鍵が記録され、ポート22は常にローカルネットワークに対して開かれている
  • 市販製品に多数の正体不明の公開鍵が登録されている点は注目に値する

結論と展望

  • 衛星技術が多様な産業分野に適用されるにつれ、Starlinkのような衛星インターネットシステムの構成要素は今後、セキュリティ攻撃と防御の主要な戦場になると予想される
  • 宇宙セキュリティの特性上、一度のミスが対象との恒久的な通信断絶につながる可能性があるため、慎重なアプローチが求められる

関連記事

1件のコメント

 
GN⁺ 2025-05-11
Hacker Newsのコメント
  • デバイスの初期化時、システムがユーザーターミナルとして認識すると、初期化スクリプトが自動的に41個のSSH公開鍵を /root/.ssh/authorized_keys ファイルに書き込み、ポート22も常にローカルネットワークに対して開いていることが判明した。41個もの鍵を使う意味が何なのか気になるし、結局のところ「自分が所有している」ユーザーターミナルに対してルートアクセス権を持つのが誰なのか疑問だ
    • おそらくあなた自身だろう。もっと真面目に考えると、ISP提供のルーターにリモート管理システムが載っているのと大差ない。たとえ SpaceX がユーザーターミナルへのアクセス権を持っていなくても、衛星や地上局でトラフィックを監視することはできる
    • 最近、特殊な政府業務に関わる人々と、追跡可能なSSH鍵がないかを確認するのに最適な相手が誰か気になった。最近ちょうど良いリークもあった
    • 41個の鍵は単に41リージョンの同一サーバーインスタンスなのかもしれない。Starlink はグローバルサービスなので、特に心配するようなことではない。むしろ41インスタンスが1つの鍵を共有していたら、そちらのほうが心配だ
    • 今いる会社では、開発者のSSH鍵は DEV や QA のファームウェアにしか配布しない。本番イメージは署名後にSSH自体が完全に無効化されている。本番環境でのリモート診断には別ソフトウェアを使い、これもアクセス権とDevOpsの承認手順で管理している。だから SpaceX の選択は不思議に感じる
    • 自分は単一ユーザーなのに authorized_keys に25行ある。ラップトップの複数の YubiKey、iPad や iPhone の鍵、Mac の Secure Enclave の鍵などが混在している。Starlink には少なくとも1〜2人以上のシステム管理者がいるはずだし、100個の公開鍵でもそれほど不自然な数ではない
    • むしろこれは思ったより普通で、セキュリティ的にも良い選択かもしれない。何百万台もの端末がすべて同じ鍵、あるいはごく少数の鍵を使うより、シリアル番号や製造時期ごとに分離された複数の鍵を使うほうが良い。秘密鍵は少数の端末管理にのみ使われ、鍵管理も分割できる
    • このターミナルがローカルネットワークにインターネット接続もある場合にだけ、外部から鍵でアクセス可能なのではないかと推測する。SSH接続のために衛星網をどう通すのかも気になるし、Starlink が NAT などのネットワーク構造をどう使っているのかも気になる
  • 以前投稿された類似テーマとして、Starlink ユーザーターミナルの分解記事へのリンクを共有
  • 41個の公開鍵を公開して、どの開発者が使っているものか調べたら面白そうだと思う
  • Starlink 関連のブログ記事アーカイブへのリンクを共有
  • 著者にタイトルの誤字（"ternimal"）を修正してほしいと依頼
    • これは keming（文字間隔の不均衡）問題の古典的な例だと洒落っ気たっぷりに述べる
  • すべてのパケットがユーザースペースで処理される点に驚いた。1Gbps のトラフィック（100バイト UDP 基準）なら毎秒100万パケットで、1GHz CPU では1パケットあたり使えるのは1000サイクルしかない。理論上は可能でも簡単ではなく、エンジニアがアセンブリを直書きしてあらゆる手を尽くすレベルだ
    • 論文によると、ネットワークスタックの構造は DPDK に似ており、パケットのカーネルバイパス処理が中核らしい。実際には最初のパケットだけソフトウェアで処理し、セッション確立後はハードウェアに渡せる可能性がある。一部のパターンは継続してソフトウェアで処理することもあるだろう。以前の Intel Puma 系ケーブルモデムルーターでも似た方式を見たことがある
    • DPDK スタイルのフォワーディングならバッファコピーが減るので、むしろ速い可能性もある。Starlink は 25〜200Mbps 程度で、平均パケットサイズが7〜8倍大きいことを踏まえると、毎秒約3万6000パケット程度で、1GHz CPU でも十分さばける量だ
    • カーネルでパケット処理するより userspace のほうが非効率である理由が何かあるのだろうか。ハードウェアキューをユーザースペースにマッピングすれば、カーネルとユーザースペースの区別は重要ではなくなる
    • Starlink の場合、100バイト UDP パケットよりも一般的な1500バイト MTU を使う
    • userspace でパケットを処理すると不要なメモリコピーが減るため、ずっと高速になる
  • こうした機器のリバースエンジニアリングをどう始めればいいのか知りたい。リバースエンジニアリングは難しく、例として出てくるものの多くは古いか高価で手を出しにくい
    • まずハードウェアエンジニアリングを学ぶべきだ。部品の用途や特性が分からないと、リバースエンジニアリング自体が難しい
    • 第一に製品を自分で買って分解する。第二に、分解後どう突破するかを考える。第三に、実際に試す。第四に、壊してしまった事実に打ちのめされる。たいていは UART ポートから入るが、Starlink には無さそうなので、eMMC メモリチップを取り外して解析した事例だ
  • QEMU ベースのエミュレーション環境で、外部デバイス（GPS など）に接続されるファームウェアをエミュレートするための参考資料や、すぐ使えるソリューションがあるか質問
    • Android の QEMU フォークでは、OpenGL、GPS、GSM、センサーなど多様なハードウェアと GUI インターフェースをエミュレートしている点を例として紹介
  • ファームウェアをリバースエンジニアリングから保護する方法を学びたい。SpaceX が使っている技術についての入門資料があるのか気になる
    • 第1段階はファームウェア暗号化のような対策だ。SpaceX も特に先回りして対応しているわけではなく、見つかるたびにその都度パッチしているように見える。以前はデバッグピンもあった
    • 使ってきた多くの製品はファームウェア面の完成度が低いことが多かった。セキュリティ目的以外ではむやみにロックせず、みんなの役に立つことにリソースを使ってほしい。パワーユーザーにとっては機器を自分で改造できることはむしろ利点だ。本当に深刻な侵害リスクがないなら、無駄に時間を使わないでほしい。各種機器を必要に応じてハックしなければならない現実は残念で、ときに憂鬱ですらある
    • 少なくともルートファイルシステムを暗号化し、盗難や抽出が難しい本物のセキュアチップ内の秘密情報を使うのが基本だ。さらに安全性を高めたいなら、ARM TrustZone を使ってブートローダー、復号、イメージ署名などの機微な処理を隔離できる。ファイルシステムを簡単にダンプできるという事実自体が、SpaceX が実質的な保護機構を使っていないことを意味する。ブートローダーだけが保護され、それ以外は露出している
  • この機器がひょっとしてロケットと同じコードベースを使っているのではないかと感じ、面白がっている
    • むしろもっと格好いいのは、衛星とコードベースを共有しているか、少なくとも衛星シミュレーター程度とは共通化していそうな点だ。各種テレメトリーを送る必要があるからだ
    • 実際には OpenWRT ベースだ