AAOS SDV - Tasarımdan Güvenli

Google olarak ürünlerimizin tasarımdan güvenli olması gerektiğine inanıyoruz. Bu nedenle, Yazılım Tanımlı Araç için Android Automotive İşletim Sistemi'ni (AAOS SDV) mevcut, pazarda kendini kanıtlamış platformlar üzerine inşa ettik ve Cuttlefish gibi sanallaştırma teknolojilerinden yararlandık. Sürüm duyurularımızda özelliklere odaklanmıştık. Bu blog yayınında ise bazı güvenlik kavramlarını ele alacağız.

Temel: Alan İzolasyonu

Ortak barındırılan örnekleri izole etmek için sanallaştırma

Elektronik kontrol ünitelerini (ECU) tek bir çipte birleştirme yönündeki mevcut trend, birden fazla alanı yan yana çalıştırarak izolasyonu azaltır.

AAOS SDV örnekleri dahili izolasyon mekanizmaları sağlasa da mantıksal alanları bağımsız olarak çalıştırmak genellikle tercih edilir. Örneğin, gösterge paneli ve bilgi-eğlence sisteminin farklı gereksinimleri vardır. Birden fazla örneği paralel olarak çalıştırmak için sanal makineler kullanırız. Böylece paylaşımın açık bir şekilde yapılması ve izolasyonun varsayılan davranış olması sağlanır.

Devralınan Android Güvenliği

AAOS SDV, gizlilik sanal makineleri (pVM) için optimize edilmiş minimalist bir Android sürümü olan Microdroid'den geliştirilmiştir. Bu köken, Android platformu mühendislerine zaten bildikleri yerleşik güvenlik özellikleri sunar.

İşlem Yalıtımı ve Varsayılan Olarak Reddetme

AAOS SDV, her uygulama için bir korumalı alan oluşturmak üzere Android'in kullanıcı kimliği (UID) tabanlı izolasyon modelini kullanır. Her hizmet, erişim haklarını, veri dizinlerini ve diğer kısıtlamaları yönetmek için benzersiz bir UID'ye sahip özel bir işlemde çalışır. İşlemleri kesin bir şekilde sınırlamak için Taşınabilir İşletim Sistemi Arayüzü (POSIX) özelliklerini kullanır ve bunu Güvenliği Geliştirilmiş Linux (SELinux) ile eşleştirerek "varsayılan olarak reddetme" yaklaşımını uygularız. Bu yaklaşım, her hizmeti kesinlikle gereken minimum düzeyle sınırlandırır. Bu sayede, eksik yapılandırmalar aşırı izin verilen bir sistem oluşturmak yerine erişimi engeller. Bu makalenin ilerleyen bölümlerinde açıklandığı gibi, aynı stratejiyi iletişim izni sistemimize de uyguluyoruz.

Kanıtlanmış Güvenlik Açığı Yönetimi

AAOS SDV, güvenlik bulgularını tanımlamak, önceliklendirmek, düzeltmek ve açıklamak için Android'in gelişmiş güvenlik müdahalesi ve güvenlik açığı yönetimi altyapısını entegre eder. Bu yaşam döngüsü; sürekli otomatik tarama, yıllık ayrıntılı sızma testi ve Android güvenlik açığı raporlama süreci aracılığıyla iş ortakları tarafından sağlanan istihbaratı içerir. Güvenlik ekibi, tespit edilen güvenlik açıklarını önceliklendirir, riske göre önem derecesi puanları atar ve düzeltme sürecini tamamlanana kadar takip eder. Açıklama ve yayınlama politikalarını aylık Android Güvenlik Bültenleri aracılığıyla koordine ederiz. Ayrıca, platformun uzun vadeli dayanıklılığını sağlamak için düzenli olarak titiz güvenlik denetimleri ve kapsamlı mimari incelemeler yaparız.

Bütünlük: Güvenli Yazılım Teslimatı

Güvenli bir platform, işlem izolasyonunu garanti etmenin yanı sıra yürütme öncesinde kod bütünlüğünü de sağlamalıdır. Yazılım dağıtımını aşağıdaki yaklaşımlarla güvence altına alırız:

Kimlik Doğrulaması Yapılmış Yazılım Teslimatı

AAOS SDV iki yükleme yöntemi sunar. İlk olarak, yazılımı doğrudan salt okunur sistem, ürün veya tedarikçi bölümlerine yükleriz. Bu bölümler, her başlatma işleminde imzaları doğrular. Bu, temel sistem bileşenlerinin güvenliğini sağlar.

İkinci olarak, hizmetler için Android Pony EXpress (APEX) paketlerini kullanırız. Her APEX, yazılımı ve bağımlılıklarını kapsar ve paketi zorunlu imza doğrulaması olan bir bölüm olarak ele alır. AAOS SDV'de APEX, kod imzalamayı donanım tarafından zorunlu kılınan sürekli bir sözleşme olarak ele alır. APEX, kötü amaçlı kod yürütmenin dört temel unsur aracılığıyla azaltılmasını sağlar: 

1. Değiştirilemez Depolama Alanı

