OCPP 2.0.1'in Güvenlik Modeli: EV Şarj Altyapısında Saldırı Yüzeyi
Elektrikli araç şarj ağları hızla büyüyor. Peki bu ağı ayakta tutan protokolün güvenlik varsayımları gerçekte ne kadar sağlam?
İçindekiler
Türkiye’de elektrikli araç şarj altyapısı son birkaç yılda katlanarak büyüdü. Cadde başındaki her AC/DC şarj ünitesinin arkasında, çoğu zaman görünmeyen bir protokol çalışıyor: OCPP (Open Charge Point Protocol). Şarj istasyonu ile onu yöneten merkezî sistem (CSMS) arasındaki tüm konuşma bu protokol üzerinden geçiyor — kimin ne zaman ne kadar şarj aldığı, faturalandırma, uzaktan başlat/durdur, firmware güncellemesi.
OCPP’nin ilk sürümleri güvenliği neredeyse hiç düşünmeden tasarlandı. 2.0.1 ile birlikte tabloya güvenlik profilleri, TLS ve sertifika yönetimi girdi. Ama sahada gördüğüm gerçek şu: standardın “yapabilirsin” dediği güvenlik önlemleri, uygulamada çoğu zaman “yapılmamış” durumda. Bu yazıda protokolü bir saldırganın gözünden, üç katmanlı bir saldırı yüzeyi olarak inceliyoruz.
OCPP mimarisini 30 saniyede oturtalım
Zincir üç halkadan oluşuyor: elektrikli araç → şarj istasyonu (Charge Point) → CSMS (backend). Araç ile istasyon arasındaki konuşma ISO 15118 / güç hattı iletişimi tarafında; istasyon ile backend arasındaki konuşma ise OCPP tarafında yürüyor. OCPP 2.0.1, taşıma katmanı olarak WebSocket (ws / wss) kullanır ve mesajlar JSON formatındadır.
Kritik nokta: şarj istasyonu genelde bir gömülü Linux ya da RTOS cihazıdır. Yani karşımızda hem bir ağ istemcisi, hem bir gömülü cihaz, hem de para akışına dokunan bir uç nokta var. Üçünün kesişimi de saldırı yüzeyini büyütüyor.
1. Katman — Fiziksel ve yerel arayüz
Şarj istasyonu, kilitli bir kabinin içinde bile olsa “fiziksel olarak erişilemez” değildir. Sahada en sık karşılaşılan zayıflıklar:
- Açıkta bırakılmış debug/servis portları (UART, JTAG) ve şifresiz servis menüleri
- Firmware’i doğrudan barındıran, çıkarılabilir SD kart veya eMMC
- Servis moduna geçince kullanıcı adı/parola sormayan bakım arayüzleri
Bu katman ele geçirildiğinde saldırgan yalnızca tek bir istasyonu değil, o istasyona gömülü CSMS bağlantı bilgilerini, sertifikaları ve anahtarları da elde eder. Bir istasyondan çıkarılan kimlik bilgisi, tüm filoya sızmanın kapısı olabilir.
2. Katman — OCPP taşıma katmanı
OCPP 2.0.1 üç güvenlik profili tanımlar: yalnızca temel kimlik doğrulama, TLS + temel kimlik doğrulama, ve TLS + istemci sertifikası (mTLS). Standart en güçlü profili önerir ama zorunlu kılmaz. Pratikte gördüklerim:
- Bağlantının hâlâ şifresiz
ws://üzerinden kurulması - TLS kullanılsa bile istemci tarafında sertifika doğrulamasının atlanması (self-signed kabul etme)
- Sabit kodlanmış ya da tüm filoda ortak paylaşılan kimlik bilgileri
Şifresiz veya doğrulamasız bir bağlantı, klasik bir ortadaki adam (MITM) senaryosuna kapı açar. Saldırgan araya girip mesajları okuyabilir, faturalandırma verisini manipüle edebilir veya sahte komutlar enjekte edebilir.
3. Katman — Backend güveni ve komut kötüye kullanımı
OCPP çift yönlü bir protokoldür: CSMS istasyona komut gönderebilir. RequestStartTransaction, RequestStopTransaction, Reset, UpdateFirmware, SetVariables gibi mesajlar bunlardan bazıları. Eğer saldırgan sahte bir CSMS gibi davranabiliyor ya da gerçek CSMS’e komut enjekte edebiliyorsa:
- İstasyonu uzaktan durdurup hizmet dışı bırakabilir (DoS)
- Zararlı firmware yükleme akışını tetikleyebilir
- Yapılandırma değişkenlerini değiştirerek istasyonu güvenlik profili düşük bir moda çekebilir
Buradaki asıl risk tek bir istasyon değil, ölçektir. Merkezî sisteme güvenerek çalışan yüzlerce istasyon, backend güveni kırıldığında aynı anda etkilenebilir.
Savunma tarafı: ne yapılmalı
Bir güvenlik analizi, çözüm önermeden yarım kalır. Öncelik sırasıyla:
- mTLS’i zorunlu kıl — istemci sertifikası olmadan bağlantı kabul etme.
- Sertifika sabitleme (pinning) ve düzgün bir PKI/sertifika rotasyonu kur.
- Güvenli boot ve şifreli depolama ile yerel arayüzden anahtar sızmasını engelle.
- Komut yetkilendirmesi: her OCPP komutunun kaynağını ve yetkisini doğrula.
- Backend tarafında anomali tespiti: aynı istasyondan olağan dışı komut/işlem paternlerini izle.
Adli bilişim açısı
Bir şarj istasyonu olayında iş “saldırı oldu mu” sorusundan “ne oldu, ne zaman, hangi izle” sorusuna geçtiğinde adli bilişim devreye girer. OCPP tarafında işlem logları, mesaj zaman damgaları ve firmware güncelleme kayıtları birer delildir. Gömülü cihaz tarafında ise uçucu bellek, NVRAM ve yapılandırma bölümü incelenmesi gereken artefaktlardır. OT/gömülü sistemlerde klasik disk imajı almak çoğu zaman mümkün olmadığından, canlı analiz ve seçici delil toplama öne çıkar — bu konuya serinin ayrı bir yazısında gireceğim.
Kapanış
OCPP 2.0.1 aslında ihtiyacımız olan güvenlik araçlarının çoğunu içeriyor. Sorun protokolde değil, uygulama ve konfigürasyonda. “Standart destekliyor” ile “sahada açık” arasındaki fark, tam da savunma yapan mühendisin doldurması gereken boşluk. Bu boşluğu görmek için de protokolü hem gömülü hem ağ hem de operasyonel açıdan aynı anda okumak gerekiyor.
Bir sonraki yazıda benzer bir “güvenlik sonradan eklendi” hikâyesini bu kez OT dünyasının en yaygın protokolü Modbus üzerinden anlatacağım.
Bu içerik eğitim ve savunma amaçlıdır. Anlatılan zafiyetler gerçek sistemlere yönelik bir saldırı reçetesi değil, savunma ve adli analiz için farkındalık amacıyla ele alınmıştır.