AAOS SDV - Secure by Design

Google olarak ürünlerimizin tasarım aşamasından itibaren güvenli olması gerektiğine inanıyoruz. Bu nedenle, Cuttlefish gibi sanallaştırma teknolojilerinden yararlanarak, mevcut piyasada kendini kanıtlamış platformlar üzerinde yazılımla tanımlanmış araçlar için Android Automotive İşletim Sistemi'ni (AAOS SDV) geliştirdik. Sürüm duyurularımızda özelliklere odaklanmıştık. Bu blog yayınında ise güvenlik kavramlarından bazıları açıklanmaktadır.

Temel: Alan izolasyonu

Birlikte barındırılan örnekleri yalıtmak için sanallaştırma

Elektronik kontrol birimlerini (ECU'lar) tek bir çipte birleştirme yönündeki mevcut trend, birden fazla alanın yan yana çalıştırılmasıyla 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, bir küme ve bir bilgi-eğlence sistemi farklı gereksinimlere sahiptir. Paylaşımın açık ve yalıtımın varsayılan davranış olmasını sağlamak için birden fazla örneği paralel olarak çalıştırmak üzere sanal makineler kullanırız.

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 soy, Android platform 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 sandbox 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 ile özel bir süreçte çalışır. İşlemleri kesin olarak sınırlamak için Taşınabilir İşletim Sistemi Arabirimi (POSIX) özelliklerini kullanırız ve "varsayılan olarak reddet" güvenlik duruşunu zorunlu kılmak için bunu Güvenliği Artırılmış Linux (SELinux) ile eşleştiririz. Bu yaklaşım, her hizmeti kesinlikle gerekli olan minimum düzeyde kısıtlar. Bu nedenle, eksik yapılandırmalar aşırı izinli bir sistem oluşturmak yerine erişimi engeller. Bu makalenin ilerleyen bölümlerinde açıklandığı gibi, iletişim izni sistemimizde de aynı stratejiyi 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 olgun güvenlik yanıtı ve güvenlik açığı yönetimi altyapısını entegre eder. Bu yaşam döngüsünde sürekli otomatik tarama, yıllık ayrıntılı sızma testi ve Android güvenlik açığı bildirme süreci aracılığıyla iş ortağı odaklı analizler yer alır. Güvenlik ekibi, keşfedilen güvenlik açıklarını önceliklendirir, riske göre önem dereceleri atar ve düzeltme sürecini tamamlanana kadar takip eder. Uzun vadeli platform dayanıklılığını sağlamak için aylık Android Güvenlik Bültenleri aracılığıyla açıklama ve yayın politikalarını koordine ederiz. Bu bültenler, düzenli olarak yapılan sıkı güvenlik denetimleri ve kapsamlı mimari incelemelerle desteklenir.

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

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

Kimliği doğrulanmış yazılım teslimi

AAOS SDV, iki yükleme yöntemi sunar. Öncelikle, her başlatmada imzaları doğrulayan salt okunur sistem, ürün veya satıcı bölümlerine doğrudan yazılım yükleriz. Bu, temel sistem bileşenlerini korur.

İkincisi 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ı sürekli ve donanım tarafından zorunlu kılınan bir sözleşme olarak ele alır. APEX, dört temel sütun aracılığıyla kötü amaçlı kod yürütmenin azaltılmasını sağlar: 

1. Değiştirilemez Depolama

• Mekanizma: Android çekirdeği, salt okunur geri döngü kullanarak apex_payload.img dosyasını doğrudan ham depolama cihazı olarak döngüye alır ve katı MS_RDONLY işaretiyle monte eder.
• Neden daha güvenli? Dosyalar aracın depolama alanına açılmadığı için işletim sistemine yazma yolu açılmaz. 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ştiremezler.

2. Kriptografik Bütünlük

• Mekanizma: Şifreleme imzası, dosya sistemi görüntüsünün tamamının Merkle Ağacı'nı doğrular.
• Neden daha güvenlidir? Çekirdek, her 4 KB'lık veri bloğunun imzasını anında doğrulamak için blok başına dm-verity kullanır. 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ı tecrit

• Mekanizma: Bu, İşlem Yalıtımı bölümünde açıklandığı gibi işlem yalıtımı kurallarını uygulayarak sandbox oluşturur. APEX, /apex altında özel bir bölüm olarak monte edilir.
• Neden daha güvenlidir? Her hizmet kendi kullanıcı ve veri dizinini alır. Bu sayede, paylaşım açıkça belirtilmediği 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. Bu sayede, yalnızca açıkça kullanıma sunulan kitaplıklara ayrıcalıklı olmayan sistem daemon'ları tarafından erişilebilir ve saldırı yüzeyi en aza indirilir.

4. Atomic Recovery

• Mekanizma: APEX, çift arabellekli geri alma özelliğini etkinleştirmek için "Etkin/Yedek" tasarımını kullanır. Fabrikada yüklenen APEX, değiştirilemeyen /system bölümünde kalırken güncellemeler değiştirilebilir /data bölümünde bulunur.
• Neden daha güvenlidir? 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 bunu "başarısız" olarak işaretler. Sistem, sembolik bağlantıları anında /system bölümüne geri taşır. Bu atomik kurtarma, sistemin bozuk durumda kalmamasını sağlar.

Esneklik: Bellek açısından güvenli geliştirme

Doğrulanmış yükleme, sistemi harici değişikliklerden 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 şartlarına sahip küçük sistemleri hedefler. Bu nedenle, tam Android yığını üzerinde geliştirme yapılması engellenir. Bu nedenle, kapsamımızı yerel çerçeveyle sınırladık. Dağıtılmış bir sistem için gerekli altyapıyı oluşturmak amacıyla mevcut altyapıya ek olarak birden fazla bileşen geliştirdik ve birincil dil olarak Rust'ı kullandık. Ayrıca, iş ortaklarının güvenli yazılımlar yazmasına yardımcı olmak için hizmetlerin iş mantığını geliştirmek üzere Rust'ı kullanırız. Rust, yerel kod yazarken ekip verimliliğini desteklemenin yanı sıra yaygın bellek güvenliği açığı sınıflarını önlemeye yardımcı olmak için bellek güvenliği özelliklerinden yararlanır.

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

Yazılımla tanımlanan araçlar, yalıtılmış alanlar arasında güvenli etkileşimler gerektirir. AAOS SDV mesh sağlama mimarisi, her iletişim uç noktasının sürümünü ve yazarını kriptografik olarak doğrulayarak bu karmaşıklığı giderir.

Cihaz ve Mesh Temel Hazırlığı

AAOS SDV Mesh, her bileşenin ağ kimliğini matematiksel olarak kendi ikili yürütme durumuna bağlayarak kimlik doğrulaması yapar. Bu model, örtülü yazılım güveninin yerini donanım tabanlı doğrulama ile alır.

Ağ kimlik doğrulaması, sürekli ve kriptografik olacak şekilde tasarlanmıştır. Bu sayede, örneğin bir araç ağ geçidi gibi bir hizmetin, 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 zorunlu kılınan 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 kurcalama işlemlerini tanımlayıp kontrol altına almak için aşağıdaki bölümde ayrıntılı olarak açıklanan DICE tabanlı kimlik doğrulama ve onaylama yöntemini kullanır.

VM'den VM'ye iletişimi güvenli hale getirmek için DICE tabanlı TLS

Sunucu kimliğini gerçekliğe dayandırma

DICE'ın (Cihaz Tanımlayıcı Bileşen 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ı olsa bile) türetilen Bileşik Cihaz Tanımlayıcı (CDI) tamamen değişir ve bambaşka 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 makineyi kimlik doğrulamak ve aynı anda yazılım bütünlüğünü doğrulamak.

DICE'ın donanım tabanlı tanımlaması ile TLS'nin şifrelenmiş el sıkışması sayesinde, alıcı makine hem arayanın kimliğini hem de yazılımının tam durumunu doğrulayabilir.

Geleneksel sertifikalar yalnızca bir sırrın bulunduğunu kanıtlar ve donanım yazılımı kurcalamalarını tespit edemez. DICE, bu sorunu ölçülmüş başlatma katmanlandırması ile çözer:

• Benzersiz Cihaz Gizli Anahtarı (UDS): Üretim sırasında oluşturulan rastgele bir şifreleme gizli anahtarıdır. UDS'ye yalnızca ilk 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ısı): Donanım ROM'u, UDS'yi sonraki yazılım katmanının tam kodu ve yapılandırmasıyla karma oluşturarak zinciri başlatır. Bu işlem, her bir sonraki katman başlatıldığında sırayla zincirlenen bir CDI oluşturur.

AAOS SDV ağındaki hizmet etkileşimleri sıkı erişim kontrolleriyle yönetilir. Tüm AAOS SDV yazılımlarında olduğu gibi, bu erişim kontrolleri de kimliği doğrulanmış ve bütünlüğü cihaz düzeyinde ve DICE tabanlı kimlik doğrulama aracılığıyla 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 bir 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ımlar.

Bu model, OEM'lerin güvenlik ile güncellenebilirlik arasında denge kurmasına olanak tanır. Güvenlik açısından hassas olmayan hizmetler için izin verici sanal makine düzeyindeki politikalar, tam sanal makine yeniden dağıtımları yerine hafif APEX güncellemeleri aracılığıyla yüklemeye olanak tanır.

Buna karşılık, güvenliğe duyarlı sinyaller için izinler her sanal makineye sabit kodlanmalıdır. Bununla birlikte, güvenliğe duyarlı bir hizmetin yeni bir sanal makineye eklenmesi için sanal makine düzeyindeki izin sisteminin genel olarak güncellenmesi gerekir. Bu nedenle, ağdaki tüm sanal makinelerin güncellenmesi gerekir.

Sonuç

AAOS SDV, Android'in güvenlik mimarisini genişleterek tasarımdan güvenli bir yaklaşımla otomotiv sektörüne özgü gereksinimleri karşılar. Platform, alan izolasyonu için sanallaştırmadan yararlanarak ve "varsayılan olarak reddet" erişim politikalarını zorunlu kılarak yazılımla tanımlanmış 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 anlık doğrulanmasıyla sağlanır.

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 gelişmiş özelliklerin güncellenebilirliği ile modern otomotiv ortamları için gerekli olan 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 yer almaktadır.