• Mekanizma: Android çekirdeği, apex_payload.img dosyasını salt okunur loopback kullanarak doğrudan ham depolama cihazı olarak döngüye alır ve katı MS_RDONLY işaretiyle bağlar.
• Neden daha güvenli? Dosyalar aracın depolama alanına açılmadığı için işletim sistemine yazma yolu gösterilmez. Saldırganlar kök ayrıcalıkları elde etse bile dosya sistemi katmanı tüm yazma komutlarını reddettiği için çalışan APEX kodunu değiştiremez.

2. Kriptografik Bütünlük

• Mekanizma: Kriptografik imza, tüm dosya sistemi görüntüsünün Merkle Ağacı'nı doğrular.
• Neden daha güvenli? Çekirdek, her 4 KB'lık veri bloğunun imzasını anında doğrulamak için blok başına dm-verity kullanır. Bir saldırgan, flash bellekteki ham bir bloğu değiştirirse çekirdek, karma uyuşmazlığını algılar ve yürütmeyi hemen durdurur.

3. Katı İzolasyon

• Mekanizma: Bu, İşlem Yalıtımı bölümünde açıklandığı gibi işlem yalıtımı kurallarını uygulayarak APEX'in /apex altında özel bir bölüm olarak monte edildiği bir korumalı alan oluşturur.
• Neden daha güvenli? Her hizmet kendi kullanıcı ve veri dizinine sahip olur. Bu sayede, açıkça paylaşım yapılmadığı sürece erişim kısıtlanır. Android, özel bir bölüm oluşturarak özel bir bağlayıcı ad alanı oluşturur. Böylece, ayrıcalıklı olmayan sistem daemon'larından yalnızca açıkça gösterilen kitaplıklara erişilebilir ve saldırı yüzeyi en aza indirilir.

4. Atomik Kurtarma

• Mekanizma: APEX, çift arabelleğe alınmış geri alma işlemlerini etkinleştirmek için "Etkin/Yedek" tasarımını kullanır. Fabrikada yüklenen APEX, sabit /system bölümünde kalır. Güncellemeler ise değiştirilebilir /data bölümünde bulunur.
• Neden daha güvenli? Bir güncelleme başarısız olursa veya kötü amaçlı görünürse apexd daemon, erken başlatma sırasında güncellemeyi "başarısız" olarak işaretler. Sistem, sembolik bağlantıları anında /system bölümüne geri döndürür. Bu atomik kurtarma, sistemin bozuk durumda kalmamasını sağlar.

Dayanıklılık: Bellek Güvenliği Sağlayan Geliştirme

Doğrulanmış yükleme, sistemi harici değişikliklere karşı korur ancak platformun dayanıklılığı, temel kodun nasıl oluşturulduğuna da bağlıdır. AAOS SDV için geliştirilen yeni bileşenlerde bellek güvenliğine öncelik verdik.

Birincil dil olarak Rust

AAOS SDV, hızlı kullanılabilirlik gereksinimleri olan küçük sistemleri hedeflediğinden tam Android yığınında derleme yapılmasına izin vermez. Bu nedenle kapsamımızı yerel çerçeveyle sınırladık. Dağıtılmış bir sistem için gereken altyapıyı oluşturmak amacıyla mevcut altyapıya ek olarak birden fazla bileşen geliştirdik ve birincil dil olarak Rust'ı benimsedik. Ayrıca, hizmetlerin iş mantığını geliştirmek için Rust'ı kullanarak iş ortaklarının güvenli yazılımlar yazmasına yardımcı oluyoruz. Rust, yerel kod yazarken ekibin verimliliğini desteklerken yaygın bellek güvenliği güvenlik açığı sınıflarını önlemeye yardımcı olmak için bellek güvenliği özelliklerinden yararlanacak şekilde tasarlanmıştır.

Dağıtılmış Güven: Ağ ve Erişim Denetimi

Yazılım tanımlı araçlar, izole alanlar arasında güvenli etkileşimler gerektirir. AAOS SDV mesh temel hazırlık mimarisi, her iletişim uç noktasının sürümünü ve yazarını şifreleme yoluyla doğrulayarak bu karmaşıklığı giderir.

Cihaz ve Mesh Temel Hazırlığı

AAOS SDV Mesh, her bileşenin ağ kimliğini matematiksel olarak gerçek ikili yürütme durumuna bağlayarak kimlik doğrulama işlemini gerçekleştirir. Bu model, dolaylı yazılım güvenini donanım tabanlı doğrulama ile değiştirir.

Ağ kimlik doğrulaması, sürekli ve kriptografik olacak şekilde tasarlanmıştır. Bu sayede, örneğin araç ağ geçidi gibi bir hizmetin, yalnızca doğru IP adresine sahip olduğu için güvenliği ihlal edilmiş bir bilgi-eğlence sanal makinesine güvenmesi gibi senaryolar önlenir.

Donanım tarafından uygulanan izolasyon ve otomatik karantina protokolleri platformun güvenliğini sağlar. SDV ağındaki eş cihazlar, yetkisiz kod yürütme veya yapılandırma müdahalesini tespit edip kontrol altına almak için DICE tabanlı kimlik doğrulama ve onaylama kullanır. Bu konu, aşağıdaki bölümde ayrıntılı olarak açıklanmıştır.

