TLS・証明書運用・JWS 署名など、OCPP 2.0.1 セキュリティ Whitepaper の要点を整理
OCPP 2.0.1 は Security Whitepaper で通信・運用セキュリティのベストプラクティスを定義しています。本記事では、実装者が押さえるべき主要ポイントと、よくある脅威への対策を整理します。
1. セキュリティの柱
- TLS 1.2+ による暗号化
- クライアント証明書による相互認証
- JWS (JSON Web Signature) でメッセージ完全性を担保
- 証明書ライフサイクル API で鍵更新を自動化
- セキュリティイベントのモニタリング
2. 脅威モデルと対策
| # | 脅威 | 影響 | 主な対策 |
|---|---|---|---|
| T1 | 中間者攻撃 (MITM) | 認証情報漏洩・改ざん | TLS 1.2+ / クライアント証明書 / HSTS |
| T2 | リプレイ攻撃 | 二重課金・不正操作 | JWS 署名 + timestamp + 再送制御 |
| T3 | 不正充電器のなりすまし | CSMS 乗っ取り | CA 署名済み端末証明書 / OCSP Stapling |
| T4 | 署名鍵漏洩 | 全メッセージ改ざん | HSM 保管 / 定期的な鍵ローテーション (UpdateFirmware, SignCertificate) |
| T5 | ソフトウェア改ざん | マルウェア混入 | Secure Boot / Firmware 署名検証 |
| T6 | ログ改ざん・削除 | インシデント調査不能 | リモート Syslog / 不変ストレージ (WORM) |
3. TLS 設定のベストプラクティス
text
Protocol : TLSv1.2 or 1.3
Ciphersuites : ECDHE-ECDSA-AES256-GCM-SHA384,
ECDHE-RSA-AES256-GCM-SHA384 (HTTP/WS)
Compression : off (CRIME 対策)
ClientAuth : require
OpenSSL 設定例 (openssl.cnf):
ini
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384"
Options = ServerPreference,NoRenegotiation
4. JWS 署名フロー
署名アルゴリズムは ES256 (ECDSA P-256 + SHA-256) が推奨。ヘッダにはキーID (kid) を含め、証明書ローテーション時の衝突を防ぎます。
C++17 (nlohmann::json + jwt-cpp) 署名例
cpp
using jwt::create;
std::string signed_msg = create()
.set_payload_claim("ocpp", jwt::claim(raw_payload))
.set_issued_at(std::chrono::system_clock::now())
.sign(ecdsa_private_key);
5. 証明書ライフサイクル API
OCPP 2.0.1 は以下のメッセージで CA 証明書とデバイス証明書の管理を行います。
| API | 方向 | 目的 |
|---|---|---|
GetCertificateStatus | CSMS → CP | 証明書の状態確認 |
GetInstalledCertificateIds | CSMS → CP | インストール済み証明書一覧 |
InstallCertificate | CSMS → CP | 新規証明書 + キーの配布 |
DeleteCertificate | CSMS → CP | 期限切れ証明書の削除 |
SignCertificate | CP → CSMS | CSR 提出 (オプション) |
自動鍵更新 を 30〜45 日前からスケジュールし、更新失敗時は
SecurityEventNotificationでアラートを送信しましょう。
6. セキュリティイベントのモニタリング
SecurityEventNotification を活用し、CSMS 側で以下のイベントを収集します。
| EventType | 例 |
|---|---|
FirmwareUpdated | ファーム更新完了 |
CertificateExpired | 期限切れ証明書検出 |
UnauthorizedAccess | 不正アクセス試行 |
イベントは SIEM (Security Information and Event Management) へ転送すると、インシデント対応が迅速になります。
7. 物理 & 運用セキュリティ
- Secure Element: 鍵を TPM や ATECC608 などのハードウェアに格納し、抽出を防止。
- Secure Boot: UEFI/MCU ブートローダでファーム署名を検証。
- Tamper Switch: ケース開封など物理改ざんを検知し、CSMS にイベント通知。
8. まとめ
- OCPP 2.0.1 では 通信暗号化とメッセージ署名が必須。ホワイトペーパーの要件を満たすことで法規制やエネルギー管理基準にも適合。
- 証明書ライフサイクル API と
SecurityEventNotificationを組み合わせ、自動鍵更新 + 監査ログ を確立する。 - ソフトウェアだけでなく 物理的な耐タンパ性 も考慮し、エッジデバイスを総合的に防御する。
次の記事では、「BootNotification から Heartbeat までの C++ 実装詳細」をさらに掘り下げます。