Starlinkユーザー端末をバラしてみたら
引用元：https://news.ycombinator.com/item?id=43933452
Starlink 端末に初期化時、自動で41個の SSH public keys が authorized_keys に書き込まれるらしい。
しかも port 22 は常に開いてるって。
41個って誰が root アクセス持ってないんだよ？って話。
お前は持ってないだろ、たぶん。
もっと真面目な話だけど、これって ISP が提供してるルーターのリモート管理システムと何か違うの？プライバシーの面で言えば、もし SpaceX がユーザー端末にアクセスできなくても、衛星や地上局でトラフィックを傍受できるし。
これって ISP が提供ルーターをリモート管理するのとどう違うの？
ヨーロッパでは自分のルーター/モデムを使わせる ISP が増えてるらしい。光回線で SFP+ 使って自分で繋いでる人もいるし、 Ubiquiti/OPNsense/OpenWrt ルーターでリモート管理されてない人も多い。 Starlink も ISP だし、これが適用されるのかな？
ISP は自分で用意したルーターの使用を許可するだけでいいみたい。
DOCSIS や GPON は複雑で、最近の ONT なんかはメディア変換以上のことをしてる。 ISP は TR-069 っていうバックドアで端末を完全に制御してるんだ。これは Starlink が SSH key でアクセスしてるのと似てる。
自分で用意したモデムを ISP がサポートする義務はまずないだろうね。ブリッジモードでも TR-069 は動いてるよ。
単に41個のリージョンにある同じサーバーのインスタンスってだけかもね。別に心配する理由じゃないよ。 Starlink はグローバルサービスだし。41個のインスタンスが1つの key を共有してる方が俺は心配だ。
Starlink は従来の意味での ISP じゃないんだ。
普通の ISP がある国で事業をするなら、その国にインフラが必要になる。ってことは、その国の法律に従うか、インフラが差し押さえられるかだ。
Starlink は米国から完全に運用することもできるし、もし外国の法律を破っても、外国政府ができることはほとんどないだろうね。支払いや配送を複雑にすることはできるだろうけど、たぶん Starlink は多少合理的な要求なら応じるだろうさ。でも Musk は、本当に必要な状況なら不合理な制限にも立ち向かうって何度も示唆してるけどね。
＞41個のインスタンスが1つの key を共有してる方が俺は心配だ。
何十、何百、何千っていうウェブサーバーが1つの証明書の private key を共有することなんて簡単だし、 public keys ならもっとまともな設計で色々できるよ。 ssh-keys を使って41台のサーバーを直接認証するなんて、ただの下手くそでいい加減なエンジニアリングだよ。
＞ DOCSIS や GPON はそうはいかないんだ
少なくとも Finland じゃ、どのメーカーの DOCSIS modem でも使えるのが普通だよ。 ISP に modem の MAC address を伝えるだけさ。
でも GPON は違うね。
俺はたった1人のユーザーだけど、 authorized_keys は25行あるんだ。
ノートパソコンには違う yubikeys が入ってるし、 keys on iPads や iPhones にも鍵がある、それに macs には secure enclave keys もあるしね。
Starlink には1人か2人以上の sysadmins がいると思うんだ。100個くらいの pubkeys は妥当だろうさ。
＞ 光回線で SFP+ module で自分で router を繋げる
君はこれがどういう仕組みか、あまり理解してないんじゃないか？
ISP はその fiber のもう一方の端っこが繋がってる先を制御してるんだよ。媒体が fiber だろうが copper だろうが piece of string だろうが関係ない。 ISP は customer interface の反対側を常に制御してるんだ。物理的に box が君の家に置いてあるかどうかは関係ない。
Starlink の場合は、全部1つの box に入ってる。
DOCSIS ( cable ) の場合、 modem を物理的に所有してるかもしれないけど、 ISP が netboots する firmware や device への full remote admin を制御してるんだ。
国によっては衛星システム使うのに国内の地上設備が必要なんだって。Starlinkも地上局いっぱい要るらしいよ。全部スキップできるわけじゃないけど、米国だけじゃ全世界カバーはキツいみたい。
＞だからさ、ISPが自分で用意したモデムのサポートを義務付けられてるかは怪しいな、EU法は分かんないけど。オランダのZiggoってとこはDOCSISで、自前モデムの使い方が載ってるみたい（リンクあり）。ブリッジモードじゃなくて、ホントに自分のモデムを使えるんだって。Edit: それ、ホントに自分のモデムを使ってる話だよ。ブリッジモードにする話じゃない。
ルーターにアクセスできちゃうと、ローカルの通信もインターネットの通信も全部見られちゃう可能性があるね。
アメリカでも一緒だよ。ケーブルネットならどこでも自分で用意したDOCSISモデム使えるんだ。
モデムもルーターも自前で使えるように許可しないといけないんだってさ。EUの決まりで”エンドユーザーは様々な端末機器を選べる自由がある”。ISPはネットに繋ぐ端末機器の利用に制限を課しちゃダメなんだって。［1］でも、今は全部守ってる国は5つだけだって（ドイツ、オランダ、ベルギー、フィンランド、リトアニア）。［2］例えばオランダのISPはPPPoEとSIP（電話）に必要な設定情報とかくれるんだ。［3］
モデム持ってるだけじゃリンク層へのアクセスしかできないって。俺のルーターとかHTTPSの通信にはアクセスできなかったよ。
俺の場合はComcastが特定のモデルしかダメだったな。全部コントロールしたいからって。Comcastのファームウェアを入れられて、その後はComcastでしか使えなくなるって言われたよ。2017年くらいの話。
”お前の”モデムは”向こうの”ファームウェアをネットから読み込んでて、管理画面から全部リモートでアクセスされちゃうんだぜ。
ルーターをroot権限で弄れたら、暗号化されてないHTTPSの通信にアクセスできると思う？
プライベートキーって共有しない方が良くない？
サーバー侵害されたらもっと大変になるんじゃないの？
モデムの場合は違うと思うな、間接的に接続された端末設備には”例外”があるんだって。
面白いことに衛星地球局は法律に明記されてるから、多分自分のStarlinkアンテナは使えるけど、自分のモデムはダメかもね…法律って変だよね。
それな。
どうせモデムのバックドアインターフェースで設定ファイル使ってプロビジョニングしてアクセスできちゃうしね。
モデルによるけど（例えばArrisモデムとか）、パスワードの今日のシードを設定したり（工場出荷時のデフォルトから変更）、もっとロックダウンしてリモートから管理アクセス得ることもできるんだ。
それなんか変だねー君のところのインフラの名残かな？
俺は同じ時期にComcastで独自のファームウェア入れた自分のDOCSISモデム使ってたよ。
ありきたりなArris Surfboardだったけど。
プライベートキーを世界中で使い回すのは手抜きエンジニアリングだと思うな。
普通、侵害時の露出は最小限に抑えたいもんでしょ、最大化じゃなくて。
そういうキャプチャはパフォーマンスには最悪だよ。
ハードウェアオフロード無効にする必要があるし、キャプチャしたパケットをアップリンクで敵にストリームしなきゃいけない。
ローカルストレージも超遅い数ギガバイトに制限されるから、オフライン解析もできないね…
ルーターアクセスのリスクはむしろ、能動的な監視じゃなくて、ネットワークに入ってきて無防備で脆弱なものをいじることの方だよ。
法律ってのは実際そんな風には機能しないんだよ。
特定国の顧客に製品売るなら、大抵その国の法律に従う必要がある。
すごく小規模でサービスが完全に仮想なら避けられるかもね。
でもStarlinkが顧客に物理ハードウェア提供する限り、規制を強制する方法はいくらでもあるよ。
それに、いつでも人を追い詰めることはできるーStarlinkの幹部も顧客も両方ね。
君が求めてるのはX.509ではサポートされてるけど、OpenSSHは独自の証明書交換標準を作ったから、その機能はサポートしてないんだよ。
HTTPSはX.509を使ってる。
OpenSSHはX.509をサポートする気もないし、俺が知る限りでは”自己署名”キー以外をサポートするようにバージョン変更する気もなさそうだね。
DOCSISのことはよく知らないけど、ここThe Netherlandsの光回線では全く違うよ。
自分のOPNsenseマシン（か好きなもの）に自分で選んだSFP+モジュール繋げられるんだ（送信機が互換性あれば、だけどね）。
ISPがリモート管理する方法は全くないよ。
それにDOCSISはこっちじゃゆっくり死にかけてるし、ケーブルプロバイダーがネットで競争力ないから顧客がどんどん離れてるんだ。
もっと良いリニアTVパッケージがなかったら、顧客離れはもっとひどいだろうね。
”君”の端末なのにルートアクセスできないってどうなの？まあ擁護はしないけど、気になるわ。端末がローカルネットとかインターネットに繋がってないなら、その鍵で繋ぐには衛星ネットワーク通るんだよね？Starlinkって衛星ルーターでどんなNATとか使ってんのかな？
似たような投稿の議論だよ。
SpaceX Starlink User Terminalの分解
https://news.ycombinator.com/item?id=25277171 (2020年12月2日 — 158ポイント、138コメント)
もっとコメントを表示（1）
41個の公開鍵、投稿してみたら？誰が使ってるかわかるかもよ。
これ見て。
https://web.archive.org/www.darknavy.org/blog/a_first_glimps…
全部ユーザー空間でパケット処理してるって驚いたわ。1Gbpsで100バイトのUDPパケットだと、秒間百万個の処理が必要になる。1GHzのCPUじゃ1個に1000サイクルしか使えない。やれることではあるけど、アセンブリ手書きとかルックアップテーブル技とか駆使しないと簡単じゃないね。
＞ 既存の研究[3]によると、これらのプログラムや構成の予備的分析では、ネットワークスタックのアーキテクチャはDPDK[4]にいくらか似てて、主にユーザー空間のC++プログラムでカーネルをバイパスしてネットワークパケットを処理してるみたいだね。
普通は最初のパケットはソフト処理だけど、接続先が決まればハード経由になるよ。特定のパターンはソフト処理のこともある。
ソフトはパッチ当てたカーネルか、XDPみたいなカーネルバイパスかも。
Source：Intel PumaのモデムとかでDPDKに関わってた経験からの推測だけどね。
＞ パケットが全部ユーザー空間で処理されてるって聞いて驚いたな…
特に転送なら、DPDKみたいなやり方はバッファコピー減らせるから速くなるかもね。
Starlinkって25-200Mbpsしか出ないし、平均パケットサイズも7-8倍デカいから、多くても秒間36000パケットくらいだよ。
これなら1GHzでも結構ラクに処理できる。
カーネルでパケット処理するより効率悪くなる理由って何？
ハードウェアキューをユーザー空間にマップする方法があるんだよ（記事にもシステムがDPDKライクだって書いてる）。
そうなると、ポーリングコードがカーネルにないことがなんで問題になるの？
100Mbps以上のほとんどのハードウェアってハードウェアオフロードがあるんだよ。
要は、ハードウェアにどのパケットどこに送るか指示してて、ソフトは個々のパケットには触らないの（pingみたいな珍しいパケット以外ね）。
そうそう、でもユーザー空間でプロトコル処理しつつ、GSOとかGRO使うこともできるんだぜ。
いやいや、そんなことないよ。その速度なら、家庭用からエンタープライズまで、何年も前から簡単にCPUだけで動くルーターはいっぱいあるんだよ。
＞100バイトのUDPパケットってあるけど、100バイト？？Starlinkは普通の1500バイトのMTUだよ。
ネットワークの世界じゃ、パフォーマンスを測る時はpps、つまり小さいパケットで測るのが普通なんだ。DPIとか暗号化でもしない限り、ルーターはヘッダーだけ見てルーティング決めるから、ペイロードが10バイトだろうが1000バイトだろうが処理コストは同じ。大きいパケットだとハードウェアの帯域幅だけが重要になるけど、これはめったに問題にならない（DDR4の限界に一度ぶち当たったことあるけど、メモリ増やしたら直ったよ）。
RTP通信だと、小さいパケットがたくさん発生することがよくあるんだ。
ユーザー空間でやると、もう一つのmemcpyを避けられるから、ずっと速くなるんだ。
最近のLinuxは、ちょっと手間はかかるけど、カーネル経由でzero-copy network I/Oができるよ。
最初にさ、それ買わないとね。次に分解するじゃん。で、侵入方法考えんの。そんで実際にやる。そんで、壊しちゃったーって嘆くんだよ。大体UARTがあるもんだけど、Starlink端末にはないみたい。だから代わりにeMMCメモリーチップ（要は soldered microSDカード）を外したんだね。
ハードウェアエンジニアリングを先に勉強したら？部品が何するのかとか、どう扱うのか知らないと、リバースエンジニアリングするの難しいだろうね。
＞DARKNAVYがRev3ファームウェア用のQEMUベースのエミュレーション環境を構築した
って書いてあるけど、外部デバイス（GPSとか）に繋がるファームウェアのエミュレーション方法とか、なんか ready solutions とか、そういう資料のリンク知ってる人いる？
これ見てみて。
https://android.googlesource.com/platform/external/qemu/+/2d…
Android EmulatorはQEMU Emulatorの下流だよ。Androidデバイスのブートとか、よくあるAndroidハードウェア（OpenGLとかGPS、GSM、Sensorsとかね）のエミュレーション、あとGUIインターフェースもサポートしてるんだ。Android Emulatorはいろんな形でQEMUを拡張してるんだよ。
ありがとう、新しいエミュレートデバイスのネタ元としてすごく興味深いね。
でも、外部環境とやり取りするファームウェアを取り上げて、それをどうエミュレートするかっていう全体的なガイドを探してたんだ。
君が探してるのは、ソフトウェアとしてどれなの？
（a）”ファームウェア”＝OS/ドライバ/ユーザー空間を動かすプラットフォーム（x86/Arm SoCとか）をエミュレートするの？
（b）外部と通信するデバイス（MCU、センサー、ゲートウェア、ファームウェアとか）を（a）と通信させるようにエミュレートするの？
（c）（a）で動くOS+ユーザー空間ソフトの振る舞いをシミュレートするの？
（d）その他？
（a）みたいなのは、QEMU（OSS）、Ant Micro Renode（OSS）、Arm FVP（商用）、Intel SIMICS（商用）とかがあるよ。
a+bだよ。既存の組み込みファームウェアで、主にテスト目的でやりたいんだ。
製品のファームウェアをリバースエンジニアリングからどう守るかっていうのに興味あるんだ。SpaceXが使ってる技術の入門的な情報とか、どっかにないかな？
ステップ1はファームウェアの暗号化みたいなことかな。だからSpaceXは何もしてないか、後追いで対応してるんじゃないかって思う。誰かが攻撃方法を公開するまでデバッグピンがあったみたいだしね。
最低限やるなら、rootfsをセキュアエレメントから抜き出すのが難しい秘密鍵で暗号化すべきだね。さらに一歩進むなら、ARMのTrustZoneみたいなのを使って、大事な操作（ブートローダーとか、復号化、イメージの署名とか）を隠しちゃうこともできる。ファイルシステムを簡単にダンプできたってことは、記事で言ってるブートローダー以外の保護はSpaceXで使われてないってことだと思うよ。
イマイチなファームウェアのいい製品いっぱい使ってきた経験から言うと、マジで強い、現実的な、ちゃんと分析した理由がない限り、今回の分解はやめたほうがいいと思うな。それよりも、リソースは賢く使って、みんなのためになったり製品を良くしたりすることに費やそうよ。ヘビーユーザーにとっては、製品を改造できる（たぶん想像もしてないような方法で）って理論上の可能性は、すごく価値のあるメリットになりうるんだよね。だから、これでなんかマジで損害被るって確信がない限り、価値が微妙なこと（あなたとユーザー’の）に時間を使わないことを考えてほしいな。これは技術的なエンドユーザーの視点から言ってるだけだよ。マジで疲れてて、デバイス（ライト、猫の餌やり機、今はローイングマシン）をちゃんと動かすためにハックしなきゃいけないのに、ちょっと憂鬱になってるんだ。
もしLinux使ってるなら、たぶんGPL違反になっちゃうよ。
これ、ロケットとコードベース共有してんの！？ 超かっこいいじゃん！
いや、もっとクールだよ、衛星とコードベース共有してるんだよ；たぶん衛星シミュレーターかも。テレメトリ送らなきゃいけないやつ。
いや、OpenWRTベースだよ。
