EV充電ポートが車両盗難の侵入口に？充電インフラに潜む3つの重大な脆弱性 

電気自動車（EV）の普及が加速するなか、充電インフラや充電ステーションに対するセキュリティ研究も急速に進んでいます。これまで多くの研究は、公開されたWebインターフェース、保護が不十分なまま公開状態にあるサービス、Bluetoothを悪用した「充電ステーション側」への攻撃に焦点が当てられてきました。しかし、いまだ十分に検証されていない重要な問いがあります。それは、「EVの充電ポートを通じて車両そのものを侵害することは可能なのか」というものです。

EVの充電ポートは、車両内部の充電コントローラECU（Electric Vehicle Communication Controller、 EVCC）に直接接続されている外部インターフェースです。EVCCは、ISO 15118規格に基づき、車両と充電ステーション間の高度かつ重要な通信を担う制御ユニットです。つまり、充電ポートは車両の中枢システムへと直接つながる入口でもあります。物理的なドアには堅牢なセキュリティ対策が施されていますが、充電ポート経由でアクセス可能なEVCCについては、同等レベルの防御が実装されていないケースも見受けられます。仮にEVCCが侵害された場合、攻撃者は車両内の重要コンポーネントへアクセスできる恐れがあり、車両内部での足がかりを確立しながら攻撃範囲を拡大させることが考えられます。

本記事では、充電プロセスにおいてEVCCが使用する上位通信プロトコルの全体像を整理するとともに、EV充電インフラが抱える潜在的なセキュリティリスクを考察します。

特に、当社のリサーチチームが発見した以下の3つの重要な脆弱性について詳しく解説します。

1. ECUおよび充電ステーションに実装されたV2G通信スタックにおける脆弱性
   
2. 攻撃者による充電ステーション侵害を可能にし得る、オープンソースフレームワーク上の重大な脆弱性
   
3. 充電ステーション運営事業者のクラウドバックエンド（OCPP）に存在する脆弱性

これらの脆弱性が悪用され、充電ポート経由でEVCCが直接侵害された場合、従来とは異なる新たな攻撃経路が生まれます。それは、車両盗難に直結しかねない、極めて重大な攻撃ベクターとなり得るのです。

EV充電エコシステムの複雑性を理解する

商用充電ステーションでは、複数車両への電力供給を効率的に制御するための負荷分散や、課金処理への対応が求められます。そのため、充電ステーションとEVの間では高度かつ複雑な通信が必要になります。さらに、充電ステーションはバックエンドサーバーによって一元管理されており、稼働状況の監視、ファームウェアの更新、電力供給の最適化などが行われています。このように、EV充電の仕組みは単なる「車両と充電器の接続」にとどまりません。車両、充電ステーション、クラウドバックエンドを含む多層的なエコシステムとして構成されており、それを支える専用インフラと運用フレームワークが不可欠となっています。

その中核を担うのが、車両側に搭載されたEVCCです。EVCCは、EVと充電ステーション間の上位通信（ISO15118に基づく上位プロトコル通信）を制御する役割を担っています。このECUは車両内部に配置されていますが、EVCCとの通信は外部に露出している充電ソケットを介して行われます。つまり、充電ポートは物理的には車両外部に位置し、比較的容易にアクセスできるインターフェースです。充電ソケットのドアによって覆われてはいるものの、通信自体はこのポートを通じて直接行われます。その結果、攻撃者にとって充電ポートは魅力的なターゲットとなり得ます。つまり、EVの侵入経路として知られるOBD IIポートは車内への物理的アクセスが必要ですが、充電ポートは車両外部からアクセス可能である点が大きな違いです。この構造的特性こそが、EV充電インフラにおけるセキュリティ検討をより重要なものにしています。

充電ポートを起点としたEVおよびEVSEへの攻撃

車両の充電ポートとの通信には、専用のハードウェアが使用されます。往々にして、充電ポートは車両内の他のコンポーネントと比べ、同等レベルのセキュリティ対策が施されているとは限りません。そのため、EVCCとの初期通信は比較的容易に実現できます。特に、車内への物理的アクセスを必要とする他のECUと比較するとその難易度の差は明らかです。

