RAS AIセキュリティ対策がFTTIを超えるとき — HARAとTARAの間の空白をSTPAで埋める
01要約
02場面：50 ms以内に完了すべきブレーキ、メッセージごとに加わる検証
前方カメラとレーダーが停止車両を捉えます。ADASドメインのAEBコントローラは衝突リスクを判断し、車両バスを通じて緊急ブレーキ要求を送信します。要求メッセージにはSecOCの認証タグ（CMAC）とフレッシュネスカウンタが付加されています。ブレーキ・バイ・ワイヤのブレーキECUはタグを再計算し、要求が本当にAEBコントローラから来たものであることを確認してから、ようやくブレーキ圧をかけます。
Electronics Weeklyの寄稿記事は、まさにこのプロセスを例に挙げています。ブレーキ・バイ・ワイヤおよびステア・バイ・ワイヤのFTTIは一般に10～50 msであり、遅延はそのまま制動距離に変わります。ブレーキECUがAES-128の検証をソフトウェアで行ってメッセージあたり2 msかかり、CANバスが飽和すると、蓄積した遅延がFTTIの余裕を大きく削ります。記事の結論は明快です。セキュリティ設計のせいでブレーキメッセージがFTTIを超えれば、それはISO 26262でいう機能安全上の故障です。
この結論に反対する人はいないでしょう。しかし実際のプロジェクトでは、この一文はどこに書かれているのでしょうか。
03HARAの表にもTARAの表にも時間の欄がない
| 問うこと | 問わないこと | |
|---|---|---|
| HARA (ISO 26262-3) | ハザーダスイベントの重大度（S）・暴露度（E）・制御可能性（C）、ASIL、安全目標 | 安全目標を守る経路にセキュリティ対策が入ったとき、時間がどれだけ残るか |
| TARA (ISO/SAE 21434) | 資産、ダメージシナリオと影響（安全・財務・運用・プライバシー）、攻撃パスと実現可能性 | 対策（認証・暗号化）が安全機能の時間バジェットをどれだけ消費するか |
| FTTIと安全メカニズム (ISO 26262-4、-5) | 故障の検出・反応時間、FTTI | セキュリティ対策が同じ時間バジェットを共有しているという事実 |
2つの分析を同じワークショップで行ったとしても、表の欄がこのようでは、この衝突は議事録の1行で終わってしまいます。安全チームは「FTTI 50 ms」を要求として、セキュリティチームは「認証成功前の実行禁止」を要求として出し、両者が同じ50 msの中で衝突するという事実は統合テストになって初めて表面化します。
1点、訂正が必要です。記事は、TARAの影響度を「HARAのASILから直接導く」ことを勧めています。しかしISO/SAE 21434では、ダメージシナリオの安全影響度はISO 26262-3の重大度（S）に基づいて決めます。ASILには暴露度と制御可能性が混ざっているため、そのまま引き継ぐと、攻撃によって暴露度や制御可能性が変わり得るという点を見落とします。引き継ぐべきはASILではなくSです。
04STPAは時間をUCAで問う
STPAは、コントローラが出すコントロールアクションごとに、4つの形で非安全になり得るかを問います。提供されない、危険なときに提供される、早すぎる・遅すぎる・順序が誤って提供される、早すぎる停止または長すぎる適用。3番目の問いこそがFTTIの居場所です。
そしてSTPAのコントロールストラクチャでは、認証とバスが制御経路とフィードバック経路の上にそのまま置かれます。認証検証はブレーキECUの制御アルゴリズムの中に、バス遅延は制御経路の中に、フレッシュネスカウンタの同期はブレーキECUのプロセスモデルの中にあります。セキュリティ対策が「安全分析の外にある別の文書」ではなく制御ループの一部になるため、ロスシナリオを書いていくと自然に引っかかります。
05例：AEB緊急ブレーキ要求の経路
教育用の架空のシステムです（特定の車両やメーカーの設計ではありません）。FTTIは説明用の例示値として50 msに設定しました。ロスは人命の喪失・負傷と財産の損害の2つ、ハザードは「安全な車間距離が保たれない」（H-1）と「必要のない状況で急ブレーキをかける」（H-2）の2つです。システム制約は次のように記述しました。
HARAの安全目標とTARAのサイバーセキュリティ目標がそれぞれ別々に記述していたことを、1つの文にまとめたのがこの制約です。
UCA 4件
| ID | コントロールアクション | 非安全なコントロールアクション | ハザード |
|---|---|---|---|
| UCA-T-1 | 緊急ブレーキ要求 | 前方衝突のリスクがあるのに、AEBコントローラが要求を遅れて送るため、ブレーキECUが認証検証を終える時点がFTTIのバジェットを超える | H-1 |
| UCA-T-2 | ブレーキ圧の印加 | 要求は届いているが、ブレーキECUが認証検証を待つため、ブレーキ圧の印加開始がFTTI以降になる | H-1 |
| UCA-N-3 | ブレーキ圧の印加 | 要求が届いたが、ブレーキECUが認証失敗により要求を破棄し、ブレーキ圧を印加しない | H-1 |
| UCA-P-4 | ブレーキ圧の印加 | 衝突のリスクがないのに、ブレーキECUが偽造またはリプレイされた要求を受け入れてブレーキ圧を印加する | H-2 |
UCA-P-4は、TARAであれば脅威シナリオとして書いていた内容です。STPAでは同じ表の中でUCA-T-2のすぐ隣に並びます。認証を緩めればT-2が減ってP-4が増え、厳しくすればその逆になります。このバランスが1つの画面で見えることが、本記事の要点です。
ロスシナリオ 5件
| ID | UCA | シナリオの要旨 | 見えてくること |
|---|---|---|---|
| LS-1 | T-2 | 認証をソフトウェアで検証してメッセージあたり約2 ms。バス飽和によるキュー待ちと再送が重なり、累積遅延がFTTIを超える。検証時間は通常負荷でしか測定されていない | 記事の事例そのもの。対策は最悪条件での測定とHSM |
| LS-2 | T-2 | ブレーキECUのアルゴリズムが「認証前のブレーキ禁止」だけを定義し、検証がFTTI以内に終わらない場合の動作を定義していない。2つの要求がHARAとTARAの文書に別々にあるため、衝突が表面化しない | 空白の欄そのもの |
| LS-3 | T-1 | カメラとレーダーのデータも同じバスで認証付きで届き、バスの過負荷が物体データとブレーキ要求の両方を遅延させる | 共通原因。前回の記事で扱った組み合わせアーキタイプと同じ構造 |
| LS-4 | N-3 | ブレーキECUのリセット後にフレッシュネスカウンタの同期がずれ、正規の要求がリプレイ攻撃と判定されて破棄される。「認証失敗」のフィードバックがないため、AEBコントローラはブレーキがかかったと思い込む | セキュリティ対策が生んだ隠蔽 |
| LS-5 | P-4 | インフォテインメントドメインが侵害され、ゲートウェイがブレーキ要求のIDをフィルタリングしない。遅延を減らすためにフレッシュネスカウンタの許容ウィンドウを広げていたため、リプレイされた要求が通過する | 時間を節約するための設定がセキュリティホールになる |
5件を並べてみると、互いに逆方向を向いたシナリオが混在しています。LS-1とLS-2はセキュリティ対策が遅すぎるために、LS-5はそれを速くしようとしたために生じます。LS-4は、セキュリティ対策が正規の要求をブロックし、その事実を隠すものです。安全とセキュリティを別々に分析すると、最初の3件は安全チームの文書に、LS-5はセキュリティチームの文書に入り、LS-4はどちらにも載らない可能性が高いでしょう。
対策 6件
| ID | 対策 | 関連シナリオ |
|---|---|---|
| CM-1 | 認証検証をHSMの暗号アクセラレータに移し、検証時間をバス飽和を含む最悪条件で測定して遅延バジェットに記録する | LS-1 |
| CM-2 | 各段階（検出 → 判断 → 認証生成 → 伝送 → 検証 → 作動）の遅延上限をFTTI内で割り当て、要求として明記する | LS-1, LS-3 |
| CM-3 | 検証がバジェット内に終わらない場合や認証に失敗した場合の動作を安全コンセプトで定義する（例：ドライバーへの警告、縮退モード）。どの動作が安全側かは、HARAとTARAの結果を合わせて見て決める | LS-2, LS-4 |
| CM-4 | 「認証失敗・要求破棄」の状態をAEBコントローラにフィードバックし、フレッシュネスカウンタの再同期手順を定義する | LS-4 |
| CM-5 | 安全上重要なメッセージのバス優先度と帯域（CAN FD、車載イーサネット）を確保し、ジッタシミュレーションを実施する | LS-3 |
| CM-6 | ゲートウェイでのドメイン間フィルタリング、HSM鍵のアプリケーションコアからの分離、フレッシュネスの許容ウィンドウは遅延バジェットと合わせて決定 | LS-5 |
CM-3には注意が必要です。「検証が遅れたらとにかくブレーキをかける」という選択はLS-1を防ぎますが、LS-5を再び開いてしまいます。この判断は安全チームとセキュリティチームのどちらか一方だけでは下せません。だからこそ、2つの分析が同じモデルの上にある必要があるのです。
06遅延バジェット：SC-2を数値に落とし込む
システム制約SC-2は、下のような表になって初めて検証できます。数値は説明用の例です。
| 段階 | 上限（例） | 担当 | 根拠 |
|---|---|---|---|
| 物体の検出・認識 | 15 ms | ADAS | センサ周期と処理時間の実測 |
| 衝突判断・要求生成 | 10 ms | ADAS | アルゴリズムの最悪実行時間 |
| 認証タグ生成 | 1 ms | セキュリティ | HSMでの測定値 |
| バス伝送（最悪） | 5 ms | アーキテクチャ | バス負荷・優先度分析、ジッタシミュレーション |
| 認証検証 | 1 ms（HSM） / 2 ms以上（ソフトウェア） | セキュリティ | 最悪条件での測定 |
| ブレーキ圧の立ち上がり | 15 ms | シャシー | アクチュエータ応答試験 |
| 合計 | 47 ms ≤ FTTI 50 ms | 安全 | バジェットの承認 |
この表の各欄は、STPAの制御経路・フィードバック経路上の要素に対応します。ロスシナリオが「どの欄があふれ得るか」を問い、対策が「その欄の上限を誰が証明するか」を決めます。
07明日確認すべきこと
機能安全担当
- 安全目標のFTTIバジェットに、セキュリティ対策（認証の生成・検証）が独立した行として含まれているか？
- 認証検証時間は、通常負荷ではなく最悪条件で測定されたか？
サイバーセキュリティ担当
- TARAのダメージシナリオの安全影響度を、HARAのASILではなく重大度（S）から引き継いでいるか？
- フレッシュネスカウンタの許容ウィンドウと認証失敗時の動作は、安全チームと一緒に決めたか？
アーキテクト
- 「認証失敗・要求破棄」の状態が、要求を送ったコントローラにフィードバックされているか？
- 安全上重要なメッセージが、暗号化された低優先度のトラフィックに押し出されないことを、ジッタシミュレーションで確認したか？
08まとめ
VisualProは、HARA、TARA、STPAを1つのプロジェクトの中で実施できます。本記事のSTPAの例はVisualPro STPAで作成しました。
09よくある質問
Q1HARAとTARAを一緒に行えば十分ではありませんか？なぜSTPAまで必要なのですか？
Q2HSMを使えば問題は解決するのではありませんか？
Q3認証検証が遅れたら、そのままブレーキをかければよいのではありませんか？
Q4TARAの影響度をHARAから引き継ぐ正しい方法は？
Q5STPAを使ったことがありません。どこから始めればよいですか？
· Electronics Weekly, "Linking functional safety with cybersecurity in the automotive industry", 2026年10月13日（Diego de Azcuénaga） — 記事
· ISO 26262-1:2018 FTTIの定義、ISO 26262-3:2018 HARA
· ISO/SAE 21434:2021 — ダメージシナリオの影響度（安全影響はISO 26262-3の重大度に基づく）
· AUTOSAR Specification of Secure Onboard Communication (SecOC)
· Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT, 2018 — STPA Handbook (PDF) / MIT PSASS STAMP Tools