AAOS SDV - Secure by Design

Google olarak ürünlerimizin tasarımdan güvenli olması gerektiğine inanıyoruz. Bu nedenle, yazılımla tanımlanmış araçlar için Android Automotive İşletim Sistemi'ni (AAOS SDV) mevcut piyasada kendini kanıtlamış platformlar üzerine kurduk 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 güvenlik kavramlarından bazıları açıklanmaktadır.

Temel: Alan Yalıtımı

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 ile bilgi-eğlence sisteminin farklı gereksinimleri vardır. Paylaşımın açıkça yapıldığından ve yalıtımın varsayılan davranış olduğundan emin olmak 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 Portable Operating System Interface (POSIX) özelliklerini kullanırız ve "varsayılan olarak reddet" duruşunu zorunlu kılmak için bunu Security-Enhanced Linux (SELinux) ile eşleştiririz. Bu yaklaşım, her hizmeti gereken mutlak minimum düzeyle 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. Açıklama ve yayın politikalarını, aylık Android Güvenlik Bültenleri aracılığıyla koordine ederiz. Uzun vadeli platform dayanıklılığını sağlamak için bu bültenler, düzenli olarak yapılan titiz güvenlik denetimleri ve kapsamlı mimari incelemelerle desteklenir.

Dürüstlük: Güvenli Yazılım Teslimatı

Güvenli bir platform, süreç 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 teslimatı

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, 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ütülmesinin 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 bağlar.
• 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ştiremez.

2. Kriptografik Bütünlük

• Mekanizma: Kriptografik imza, 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 bloğu değiştirirse çekirdek, karma uyuşmazlığını algılar ve yürütmeyi hemen durdurur.

3. Katı Tecrit

• Mekanizma: Bu, sandbox oluşturmak için İşlem Yalıtımı bölümünde açıklandığı gibi işlem yalıtımı kurallarını uygular. 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. Atomik Kurtarma

• 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ştirilemez /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ş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 şartları olan 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 üzere mevcut altyapıya ek olarak birden fazla bileşen geliştirdik ve birincil dil olarak Rust'ı benimsedik. 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 Denetimi

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şlemlerinin tanımlanmasına ve kontrol altına alınmasına yardımcı olmak için aşağıdaki bölümde ayrıntılı olarak açıklandığı gibi DICE tabanlı kimlik doğrulama ve onaylama kullanır.

Sanal makineler arası 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ı 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ı 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 kimliklendirirken aynı anda yazılım bütünlüğünü doğrular.

DICE'ın donanım tabanlı tanımlaması ile 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 sırrın sahipliğini kanıtlar, donanım yazılımı kurcalamayı tespit edemez. DICE, bu sorunu ölçülmüş başlatma katmanlandırması ile ele alır:

• Benzersiz Cihaz Gizli Anahtarı (UDS): Üretim sırasında oluşturulan rastgele bir kriptografik gizli anahtar. UDS'ye yalnızca ilk aşama önyükleyici erişebilir. UDS, diğer tüm yazılımlar ve harici arayüzler için erişilemez durumda kalır.
• 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, bir CDI oluşturur. Ardından, sonraki her katman başlatıldığında CDI sırayla zincirlenir.

AAOS SDV ağındaki hizmet etkileşimleri sıkı erişim denetimleriyle yönetilir. Tüm AAOS SDV yazılımlarında olduğu gibi, bu erişim kontrollerinin kimliği doğrulanır ve bütünlüğü, cihaz düzeyinde ve ağdaki cihazlar arasında DICE tabanlı kimlik doğrulama yoluyla 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ımlayın.

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 VM düzeyindeki politikalar, tam VM 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. Bunun karşılığında, güvenliğe duyarlı bir hizmetin yeni bir sanal makineye eklenmesi için sanal makine düzeyindeki izinlerin sistem genelinde güncellenmesi gerekir. Bu, ağdaki tüm sanal makinelerin güncellenmesini gerektirir.

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. Alan izolasyonu için sanallaştırmadan yararlanarak ve "varsayılan olarak reddet" erişim politikalarını zorunlu kılarak platform, yazılımla tanımlanan 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.