充電ポートの構造は地域ごとに異なります。米国、欧州、日本、中国など、それぞれの市場で異なる規格およびフォームファクター（コネクタの物理形状）が採用されています。AC充電およびDC充電それぞれに対応するため、充電ソケットの形状やピン構成も地域によって差異があります。AC充電に関しては、欧州および中国ではIEC 62196-2に基づいたType 2コネクタ（Mennekes方式）が広く採用されています。地域ごとの規格差は物理設計の違いにとどまらず、通信方式や実装アプローチにも影響を与えるため、セキュリティ検討においても重要な要素となります。

DC充電においては、地域ごとの差異がより顕著に現れます。米国ではCCS1、欧州ではCCS2、日本ではCHAdeMO、中国ではGB/Tが主に採用されています。

EVSEとEV間の通信の仕組み

商用EV充電設備（Electric Vehicle Supply Equipment、EVSE）は、単に電力を供給するだけではありません。課金処理の管理、電力系統との充電スケジュール調整、接続車両の認証など多岐にわたる機能を担っています。これらを実現するため、EVSEは車両側のEVCCと通信を行います。この通信は、ISO 15118でHigh Level Communication（HLC）と定義されるデジタル通信に基づいています。HLCは、Power Line Communication（PLC）技術を用いて実行されます。具体的には、充電ポートの通信ラインの1つであるControl Pilot（CP）ライン上の信号にデジタルデータを重畳することで通信を行います。PLCによる論理ネットワークの確立方法は、HomePlug Green PHY（GP）仕様で定義されています。この中で用いられるSignal Level Attenuation Characterization（SLAC）プロトコルは、同一バス（通信重畳された通信バス）上の通信エンティティ（EVもしくは、外部蓄電池などの充電対象機器）を識別するために使用されます。SLACプロセスが完了すると、EVおよびEVSEの双方にIPv6アドレスが割り当てられます。これにより、車両と充電ステーション間でイーサネットベースの通常通信が開始されます。この段階から、EVとEVSEはISO 15118またはDIN SPEC 70121で定義されたプロトコルを用いてメッセージを交換できるようになります。

物理層およびリンク層の確立後、EVはネットワーク上でEVSEのアドレスを検出するため、UDPブロードキャストメッセージを送信します。これはSECC Discovery Protocol（SDP）の一部であり、比較的短時間で完了するプロセスです。なお、ISO 15118ではEVSEをSupply Equipment Communication Controller（SECC）と呼ぶこともあります。EVSEは、利用可能なIPv6アドレス、使用するトランスポートプロトコル（UDPまたはTCP）、さらにTLSを利用するか否かといった情報を応答します。その後、EVは充電を開始するプロセスの中でV2Gメッセージを用いてEVSEと通信を継続します。

V2GメッセージはISO 15118またはDIN SPEC 70121で定義されており、XML構造で表現されます。これらのXMLメッセージは、Efficient XML Interchange（EXI）によってバイナリ形式へエンコードされ、通信スタック内の基盤レイヤーとして機能します。最終的に、各V2GメッセージはV2GTPで定義された形式に従い、ペイロード長、メッセージタイプ、プロトコルバージョンを含む8バイトのトランスポートヘッダーを付加して送受信されます。

ケース1：open-plc-utilsにおけるSLAC実装のバッファオーバーフロー

当社のリサーチチームは、open-plc-utilsプロジェクトにおいて重大なスタックベースのバッファオーバーフロー脆弱性を発見しました。対象となったのは、Signal Level Attenuation Characterization（SLAC）プロトコルの実装部分です。SLACは、EVと充電ステーション間で安定したPowerline Communication（PLC）を確立するために不可欠なプロトコルです。つまり、このレイヤーは充電通信の基盤を支える重要な構成要素といえます。本脆弱性（CVE-2025-27071）は、受信ネットワークパケット内のグループ数を示すフィールド（number of groups）に対する検証不備に起因します。このフィールドは、減衰測定値を格納する可変長配列のサイズを決定する役割を持っています。

