Android Uyumluluk Tanımlama Belgesi'ne göre, OEM'ler uygulama geliştirmeyi etkinleştirmenin bir yolunu sağlamalıdır. Ancak arabalarda mobil cihazlardaki gibi geliştirici seçenekleri sunmak, bu arabaları saldırılara karşı savunmasız bırakır. Geliştirici seçeneklerine erişim artık kimliği doğrulanmış bir kriptografik jeton mekanizması kullanılarak OEM tarafından sınırlandırılabilir. Özellikle bir OEM şunları yapabilir:
- İlk başlatmadan önce varsayılan kısıtlamaları belirtin.
- Tercih ederseniz kripto jetonlarla geliştiricileri güvenli bir şekilde yetkilendirin.
- Geliştirici hem kimliği doğrulandığında hem de yetkilendirildiğinde kısıtlama değişikliklerini uygular.
Bu sayfada, hata ayıklama kısıtlama denetleyici uygulaması ve uzaktan jeton veren uç noktadan oluşan bir referans uygulaması açıklanmaktadır.
Terminoloji
Terminoloji'ye ek olarak bu sayfada şu terimler kullanılmaktadır:
- RFC 7515'te tanımlanan JSON Web Signature (JWS)
- Ulusal Standartlar ve Teknoloji Enstitüsü (NIST)
Tasarım
OEM'ler, geliştiricileri JSON Web Signature (JWS) jetonlarıyla (RFC7515) yetkilendirebilir. Referans uygulamada, erişim jetonları OEM'ler tarafından verilir ve kısıtlama denetleyici uygulaması tarafından kullanılır. Erişim jetonları, yeniden oynatma saldırılarına ve sahte jetonlara karşı dayanıklı olacak şekilde tasarlanmıştır.
Şekil 1. Tasarım
Entegrasyon ve yapılandırma
OEM'ler, ilk başlatmada varsayılan kısıtlamaları belirtmelidir. OEM'ler bunu, AOSP çerçevesindeki varsayılanları geçersiz kılmak için çeşitli statik kaynak katmanlarıyla yapar.
Başsız sistem kullanıcısının varsayılan kısıtlamaları, config_defaultFirstUserRestrictions içinde frameworks/base/core/res/res/values/config.xml dizesiyle yapılandırılabilir. Örneğin:
<!-- User restrictions set when the first user is created.
Note: Also update appropriate overlay files. -->
<string-array translatable="false" name="config_defaultFirstUserRestrictions">
<item>no_debugging_features</item>
<item>no_install_unknown_sources</item>
<item>no_install_unknown_sources_globally</item>
</string-array>Sürücüler, yolcular ve misafirler için varsayılan kısıtlamalar frameworks/base/core/res/res/xml/config_user_types.xml bölümünde yapılandırılabilir. Bir OEM, bu dizeleri sırasıyla her kullanıcı türü için varsayılan kısıtlamaları ayarlamak üzere yerleştirebilir. Örneğin:
<user-types> <full-type name="android.os.usertype.full.SECONDARY" > <default-restrictions no_debugging_features="true" no_install_unknown_sources="true"/> </full-type> <full-type name="android.os.usertype.full.GUEST" > <default-restrictions no_debugging_features="true" no_install_unknown_sources="true"/> </full-type> </user-types>
Derleme numarası tercihi denetleyicisi
AAOS'te, Ayarlar'daki Derleme Numarası tercih satırıyla kullanıcı etkileşimi, packages/apps/Car/Settings/src/com/android/car/settings/system/BuildNumberPreferenceController.java konumundaki BuildNumberPreferenceController.java tarafından işlenir.
no_debugging_features (UserManager.DISALLOW_DEBUGGING_FEATURES) kullanıcı kısıtlaması ayarlandığında,
BuildNumberPreferenceController, dokunulduğunda üretim (user) derlemelerinde geliştirici geri sayımını devre dışı bırakır:
@Override protected boolean handlePreferenceClicked(Preference preference) { if (DevelopmentSettingsUtil.isDevelopmentSettingsEnabled(getContext())) { return true; } // Enforce restriction on production (user) builds if (Build.IS_USER && mUserManager.hasUserRestriction(UserManager.DISALLOW_DEBUGGING_FEATURES)) { showToast(R.string.dev_access_blocked_toast); return true; } mDevHitCountdown--; if (mDevHitCountdown == 0) { DevelopmentSettingsUtil.setDevelopmentSettingsEnabled(getContext(), true); showToast(R.string.show_dev_on); } return true; }
Build.IS_USER kullanıldığında üretim derlemelerinde güvenlik kilitlemesinin sıkı bir şekilde uygulanması sağlanır. userdebug derlemelerindeki dahili mühendislik ekipleri ise manuel komut satırı arayüzü (KSA) geçersiz kılmaları olmadan test için 7 kez dokunma hareketiyle geliştirici seçeneklerine erişebilir.
Kısıtlama denetleyicisinde hata ayıklama
Hata Ayıklama Kısıtlama Denetleyicisi'nin (DRC) referans uygulaması, AOSP'de packages/apps/Car/DebuggingRestrictionController adresinde sağlanır.
DRC, yetkili servis teknisyenleri ve geliştiriciler için üretim araçlarındaki no_debugging_features kısıtlamasını OEM'lerin dinamik ve geçici olarak kaldırmasına olanak tanır. Araç içi DRC uygulaması, hata ayıklama araçlarını kalıcı olarak açık bırakmak veya donanım yazılımının yeniden yanıp sönmesini gerektirmek yerine, kullanıcıdan OEM arka ucuyla kimlik doğrulaması yapmasını ve sınırlı bir teşhis oturumu için adb ve Geliştirici Seçenekleri'ni etkinleştirmek üzere kriptografik olarak imzalanmış bir erişim jetonu göndermesini ister.
DRC referans uygulaması iki temel bileşenden oluşur:
- Araç içi DRC istemci uygulaması (
app/): Gelen JWS jetonlarının geliştiricilerini kimlik doğrulaması, X.509 sertifika imzasını, ana makine adını, tek seferlik rastgele sayıyı ve geçerlilik bitimini doğrulayan veUserManagerkullanarakno_debugging_featureskısıtlamasını dinamik olarak değiştiren, ana ünitede ayrıcalıklı bir sistem uygulamasıdır (MANAGE_USERSiznini içerir). - Cloud Token Issuer (
server/): Geliştirici kimlik bilgilerini doğrulayan ve sınırlı bir geçerlilik süresiyle kriptografik olarak imzalanmış RS256 JWS erişim jetonları veren bir arka uç web hizmeti (Firebase Cloud Functions olarak dağıtılabilir).
Kurulum talimatlarının tamamı, sertifika oluşturma aracı ve dağıtım adımları için Hata Ayıklama Kısıtlama Denetleyicisi entegrasyon kılavuzuna bakın.
Test
Google, OEM'lerin referans uygulamayla başlayıp buradan devam etmesini önerir.
- Yer paylaşımı dosyalarındaki kısıtlamaları yapılandırdıktan sonra AAOS'u derleyin ve tanımlanan akışları doğrulayın. Erişim ayarlarınızı doğrulamak için referans uygulamayı ve yerel JWS özellikli hizmeti kullanın.
- İsteğe bağlı: Sistemi, JWS özellikli bulut hizmetinizi kullanacak şekilde yapılandırın. Arka uç hizmetinizde beklenen akışı izlediğinizi doğrulayın.