Sanal makineler arası iletişimin güvenliğini sağlamak için DICE tabanlı TLS

Ana makine kimliğini gerçekliğe dayandırma

DICE'ın (Cihaz Tanımlayıcı Oluşturma Motoru) Altın Kuralı: Donanım yazılımındaki tek bir kod satırı değişirse (küçük bir güncelleme veya kötü amaçlı bir saldırı bile olsa) türetilmiş Bileşik Cihaz Tanımlayıcısı (CDI) tamamen değişir ve tamamen farklı bir Takma Ad Anahtarı oluşturulur.

DICE ve TLS (Taşıma Katmanı Güvenliği), sıfır güven mimarisinin temel zorluğunu çözmek için entegre olur: Bir makinenin kimliğini doğrularken aynı zamanda yazılım bütünlüğünü de doğrular.

DICE'ın donanım tabanlı kimlik doğrulaması ve TLS'nin şifrelenmiş el sıkışması, alıcı makinenin hem arayanın kimliğini hem de tam yazılım durumunu doğrulamasını sağlar.

Geleneksel sertifikalar yalnızca bir gizli anahtarın varlığını kanıtlar, donanım yazılımı üzerinde oynama yapılıp yapılmadığını tespit edemez. DICE, bu sorunu ölçümlü başlatma katmanları ile çözer:

• Benzersiz Cihaz Gizli Anahtarı (UDS): Üretim sırasında oluşturulan rastgele bir kriptografik gizli anahtar. UDS'ye yalnızca birinci aşama bootloader erişebilir. Diğer tüm yazılımlar ve harici arayüzler UDS'ye erişemez.
• Katmanlı Ölçümler (Bileşik Cihaz Tanımlayıcı): Donanım ROM'u, UDS'yi bir sonraki donanım yazılımı katmanının tam kodu ve yapılandırmasıyla karma oluşturarak zinciri başlatır. Bu işlem, bir CDI oluşturur ve ardından her bir katman önyükleme yaparken sırayla zincirleme olarak bağlanır.

AAOS SDV ağındaki hizmet etkileşimleri, katı erişim denetimlerine tabidir. Tüm AAOS SDV yazılımlarında olduğu gibi bu erişim denetimlerinin kimliği doğrulanır ve bütünlüğü, DICE tabanlı kimlik doğrulama aracılığıyla cihaz düzeyinde ve ağdaki cihazlar arasında korunur.

Katmanlı Erişim Denetimi

AAOS SDV, erişim mekanizmalarından ödün vermeden dinamik araç güncellemelerini etkinleştirmek için derinlemesine savunma stratejisi kullanır. Bu model, iki temel güven katmanına dayanır:

1. Hizmet düzeyinde izinler: Belirli bir sanal makinedeki hizmetin ağ genelinde erişebileceği veya kullanıma sunabileceği belirli kaynakları tanımlayın.
2. Sanal makine düzeyinde izinler: Belirli bir sanal makinede barındırılan tüm hizmetler için sanal makineler arası iletişim sınırlarını tanımlayın.

Bu model, OEM'lerin güvenlik ile güncellenebilme durumu arasında denge kurmasına olanak tanır. Güvenlik açısından hassas olmayan hizmetler için izin veren sanal makine düzeyindeki politikalar, sanal makinenin tamamen yeniden dağıtılması yerine basit APEX güncellemeleriyle yükleme yapılmasını sağlar.

Buna karşılık, güvenliğe duyarlı sinyaller için izinler her sanal makinede sabit kodlanmış olmalıdır. Bunun dezavantajı, güvenliğe duyarlı bir hizmeti yeni bir sanal makineye eklemek için sanal makine düzeyindeki izinlerin sistem genelinde güncellenmesi gerekmesidir. Bu durumda, ağdaki tüm sanal makinelerin güncellenmesi gerekir.

Sonuç

AAOS SDV, tasarımdan güvenli yaklaşımıyla belirli otomotiv gereksinimlerini karşılamak için Android'in güvenlik mimarisini genişletir. Platform, alan izolasyonu için sanallaştırmadan yararlanarak ve "varsayılan olarak reddet" erişim politikalarını uygulayarak yazılım tanımlı araçlar için esnek bir ortam oluşturur. Kriptografik bütünlük, yürütülen kodun donanım tarafından zorunlu kılınan anında doğrulanmasıyla korunur.

Platform, proaktif güvenlik açığı yönetiminden DICE aracılığıyla donanım tabanlı kimlik doğrulamaya kadar sürekli güvenlik yaşam döngülerini entegre eder. Bu çok katmanlı savunmalar, OEM'lerin ileri seviye özelliklerin güncellenebilme durumu ile modern otomotiv ortamları için gereken güçlü güvenlik arasında denge kurmasına olanak tanır. Teknik özellikler ve uygulama ayrıntıları AAOS SDV'ye Genel Bakış sayfasında bulunabilir.