EV側および充電ステーション（EVSE）側の両実装において、コードはこのユーザー制御可能な値を取得し、境界チェックを行わないままメモリコピー処理に使用していました。その結果、固定サイズ（58バイト）でスタック上に確保されたバッファ（下記図：AGGポインタsession）に対し、最大255までの値を指定することでバッファオーバーフローを引き起こすことが可能となります。open-plc-utilsプロジェクト自体は10年以上更新されていませんでしたが、Linuxベースの充電ステーション環境では依然として広く利用されています。そのため、この脆弱性は理論上の問題にとどまらず、実運用環境にも影響を及ぼし得る重大なリスクといえます。本件は2024年12月にQualcommへ報告され、その後セキュリティアドバイザリが公開されました。さらに、2025年後半にはオープンソースプロジェクトに対するパッチもリリースされています。

充電ステーションはIoTデバイスである

組み込みコンピューティング機能、ネットワーク接続性、そしてユーザー向けアプリケーションとの連携機能を備える充電ステーションは、典型的なIoTデバイスの一例といえます。多くのEVSEはLinuxをベースに動作しており、オープンソースOSの安定性と柔軟性を活用して基盤機能を管理しています。また、一般的なEVSEは複数の通信手段を備えており、セルラー通信によるインターネット接続、Wi-FiやBluetoothを介したユーザーアプリとの接続、さらにはNFCによるスマートカード認証などに対応しています。

これまで、こうした通信経路がEVSEに対する主な攻撃ベクターとみなされてきました。実際に公開されているセキュリティ研究の多くは、Wi-Fi経由で公開された脆弱なサービスの悪用や、LinuxのBluetoothスタックに存在する既知の脆弱性の悪用、その他の近距離通信チャネルを標的とするものでした。

ケース2：充電ステーションにおけるリモートコード実行

当社のリサーチチームは、EVerestフレームワークのEvseV2GモジュールにおけるV2G Transport Protocol（V2GTP）実装部分に整数オーバーフローの脆弱性を発見しました。この重大な脆弱性はヒープオーバーフローを引き起こし、Linuxプロセス上で任意コードを実行可能にします。その結果、充電時の決済制御の回避、充電ステーション（EVSE）内に保存された秘密鍵の窃取、さらには侵害された充電ステーションになりすましてOpen Charge Point Protocol（OCPP）を通じてベンダーのバックエンドと通信することまで可能となります。

EVerestは、Linux Foundationが支援するオープンソースのモジュール型EV充電スタックフレームワークです。今回発見した脆弱性（CVE-2024-37310）は、V2GTPレイヤーに存在し、特にペイロード長の解析処理に起因する問題です。具体的には、受信データ長に8バイトを加算して検証する処理において、32ビット整数のラップアラウンド（値が最大値を超えると最小値に戻る現象）を考慮しない実装が行われていました。その結果、本来は不正値としてはじかれるべき巨大なデータが、境界チェックを通過してしまいます。最終的に、固定サイズのヒープバッファへ過剰なデータが書き込まれ、ヒープオーバーフローが発生します。

攻撃者は、たとえば0xFFFFFFFFのような悪意あるペイロード長を指定することで、検証時に整数オーバーフローを発生させることが可能です。その結果、本来は8192バイトのバッファ容量を超えるデータを制限するためのセキュリティチェックを回避できてしまいます。こうしてシステムは、固定サイズのヒープバッファに対して実質的に無制限のデータ受信を試みることとなり、ヒープオーバーフローが発生します。本脆弱性はCVSSスコア9.0という重大評価を受けており、充電ポート経由でのリモートコード実行を可能にする極めて深刻な問題です。

分散型充電ステーションはクラウドで管理されることが多い

