みちびき信号認証サービス - Beyond your wall with Drogger

2024年 4月よりみちびきの信号認証サービスが正式運用になりました。

ビズステーションでは世界初のみちびきの信号認証サービス対応ファームウェア(F/W)をリリースいたしました。RWS/RZSシリーズすべてのGNSS受信機で利用できます*1。
信号認証は、スプーフィング（後述）などのなりすましの脅威に対抗する強力な防衛手段です。

信号認証とは
使い方
ミッションクリチカルな用途

信号認証とは

GNSSの位置測位では、測位衛星から放送するデジタル情報を受信して利用しています。この情報は衛星時計のオフセット量やある時刻における衛星位置を計算するデータなどが含まれています。
仮にこの情報が偽装されたとすると、時計が狂ったり測位位置が大きくずれたり、測位出来なかったりすることになります。

そこで、衛星から受信した情報が正しいものであるか確認出来るようにしたサービスが、みちびきの信号認証サービスです。
信号認証対応 F/Wは、このサービスを利用して受信したデータが本物かどうかを確認することができます。

スプーフィング

受信機付近で衛星の電波と同じ周波数で、本物と同様にフォーマットされれ偽データを載せた電波を送信します。つまり、衛星になりすました電波を送信します。このような偽装をスプーフィングと言います。

受信機がそのデータを信じて処理すると、誤った位置や時刻を示すことになります。GNSSはインフラとして多くの用途で利用されていますので、大変な社会問題になります。

認証方法

認証の方法は、インターネットで広く利用されているデジタル署名を使用しています。署名と確認は以下のような手順で行われます。

運用局は（地上の管制局）秘密鍵を使って、GPS・Galileo・QZSSの衛星とシグナル毎の本物の航法データの署名を生成します。
運用局はみちびき衛星にてその署名を放送します。
受信機には事前に秘密鍵に対する公開鍵を入れておきます。
受信機は受信したGPS、Galileo、QZSSの航法データから公開鍵を使って署名を生成します。
受信機はみちびきから放送された署名と、自身で生成した署名を比較し違いがないか確認します。

対象衛星とシグナル

みちびきの信号認証サービスは、GPS、QZSS、Galileoが対象です。GLONASSとBeidouの認証はできません。

対象のシグナル（ナビゲーションメッセージ）はGPS,QZSSはL1(LNAV) L5(CNAV)、Galieoは E1/E5b(INAV) E5a(FNAV)が対象です。通常受信機が内部で使用するのは、LNAVとINAVです。

QZSSの署名は元データと同じシグナル（QZSSのL1/L5）で送信されます。
GPSとGalileoの署名はQZSSのL6Eを使って送信されます。

認証要件

認証には、受信機の機能によって制限があります。

QZSSの航法データの認証はRWS/RZSシリーズすべてで利用できます。
GPS、Galileoは署名データがQZSS L6Eで放送されるためL6Eを受信できる必要があります。このため、受信機単体で検証できるのは、RWS.DC・RWS.DCMのみです。
RZS.DCは可能ではあるものの、L6EとL6D(CLAS)の同時受信ができないため、CLASを使いながらGPS/Galileoの信号認証を行うことはできません。どちらか一方を排他選択となります。
L6Eが受信できない受信機でも、外部からL6Eデータを受け取れれば、認証処理を行うことができます。（F/W自体は同じで制限されていません）
L5(CNAV)やE5a(FNAV)は3周波受信機のみ対応します。

そのほか、今回のF/Wリリースでは以下の対応がされています。

E5bはE1と同じINAVのため、E5bも認証結果が表示されます。
GPS L2はL5と同じCNAVのため、L5用のデジタル署名を使ってL2 CNAVの検証を行っています。（L5が放送されない衛星のL2は認証できません）

認証の遅延

デジタル署名を受け取る時刻には、元のデータ（署名対象）の放送タイミングに対して仕様上の遅れがあります。そのため、検証は少し前に放送されたデータに対して行うことになり、タイムラグが生じます。

QZSSは240秒となっていますが、運用局のアナウンスでは最大720秒になるかも知れないとしています。
GPSは安定して300秒サイクルで認証できます。
Galileo INAVは経験上 20分ほど認証できないタイミングがあります。

