ハードウェアの安全性:Kshana がハードウェアに対して行うこと、そして決して行わないこと
ステータス:オーナーによる法的レビューは未了です。以下の法的な注記は、メンテナーが公開情報を読んでまとめたものであり、利用者が限界の所在を知るために書かれています。法的助言ではなく、弁護士によるレビューも受けておらず、法律は国によって異なります。許可としてではなく、弁護士に相談すべき理由として読んでください。
Kshana は、研究、シミュレーション、試験のための助言用ソフトウェアです。型式承認を受けた機器ではなく、受信機、時計、ラボの評価も承認も行いません。README の助言に関する記述を参照してください。
ルール#
受信が製品です。送信は、オープンなエンジンには決して含まれません。
- Kshana には、送信機を駆動するコードは一切ありません。SDR の送信経路(UHD、HackRF、bladeRF、Soapy の送信呼び出し)はなく、ジャミングやスプーフィングの波形が、再生を目的としたファイルに書き込まれることもありません。
- Kshana が書き出すファイル(IQ シーン、SigMF と ION の
.sdrx記録、NMEA と bench のエクスポート)が表すのは、模擬の、正当な信号または運動であり、Kshana がシーン用に書き込むメタデータには、kshana iq sceneによって書かれたことが示されます(ION の.sdrxコメントには、記録ではなく模擬シーンであることが示されます)。 - 実験でbench上の RF が必要な場合、それを生成するのは運用者自身の機器であり、運用者自身の筐体の中で、運用者自身の許可のもとで行います。Kshana は、運用者が行ったと述べた内容を記録するだけで、推測はしません。
ステージ#
各ステージには、Kshana が何を行うか、どのハードウェアが関わるか、誰が RF を放射するか(放射する者がいる場合)、そして Kshana が結果を証拠として扱う前に満たされていなければならないゲートを示しています。
| ステージ | Kshana の役割 | ハードウェア | RF 放射 | ゲート | 0.38 での状態 |
|---|---|---|---|---|---|
| 0 | ファイル:リプレイログ、IQ、bench のエクスポート、stdin、TCP、UDP 経由のライブ NMEA または UBX | なし | なし | なし | 出荷済み |
| 1 | 受動的な受信:受信機は読み取り専用、タイミングログ(linuxptp、chrony、TICC)、IMU の CSV、増え続ける SigMF ファイルに対する iq monitor --follow |
利用者の受信機、グランドマスター、受信側の SDR | なし | 受信機への設定の書き込みには、明示的な --configure が必要で、既定は読み取り専用 |
一部出荷済み:タイミングログ形式、holdover-test、iq monitor --follow。シリアル受信機の入力は計画中 |
| 2 | Kshana からの RF を伴わないラボのオーケストレーション:試験条件の仕様、案内されてタイムスタンプが付く運用者の操作(アンテナを外す、シミュレーターを起動する)、往復のスコアリングと証拠 | ラボ所有のシミュレーター、シールドボックス | ラボのシミュレーターによるもののみ、伝導 | エビデンスパックに記録された、署名付きの lab-attestation(下記)。これがなければ、Kshana はラボの実行のスコアリングを拒否します |
記録はエビデンスパックに実装済みですが、それがなければスコアリングしないという拒否は未実装です(ラボ実行用のコマンドが存在しません) |
| 3 | 正当な GNSS IQ シーンの伝導リプレイ:Kshana がシーンファイルを書き出し、利用者が自分のツールで、減衰器と RF 筐体内の被試験装置を備えたケーブルへ再生します | 利用者の SDR、減衰器、筐体 | 伝導のみ、利用者の責任 | オープンなエンジンには送信コードを含めない。干渉波とスプーフィング波形は範囲外。輸出管理のレビュー。弁護士 | オープンなエンジンには含めない。弁護士とともに進めるべき、商用エディションの項目 |
| 4 | リアルタイムの閉ループ RF ハードウェア・イン・ザ・ループ | パートナーの機器 | パートナー | 代わりにステージ 2 の仕様を通じて統合する | 計画なし |
「出荷済み」は、そのコードがこのリリースに含まれていることを意味します。この表のどこにも、いずれかのステージがいずれかのパートナー、ラボ、当局とともに使われたことは示されておらず、使われたことはありません。
原則#
- 受信が製品であり、送信はオープンなコードには決して含まれません。
- ハードウェアのセッションはすべて、入力、条件、使用したしきい値のハッシュを含むエビデンスパックを生成します。
- 伝導またはシールドの証明は記録されるものであり、推測されることはありません。
- ハードウェアから得られた数値は、独立した外部のオラクル(たとえばラボの真値軌道や基準時計)が一致するまで、MODELLED のままです。事前登録した合格基準は、実行後に緩めません。
- 受信パターンを制御するアンテナ、慣性ユニット、チップスケール原子時計は、データ源(パターン、ログ、公表された安定度曲線)として扱い、Kshana が駆動する装置としては扱いません。
- 表現:結果は、要件に対して「マスクに対して測定された」ものであるか、要件の証拠を裏付ける(supports evidence for)ものです。Kshana は、装置が標準を満たしているとは言いませんし、誰もそれを評価も承認もしていません。
法的な注記(オーナーによる法的レビューは未了)#
GNSS 信号の受信は、ほとんどの国で合法です。GNSS 帯域での送信は、そうではありません。
- 米国。無線通信への故意の妨害は 47 U.S.C. §333 で禁止されており、FCC はジャマーに対して取り締まりを行っています(https://www.fcc.gov/general/jammer-enforcement)。benchからの送信が、benchの外へ届くことがあります。
- その他の国。メンテナーは、他の国の法律を確認していません。gps-sdr-sim の周辺のコミュニティは、その出力の送信はほとんどの国で法律により禁止されていると述べています。弁護士が別段の見解を示していない限り、それを作業上の前提として扱ってください。
- シールドまたは伝導のセットアップは安全策であり、許可ではありません。下記の証明は、運用者が講じていたと述べる安全策を記録するものです。それによって放射が合法になるわけではありません。
- 記録。無線信号の記録は、場所によってはプライバシーや合法性の問題を生じることがあります。
iq monitor --followと、あらゆるキャプチャの手順は受信専用であり、どこで何を記録するかの責任は運用者にあります。 - 輸出管理。信号発生器を駆動するハードウェア・イン・ザ・ループのソフトウェアは、輸出管理規則の対象になることがあります。そのため、ステージ 3 はオープンなエンジンの対象外です。
- ここに書かれたことは、いかなる推奨でも合意でもありません。規制当局、試験場、ラボ、ベンダーのいずれにも、この文書について相談しておらず、いずれもここに書かれた内容に同意していません。
lab-attestation フィールド#
ステージ2以上では、ラボ機器を用いた実行に lab-attestation オブジェクトが付き、入力のハッシュとともにエビデンスパックに記録されます。これは名前の明示された運用者による申告であり、測定ではなく、Kshana は検証しません。
[lab-attestation] # or the same keys at the top level of the file
operator = "name or role of the person responsible" # required
organisation = "laboratory or company" # required
date = "2026-11-02" # required, the day of the session
setup = "conducted" # required: "conducted" or "shielded"
attenuation_db = 60.0 # required for "conducted": total, emitter to device
enclosure = "RF-shielded box, model and ID" # required for "shielded"
emitter = "laboratory-owned simulator, model" # required: what produced any RF
statement = "No emission outside the enclosure or cable path." # required, free text
signature = "ed25519:..." # optional: the operator's own detached signature, recorded as given
0.38 で実装されている内容:
kshana receiver-trust evidence ... --lab-attestation <file.toml>はファイルを検証し、その申告をパックのmanifest.jsonに記録します。マニフェストはパックの Ed25519 署名の対象に含まれるため、検証を壊さずに記録を編集することはできません。同じ機能は、Python のevidence_createのlab_attestation引数、および MCP のcreate_evidence_packツールのlab_attestation_toml引数としても利用できます(ブラウザー版はパックを作成しません)。- 申告なしで作成したパックは、従来とバイト単位で同一です。
kshana evidence verifyは申告内容を報告し、「名前の明示された運用者による申告であり、Kshana は検証していない」と示します。- 申告が不完全な場合、または
setupがconductedでもshieldedでもない場合(無線伝送(over-the-air)の構成はラボ実行として受け付けられません)、その申告は拒否され、パックは作成されません。
まだ実装されていないもの:申告のないラボ実行を Kshana が採点することを拒否する、ステージ2のルールです。0.38 ではラボ実行用のフラグを受け付けるコマンドがないため、拒否の対象がなく、このルールはラボのオーケストレーションコマンドとともに導入されます。申告が記録するのは、安全対策に関する運用者の申告です。申告によって電波の発射が適法になることはなく、結果のラベルも変わりません。採点されたラボ実行は、外部のオラクルが一致しない限り MODELLED です。
コントリビューターへの意味#
- オープンなエンジンに、送信経路、送信に関する依存関係、送信のサンプルを追加しないでください。
- 再生を目的としたジャミングまたはスプーフィング信号を出力する波形生成器を追加しないでください。
- 新しいハードウェア入力は既定で読み取り専用です。書き込みには明示的なフラグと、このファイルへの記載が必要です。
- ハードウェアに触れる新しいコマンドは、すべてのサーフェスに載せるか、理由を付けて
SURFACES.mdで N/A と記し、そのステージをここに明記します。