充電ステーションネットワークの構築は、従来のガソリン供給網とは本質的に異なります。分散配置された充電ステーションは、EVが要求する電力を任意のタイミングで無制限に供給できるわけではありません。供給可能な電力量や充電スケジュールは、中央管理システムとの間で調整・最適化される必要があります。この制御を担うのが、一般にCharge Point Operator（CPO）と呼ばれる充電インフラ・ネットワーク管理を運営する会社の中央バックエンドです。CPOはOpen Charge Point Protocol（OCPP）を用いて各EVSEを管理・制御します。一方、EVと充電ステーション間の情報交換は、ISO 15118で定義されるHigh-Level Communication（HLC）に基づき実行されます。このデジタル通信は、充電コネクタのControl Pilotピン上でPowerline Communication（PLC）技術を用いて行われます。つまり、EV充電エコシステムは「車両―充電器―クラウド」という三層構造で成り立っており、各レイヤーが相互に連携することで初めて機能します。

CPOは、管理対象のステーションの近くに設置されたプライベートサーバーで運用される場合もあります。しかし実際には、EVSEがインターネット上に公開されたサーバーへ直接接続しているケースも多数確認されました。さらに問題なのは、認証がバックエンド側の正当性確認のみに使用され、接続してくるEVSE側の検証が十分に行われていない構成が存在していた点です。このような設計では、第三者がサーバーに対してクエリを送信したり、正規の充電ステーションを装って接続し、データ取得やポートスキャンを行うことが可能になります。

ケース3：CPOバックエンドクラウドサーバーの侵害

私たちの調査では、任意のクラウドベース攻撃を受け得る公開サーバーが確認されました。この脆弱性を悪用することで、攻撃者は管理者レベルの権限でEVSE群を制御できる可能性があります。

あるメーカーのAndroidアプリを解析する過程で、OCPP通信も処理しているバックエンドCPOサーバーを特定しました。このサーバーはSpring Bootフレームワーク上で稼働しており、管理機能がデフォルトで有効化された状態でした。この設定は極めて危険です。攻撃者は管理用の機密エンドポイントへアクセスし、サーバー上で稼働するJava Virtual Machine（JVM）のフルヒープダンプ（メモリ上に保持されている情報を丸ごと取得する機能）を取得できる可能性があります。その結果、クラウド側から充電ステーション全体を掌握するという、極めて重大なリスクが生じます。

取得されたヒープダンプを解析すると、攻撃者は極めて機密性の高い情報を抽出できる可能性があることがわかりました。具体的には、企業情報である実装コード、パスワード、URL、各種機密情報、組織のメールアドレス、さらには当該充電ステーションを利用した車両のVIN（車台番号）などが含まれます。その影響は深刻です。CPOバックエンドが侵害された場合、攻撃者は管理下にある充電ステーション群を遠隔から制御できる可能性があります。これにより、ファームウェアアップデートの改ざん、供給電力レベルの操作、あるいはネットワーク全体での無償充電の許可といった不正行為が現実的な脅威となります。

私たちは本脆弱性を確認後、直ちに該当サーバーの管理者へ通知し、問題は速やかに是正されました。

侵害されたEVCCがもたらす新たな車両盗難リスク

本記事で取り上げた一連の脆弱性により、充電ポート経由でEVCCを直接侵害することが可能になります。これは、車両盗難における新たなかつ重大な攻撃ベクターを意味します。従来の攻撃手法では、車両内部へ物理的に侵入し、CANバスへアクセスする必要がありました。しかし、EVCCが侵害された場合、外部からアクセス可能なインターフェースを起点として、車両内部ネットワークへの足がかりが得られます。

EV車両盗難に関して想定される基本的な攻撃チェーンは以下の通りです。

1. 充電ポート経由での侵害
   攻撃者は、これまでに説明したバッファオーバーフローや整数オーバーフローといった脆弱性を悪用し、外部の充電ポートからEVCCを侵害します。これにより、EVCC上でのリモートコード実行が可能となります。
2. 車両内部ネットワークへのアクセス
   EVCCは車両内部ネットワークに接続されています。侵害後、攻撃者はこの接続を利用して、任意のCANメッセージを車両バスへ送信できる恐れがあります。