認証結果の利用

受信機は、署名確認出来たデータだけを使用すればよいのですが、実際はあまり単純にそうできません。
署名には数分の遅延があるため、確認済のデータだけを使うと最新のクロック補正や衛星位置情報の利用ができなくなります。また、電源を入れてから測位できるまでに多くの時間を要するようになってしまいます。非常に使いづらいものになります。

このため、現在のところ確認済のデータだけを使うといった厳しい制限をかけるのではなく、認証状態の記録（ログ）や画面での確認といった控えめな利用を選択しています。今後のセキュアな環境要求に応じて利用方法は変更していく予定です。

測量などにおきましては、観測時間に不正な状態がないことを記録から確認することで、スプーフィングの無いデータによる測量であることを担保することができます。

使い方

Drogger-GPSの更新と受信機 F/Wのアップデート

Drogger-GPSを　Ver 2.15.247以降に更新します。
お使いの RWS/RZSシリーズのF/Wを Ver 3.0.1以降に更新します。
Drogger-GPSの設定 -[GNSS(衛星測位システム)]-[QZNMA Signal Authentication]をONにします。

動作確認

衛星航法データが正しいものと確認できると[Satelites]グラフのシグナル名が緑色、認証不一致の場合は赤色で表示されます。

未認証のものは従来通り白文字です。

信号認証が出来るまでには前述のとおりタイムラグがあります。空が開けた場所にて、電源ONから10分程待ってから確認してください。

L6EをVRSCから受信する

L6を受信できない受信機でもVRSCを使うと、GPSとGalileoの信号認証を行うことができます。

VRSCからNtripプロトコルでL6Eを受信します。以下はDrogger-GPSでの設定方法です。（信号認証にはMADOCAラインセンスは不要です。）

[設定]-[RTK]-[移動局]をONにします。
[移動局用キャスターホスト]をタップします。
[Ntrip Caster タイプ]で一度[VRSC/CLAS]を選択し、再度開いて[その他]を選択します。この操作でVRSC用のWiFIアクセスポイントなどが設定されます。
[マウントポイント]をタップし「RAW_L6E」と入力し[OK]をタップします。
設定を抜け[Start]をタップします。しばらくして、[Ntrip Status]が　Runningで[Mount Point]にRAW_L6Eと表示されればOKです。

尚、VRSCの設定はデフォルトのままでOKです。

ミッションクリチカルな用途

以降は、具体的に認証状態を問うクリチカルな用途の場合にご覧ください。

認証状態の記録

信号認証は画面だけでなく、NMEAメッセージの出力と記録ができます。NMEAメッセージには、以下の2種類があります。

$PNSTS 衛星認証ステータス
$PNSFV フレーム受信結果

結果を後で確認する場合は、$PNSTSを使用します。$PNSFV は衛星航法データのサブフレームごとの詳細な検証結果です。

$PNSTS 衛星認証ステータス　

衛星認証ステータスは衛星+信号の組み合わせごとに、最後の検証結果を全衛星出力します。5秒ごとに出力されます。

最後の検証結果とは、一連のサブフレームの整合性があり実際に署名と照合された最後の結果です。例えば、10:15:00にGPS 10号機の検証が「成功(0」)し、その後受信環境が良くなく検証が出来ずにいた場合、その時点のGPS 10号機の衛星認証ステータスは10:15:00の時と同じ「成功(0)」を出力します。
また、最後の結果には「署名データに変化なし (2)」も含まれます。
一度検証されれば基本的にその衛星は「検証していない(3)」を示すことはありませんが、現在のサブフレームのtow*2と最後の検証時towを比較し、30分以上経過している場合は、「検証していない(3)」にリセットされます。

$PNSTS,1,1,24,288936,2,1,15,288936,2,1,23,288936,2,1,18,288936,2,1,12,288906,2*50
$PNSTS,2,1,13,287376,2,1,10,288936,2,5,4,288325,2,5,10,288925,2,5,11,285745,2*67
$PNSTS,3,5,19,0,3,5,21,0,3,5,36,287725,2,5,12,287245,0,2,10,288924,2,2,12,0,3*67
$PNSTS,4,2,15,0,3,2,18,288924,2,2,23,288924,2,2,24,288924,2,2,25,288924,2*6E
$PNSTS,5,1,25,288936,2,5,9,288925,2,5,31,0,3,2,32,288924,2,1,32,288936,2*5F