3. 車両コマンドの偽装注入
   送信された任意メッセージが正規コマンドに成りすました場合、電子イモビライザーの回避、ドアロックの解除、さらには車両始動といった操作が可能になる恐れがあります。結果として、物理的な鍵を用いることなく車両を盗難できるシナリオが成立します。

この攻撃が特に危険である理由は、EVCCがその機能上、外部と内部ネットワークを接続するゲートウェイ的役割を担っている点にあります。つまり、本来は充電機能のために開かれたインターフェースが、適切な防御がなければ侵入口へと変わり得るということなのです。

EVCCを起点とする車両盗難への対策

EVCCの侵害を新たな車両盗難リスクとしないために、自動車メーカーには多層的なセキュリティアプローチの採用が求められます。

• アンチエクスプロイト対策の実装
  EVCCファームウェアに対し、スタックカナリアやMemory Protection Unit（MPU）といった最新のアンチエクスプロイト対策（脆弱性が存在しても攻撃成立を防ぐ防御機構）を適用し、バッファオーバーフローなどの脆弱性悪用を困難にすることが重要です。
• 車両ネットワークのセグメンテーション
  車両ネットワーク設計において、EVCCのような外部と接続するECUを、エンジン始動やドアロック制御などの安全上重要な制御系が属する領域にあるECUから分離することが不可欠です。EVCCは外部インターフェースに接続され攻撃対象となり得るため、ここから転送されるメッセージについては、堅牢なゲートウェイを通じて厳格なフィルタリング、認証、妥当性検証を実施する必要があります。

結論と提言

電動化の進展に伴い、堅牢な充電インフラは車両アーキテクチャの一部として不可分の存在となっています。このため、充電ポートという外部インターフェースを介して車両内部ネットワークへ到達可能であるという構造的特性は、新たな設計上の検討課題を提示しています。本記事で紹介した脆弱性は、特定の実装不備にとどまらず、通信スタックやネットワーク設計の前提に内在するリスクを示すものです。低レイヤープロトコル（物理・リンク層など）の安全性、外部接続ECUの信頼境界の設定、クラウドバックエンドの保護といった各層において、多層的な防御設計が求められます。EV充電環境の安全性を確保するためには、個別の脆弱性対策に加え、アーキテクチャ全体を俯瞰したセキュリティ設計と継続的な検証が不可欠です。特に、設計段階からのセキュリティ検証および実環境を想定したペネトレーションテストの実施は極めて重要です。充電ポートを単なる利便性のためのインターフェースとしてではなく、外部からの侵入経路となり得る境界点として捉える視点が今後ますます重要になるでしょう。
EV充電環境の安全性を確保するためには、以下の対策を講じることが重要です。

• 規格要件およびハードウェア構成に基づき、ECUへ適切なセキュリティ制御を実装する
• サードパーティ製ツールやオープンソースソフトウェアの利用に際しては、十分なセキュリティ評価を行う
• CPOの設計・実装においてセキュリティを前提とする（例：管理エンドポイントの保護、OCPPサーバーの公開範囲の制限）

PlaxidityX サイバーセキュリティリサーチ＆ソリューションチームについて

PlaxidityXのサイバーセキュリティ リサーチ＆ソリューションチームは、自動車業界に特化したサイバーセキュリティの研究およびソリューション提供を行っています。車両アーキテクチャ、通信プロトコル、関連規格に対する深い理解を基盤に、包括的なサイバーセキュリティサービスを提供しています。

チームは、車両エコシステム全体を対象としたセキュリティ評価・ソリューションに取り組んできました。これまでに主要自動車メーカーおよびTier 1サプライヤーと多数のペネトレーションテストおよび研究プロジェクトを実施し、実環境を想定した検証を通じて設計上の課題抽出と改善支援を行っています。また、UN R155やISO 21434といった国際規制・標準への対応支援を含め、開発プロセス全体に組み込まれたセキュリティ体制の構築をサポートしています。

リサーチプロジェクトの実施から、PlaxidityXの先進的な製品導入まで、進化する脅威に対応するための知見と技術を提供し、車両ライフサイクル全体にわたるセキュリティ確保を支援します。