番号	例	型	説明
0	$PNSTS	文字列	識別子
1	1	整数	行番号（1行は82文字以内で複数行で全衛星を列挙）
2	1	整数	航法メッセージタイプ　航法メッセージタイプ表を参照
3	5	整数	衛星番号
4	288936	整数	航法データのtow (Time of week)
5	2	整数	検証結果　検証結果表を参照 0～ 9までの値が使用されます。例外として運用局のサービスの場合「運用局のサービスが停止している(36)」が使用されます。

運用局のサービスが何らかの理由で停止し、L6E信号のname_idがセロ以外である場合は、以下のように、航法メッセージタイプ衛星番号航法データのtowはゼロ、検証結果は「運用局のサービスが停止している(36)」になります。

$PNSTS,1,0,0,0,0,36*<checksum><CRLF>

$PNSTSを集計すると、認証の連続性について確認できます。以下のプログラムは$PNSTSを記録したログを参照しグラフィカルに表示した例です。
横軸が時間で、衛星・シグナルごとに緑の線は認証成功、薄い茶色は未検証です。認証に失敗した場合は、赤色線で示されます。

この簡易ビュワーは以下よりダウンロードできます。 https://www.bizstation.jp/DroggerGps/sas/stsViewer.zip

$PNSFV フレーム受信結果

フレーム受信結果は、サブフレームを受信するたびに処理された内容を詳細に出力します。GNSS認証においては該当サブフレームを受信するたびに認証も行われます。

QZSSでは、認証対象サブフレーム受信時に認証が行われます。証明書を含むサブフレームではその保存が正常かどうかを示します。

Galieo衛星についてサブフレームの受信タイミングに加えて、L6Eのデジタル署名を受信したタイミングも検証が行われます。$PNSFVはこの結果も出力します。

$PNSFV,2,31,30,11,0*72

番号	例	型	説明
0	$PNSFV	文字列	識別子
1	2	整数	航法メッセージタイプ　航法メッセージタイプ表を参照
2	32	整数	衛星番号
3	30	整数	サブフレーム番号 Galileoハイブリッド方式でデジタル署名を受信したタイミングの場合、この番号は0が使用されます。QZSSのRDSを含むサブフレーム( id=60)を受信した場合サブフレーム番号+RDSのセグメント番号が出力されます。（61 or 62 or 63）
4	11	整数	検証結果　検証結果表を参照
5	0	整数	航法データのtow (Time of week)　この値は検証過程でtow取得に至らない場合ゼロになる

航法メッセージタイプ

値	衛星	Navタイプ	信号
1	GPS	LNAV	L1C/A
2	GPS	CNAV	L2C , L5
3	GPS	CNAV2	L1C
4	GAL	FNAV	E5a
5	GAL	INAV	E1B, E5b
6	QZS	LNAV	L1C/A, L1C/B
7	QZS	CNAV	L2C, L5
8	QZS	CNAV2	L1C

検証結果表

値	説明
0	全フレーム一括での認証成功
1	全フレーム一括での認証失敗
2	新しいフレームに置換した全フレームハッシュ値と全フレーム認証成功時のハッシュ値が同じ且つ、署名データに変化がない。
3	検証していない　（検証できる要件が揃っていない）
4	検証が遅れている。前回の認証から、(シグナルごとの)規定時間内に認証できていないことを示します。これは、トンネルなどで航法メッセージを受信できなかった場合などで起こります。
9	検証システムに異常があって検証していない
10	検証できる要件が整うのを待っている
11	デジタル署名がない　（未受信含む）
12	QZSのデジタル署名がない
14	複数フレーム間の一貫性がない
15	複数フレーム間でiodeの一貫性がない
16	署名と検証対象iodeが異なっている
21	衛星のhealthにより検証しない
30	検証システムに異常
31	システムハンドルエラー
32	航法メッセージタイプまたはprnが異常
33	検証フレームデータが無い
34	ハッシュ値取得に失敗した
35	公開鍵の取得に失敗した
36	運用局のサービスが停止している